The end goal for any smart software developer is to create something that the users enjoy. It matters little what the software does as long as people like using it. Happy users generate a lot more money for you than any amount of measurable utility will.
Making your users happy can be a lot more complicated than it sounds. You'd think that you could just ask them what they want, and then iteratively ask how things should be tweaked, but this can lead to disaster. There are two main reasons to avoid letting your users design your software for you.
Most people aren't creative enough
If you asked someone what they liked or didn't like about a software experience, their feedback could be very useful. However, if you ask someone what could be changed to make it better, you're taking them way outside of their element. Most people think of new experiences by using old experiences as a point of reference. When they give suggestions, they will think of ideas that they've already seen before.
Developing great software requires some sort of innovation and you just won't get that from asking random users for feedback.
Everyone is different
Designing features to make one or two people happy will almost certainly lead to an improved user experience for those people. However, because everyone has different needs, you may end up cluttering up the system for everyone else. You're the only one with enough perspective to make the tough decisions. Some users might be screaming for a feature but you know that your overall customer base would just find it confusing or distracting, so you have to say "no".
So what should you do?
I always value the feedback of users or co-workers that aren't experienced with the creative design process. The way I keep this feedback under control is to make sure I ask the right questions. These questions are:
- What do you currently not like about the software?
- What problems could this software solve for you that it isn't already solving adequately?
Notice that both of these questions focus on the user and not the design of the software. People know their own experiences. If someone hated a certain page, that's great feedback. If they wish the software would help them stay organized, that's also valuable to know. The important thing is that the way I phrase these questions leaves it up to me to translate them into actual solutions.
I'm not asking how a current page could be made better, I'm just asking which ones are causing problems. I'm not asking for the user to suggest features, I'm just asking for problems that I can solve by designing my own features. I'm (theoretically) good at designing things, so the user is better off letting me do my own thing.
