Something that I heard about on a Sirlin Games Podcast helped me put words to something I think about often. One of the things I do at work constantly is think of what I'm doing from the user's perspective. I ask simple questions like, "How does this affect User A's workflow?" and, "Why would User B care about this or do that?"
David Sirlin gave me a word/phrase to wrap these questions into. He talked about User's Intention. He talked a lot about it using Starcraft 2 as an example (and also the original Starcraft). One particular section was talking about the behavior of the workers (SCVs, drones, and probes).
In the original Starcraft, you start out with 4 workers just sitting there be your main building, but the first thing you are going to do is just send them to collect minerals. That is also generally what you are doing when you build them as well. In Starcraft 2 these workers automatically go to collect minerals. Instead of having to select these units and click on a mineral to harvest, they will just go do it. Stop and think about why this is okay and a good idea.
When a user creates a worker, it's main purpose is to collect minerals. It's the player's intention. Don't make the player waste time clicking and selecting a mineral patch. Instead let the player use their brain on bigger, more important tasks.
Another interesting point made is that don't make the player go through these extra steps that everyone has to do anyway. Essentially, let them get to the meat, and let them do what they intend to do. In Warcraft, a player started with having to build their main building with one worker. After they finish building then they can start collecting minerals and building more workers. Fast-forward to Starcraft, Blizzard no longer makes the player build a main building, and they give them 4 workers. Then in Starcraft 2 they start you with 12 that start collecting minerals immediately without player intervention. They iterated on a concept to get the users playing the actual game faster.
These are all things that grew based off of understanding the actual intention of the player/user. This works in regular software development as well. If you can understand what the user intends to do, then you can simplify the process and clear away the useless parts they don't need. Think of the software that you use and the games you play. Are there a lot of things that make you waste time in "setting up the board"? It's why Microsoft Word has the ability to create template files. No one wants to setup the same file over and over.
As a developer you can't lose sight of the fact that actual people will be using your software. You must understand your use cases and the user's intention to make an effective product. It sounds easy, but it's a constant self-check. It's so easy to get tunnel vision and say, "That problem is solved." If you don't understand the bigger picture you can't determine that what you are doing is actually right. What makes sense to you may not make sense to your users. Check your assumptions and go the extra mile.
