As designers, regardless of craft, it’s our job to advocate for, and empathize with the user. However, that doesn’t imply that we bend to the user’s every wish.
Applications or products that respond to expressed or implicit needs of a user drastically increases its potential for adoption.
Conversely, applications or products that respond to every expressed or implicit need of a user drastically decrease its potential for adoption.
The mobile application market is a shining example of how this pattern tends to work.
Application A aims to solve a small handful of the users’ expressed or implied needs, and limits its features by that constraint.
Application B aims to solve a small handful of users’ expressed or implied needs, and opens the flood gates to user generated features.
At first blush, many of us would applaud Application B for listening to users’ requests by adding more “value” to the application with each feature. However, upon closer evaluation, Application B may be building itself into extinction.
I think this quote and graph explain this quite nicely.
Create more and more features, for fewer and fewer people, until we’ve created everything for no one.
- Neil Martin, IDEO London
Know When To Say No
Knowing when to say no to a user can be complicated. I’d like to offer a few simple ideas that can help filter out the onslaught of feature requests.
- Have a product vision.
Having a product vision gives you a clear picture of what the application is, but also, what the application is NOT. Knowing what it’s not is often the missing key.
- Measure requests, don’t react blindly to them.
Knowing how many requests, who made the requests and how often the request was made can give you insight into actual value.
- Dig deeper and understand motivations.
Quite often, there is little value in turning a request into a feature. Taking the time to understand the users’ motivations for making the request can yield a variety of solutions that can potentially deliver a more meaningful engagement.