Back in my glory days of undergrad, I sat in my dorm room making Flash games. From 2009-2011 I released 8 games that were played over 25,000,000 times and generated over $20,000 in revenue, mostly from embedded video advertisements. These games weren't particularly high quality and didn't take more than a few weeks to make.
Making these games taught me a lot about designing products for users. Here are the 8 lessons and some relevant reading on the same topics:
1. Prototype a lot. More doing, less planning. Exploring the design space through actual proof of concepts is a great exercise. You will seredipitously discover things that you would have never been able to plan. I made 100+ different prototypes throughout the process of making my 8 games. A lot of people thought this was a waste of time, but I can't see how I would have came up with those ideas any other way! My prototype library itself was quite useful too. Need some code for an enemy that homes in on the player? Copy and paste that from a previous prototype. Need some inspiration for a new game? Go play with prototypes from last year!
2. Get feedback early and often. What's fun in your head probably isn't fun in reality. You can learn so much from just putting your product in front of a few people for 10 minutes. Every time you make major changes, get feedback. I don't just mean verbal feedback. Observe how users interact with your product. Are they skipping the tutorial? Can they not figure out how to do something? You certainly have to take user feedback with a grain of salt, but there is often some truth in what they say. It is not easy to read between the lines though! You're bound to misinterpret feedback so be prepared to iterate often.
3. Don't blame your users. It is enticing to assume a user is stupid if they can't figure out how to use a simple feature. For example, I received several complaints about a game of mine not having a mute button... but it was there! I ignored them and then got the same complaints with my next game. But maybe my mute button wasn't as obvious as I had thought? Or maybe my music was bad or too loud by default? Another example was a game of mine with controls that were not intuitive, which caused players to lose interest before they ever figured it out. I ignored the early feedback (even from a friend who was the first to test it) and that game did not do well. Don't get defensive when your design doesn't work out. This is an opportunity to improve your product.
4. Be careful striving to be different just to be different. I went down the rabbit hole of seeking novelty too many times and was left with games that just didn't work. Novelty is hard, especially when you are trying to force it. If you find yourself stuck after too long, such as staring at the wall wondering what game you should make, then stop! Refer back to lesson #1. Even though there is a lot of taboo around incremental improvements, there is nothing wrong with improving on an existing idea. In fact, novelty has some disadvantages! You have to be the first to sort through the issues and convince your users that your idea is good.
5. Polish polish polish. Polish is everything! Adding a few animations, particle emitters, and sound effects really goes a long way and your players will notice. Often times I would struggle with knowing what to add next, but my roommate was always able to point out a tiny feature, like an on-hover sound effect, that made the game feel so much better. It is easy to get your mind stuck on your product's main features, but adding polish is often very low effort. Look at other products in your market for inspiration and have attention to detail. No one likes programmer art. Don't be lazy! :)
6. Diversify. Don't put all your eggs in one basket, whether it is revenue streams or game ideas. Almost all of the revenue from my games came from an advertisement company called Mochi Media. They made it easy for anyone to monetize their game... until they were acquired and shutdown. My revenue stream was immediately $0 with no way for me to fix it since the games were deployed with their advertisement API embedded in the games and no way of me pushing an update. Not only did most of my revenue come from one company, but two of my games accounted for 85% of my ad views. Had I cared more about the business side of things, I would have utilized other ad APIs (e.g., Kongregate and Facebook) and other revenue sources (e.g., my website and branded versions of my games).
7. Do you use your own product? The ultimate test I have found in game development is do I play my game?. If I don't even find it fun then it will be difficult to convince others to play it. Additionally, it will be difficult to stay motivated and excited to work on the game if I don't really like it. Don't just test it, but use it. This is more generally known as dog fooding.
8. Allow users to be intellectually invested. Give them something to come back to. Provide them long-term value that will get them coming back over and over. This is key to virality. Users won't tell their friends about a product or game that they used for 5 minutes and never thought about again. As my roommate described it, the goal is to get a player intellectually invested. In gaming, this often involves giving players opportunities to make choices and to get better at the game. They will keep playing and will think about it even when they aren't playing. Then they will tell their friends. Gamification (e.g., achievements) is a popular way to do it, but I argue it is quite shallow. The games that I tend to replay often have some combination of (a) deep character customization, such as skill trees, that keep me optimizing my choices, (b) involve a lot of skill that requires deliberate practice, or (c) have a social element that enables competition. These ideas apply even in other domains outside of gaming. Note: I am not advocating for using psychological warfare to get your users addicted, but rather providing beneficial value to the user.