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:
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.
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.
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.
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.
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.
