I just released my first ever application into the world and asked for feedback. I was surprised by the feedback, because the users are asking for a lot of detail. They seem to want a user interface filled with buttons, knobs and sliders that lets them tweak every little thing to their desire. Everything I've read about usability tells me that this is exactly what to avoid, but it is what the users are asking for.

So I'm trying to figure out if I should give the users what they are asking for, or if it is typical for users to ask for more detail than they really want.

5 Answers 5


While you may have a large number of total suggestions, I think you’ll find that most unique suggestions come from a small minority of users. This is typical for an application once it’s released to the wild –users will start using it for multiple different things beyond its core capability, and will thus want more features and flexibility to expand in all directions beyond the core. It’s a case of 90% of additional features being used by 10% of the users, and it’s a different 10% for each feature. The net effect is that users as a group appear to be asking for a lot more detail. In reality, each user is only asking for one little bit more detail.

The sad part is that users generally cannot appreciate the usability cost of unwanted features. If you gather 10 users together to discuss improvements and only one wants a control to adjust X, the other nine won’t object because they’ll figure one more control can’t hurt. This is what leads users to buy over-featured unusable devices. All they see is the bullet on the package for the key feature they want. They don’t understand the harm that comes from supporting all the other bullets.

Beware the silent minority (or majority?) that is happy with the way things are. Almost no one is going to say, “Don’t you dare change anything. That’ll just confuse me.” Be careful about a small number of users dragging your product out of its intended niche of users. Maybe some of your users are better off using a more suitable product from someone else.

Finally, beware statements from users on what they say they would do (“Oh, yeah, I’d fine-adjust with the dilithium ratio all the time if I could”). These have a weak relation with what they actually do when the time comes. The only way to tell is to test a prototype of the feature before deploying it. Such testing should also include user regression testing of core capabilities to assess if the new feature is interfering with them. Even if some users truly use the detail, maybe it isn’t worth it.

Bottomline: you should expect to reject most user suggestions, at least in the form they are suggested.

But that doesn’t mean you should ignore the feedback either. In your case:

  1. Rank the unique suggestions by the number of users asking for it. Top-ranked suggestions are top candidates for implementation, although you can’t assume that if the majority of responding users want a feature the majority of all users want that feature.

  2. Find out why the users want each feature. If you can ask the users, ask them. Otherwise, try to tease it out of other data you have (e.g., hit logs). It may be necessary to do additional research. Maybe you already support the users’ goals but they didn’t realize it, and the solution is better discoverability or documentation. Maybe they don’t want the flexibility to adjust X, but instead really need X hard-wired to a different value. Maybe you can find a different way to accomplish the goal without adding complexity or clutter.

  3. Knowing the goals, see if you can combine top features into one simpler feature. Maybe certain details are highly correlated so you can combine them into a single control. Maybe you can abstract the feature to a higher level (instead of 32 different settings, have only 5 settings than may be combined in 32 different ways). Maybe you can automate the settings.

  4. Design the feature UI to be consistent with other elements of your product’s UI and with the overall vision for the product. Maybe users have a great idea, but it’s from their experience with another product with very different conventions. You can’t just plop it into your UI.

  5. Once you determine the true features to add (if any), consider methods of progressive disclosure so the 90% of your users that don’t need Feature X are not disrupted by the 10% that do. For example, you could allow users to select controls to appear on their dashboard on demand.

I’ve more on increasing capability without complexity at Simple Simplicity.


This is the kind of feedback that is the easiest to elicit from users - details on color choice or extra features.

I think the "intention" part is the important one. The problem the users are trying to solve using your application. So if you have any way of contacting the users who has given you feedback - or even just a radom selection of any of your users, you might find the answers to this question relevant: How to discover what users NEED and not what they WANT?


Actually, it is perfectly normal to receive very little feedback. So it's good you're hearing from your users.

Try to organize these requests, filter them, prioritize them. You don't want to do anything to jeapordize the usability of your application. Some requests you'll simply have to say no to, but there may be others that are worth implementing. Try to find the intention behind these requests. Many times someone will state the problem they're trying to solve and suggest a solution. Their solution may not be the best one, even if their problem is valid. So it's your job to find the most elegant solution.

Also I'd consider signing up with a site like Uservoice or GetSatisfaction. Then your users will be able to vote on feature requests, and that'll more or less prioritize your work for you.


Bear in mind that the people who feedback are a self selecting group who want changes. There may well be another, larger, group who are perfectly happy with your original interface, and may become unhappy if you start adding lots of extra controls.

The only way you'll know whether this is the case is by organising some proper user research.


When users give feedback, they are saying that there is an issue. It's your task to discover what they 'need'. To discover that, you have to ask the 'why' question loads of times. Why do you want that button? Why is that important? Why are you trying to do this?

After asking loads of questions, you'll need to test new designs to make sure the interface changes slowly (Interface changes are always hard to digest), and to make sure these changes are really useful.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.