What is the end goal that I’m trying to reach?
This needs to be answered clearly. If the goal is to create a simple calculator, then the focus should be on ease of input, and accurate output. It doesn’t need to have themes, that’s a distraction that doesn’t add anything to the program. Let the theme be inherited from the operating system and focus on the primary goal.
Software is a Tool
It doesn’t feel that way to a programmer, but to the average user, even “tech savvy” ones, software is just a tool to use. Whether its a game (a tool they use to relax), or a word processor, or an email client, software is a tool. To you, the programmer, it may be an expression, but the end users won’t see it that way and won’t care. Its a tool.
Just because you can, doesn’t mean you should
In fact, it probably means exactly the opposite. If you think your calculator program needs to be able to have customized backdrops in the answer window, it might be time to look back at the first rule. Does it really add anything of value to the program?
Make things only as complicated as they need to be, and no more
This one is a tough one. If the program is for you, and you alone, it can be as complicated as you want. If it is for other non-programmer types of users, things must be laid out logically in a way that they can use and understand.
Avoid pages of of options that nest three layers deep. Most of your users will never get past the first page of options — if they ever go into the options more than once. Most users will explore, but just a little bit. Once they start using the functionality, though, chances are is that they’ll never go back to those options again.
You see the software as a puzzle and a labor of love, and possibly have a deeper bond with the code than they ever will. The code is a part of you, an extension of your mind and thoughts. To them, its a tool. It needs to work and they don’t care how, nor do they care what it may or may not mean to you.
People Hate Change
Unless you’re a programmer or a tech enthusiast, most people don’t like to learn how to use their tools over and over again. Choose your initial design carefully, because deviating from it repeatedly will alienate your user base. Windows XP is the perfect example of this. There are still millions of computers out there running Windows XP and the users don’t see any reason to change. And why should they change? They’re familiar with it, it works for them, and they know how to use it. Upgrade from Windows XP to Windows 8? You have a very unhappy user there.
If its an upgrade, make sure its not too radically different, if it is, provide a way to make it feel like its predecessor
This is the one Google screwed up in big time with Android 5. Android 5.x has a radically different look and feel than Android 4.x. This itself isn’t a bad thing, but if you’re upgrading, you should make sure your software behaves mostly like what the user is coming from or they’ll get frustrated with it. Remember, software is a tool and users hate change.
Retraining employees is expensive for businesses and people don’t like change, so if you make things too different, no one will want to use it and you’ll reduce your sales or installed user base.
Your software should be able to have the look and feel of one major release behind it. It doesn’t have to be 100% identical, but similar enough that the user is comfortable with it. So, for version 3, it should be able to look very similar to native version 2. Version 4 should be able to look like native version 3 (not emulated version 2, but the native version).
If possible, give the users a clear choice when they upgrade. Ask them what they want to do if at all possible.
If its a fresh install, give them the vision you intended
All bets are off if its a brand new installation of your software. Make it look like how you think it should. Since its not an upgrade, you’re not forcing them to change from something that they’re comfortable with.
Listen to the users when they give feedback
I’ve seen this one not happen repeatedly. Your users are your customers, the ones putting a roof over your head and food on your plate. Don’t just dismiss them because they’re not in control of your software. They are in control of your software, they’re the ones using it, and they can stop using it.
You’ll get a lot of really idiotic comments from users once things go into the wild. They don’t understand these guidelines and if you listen to all of them, your software will turn into Frankenstein’s monster. See the rules above about it being only as complicated as it needs to be, and just because you can, doesn’t mean you should.
You will get constructive comments in with the “you suck, your software sucks, and I hope you get an STD” garbage. Those are the ones you need to watch for and be mindful of. They’re the ones who will show you the roadmap for your software that will help it be successful.
I realize that for a lot of software, particularly web software, that not all of these are possible. I’ve spent the last 16 months rewriting a large project that breaks several of these rules, but mostly just in the web interface. I did, however, try to keep all of the current functionality grouped logically together and easy to use, but I know that someone is going to wish an STD on me when it finally releases.
