Don’t ask your users to design for you
My first UX design job was at a SaaS startup. As in many startups, the main challenge was finding product-market fit, and as in many startups, the strategy was to ask companies with deep pockets what features they would like us to build for them. Sometimes, this was done through Sales meetings. Other times, the team would reach out to existing users at large customers for proposals.
This approach to research is common across orgs with low design maturity. What easier way to get “validated” insights than to get the customers themselves to tell you? Now we can just build it and watch the metrics and revenue go up.
Except it didn’t work out that way, for us or for anyone else. After a few “user-centered” releases like that the CEO soured on the entire concept of research. Users don’t know what they want, he said, because we built it and they’re not paying for it.
The user is not like me
There is an old anecdote that goes something like this: A city ran a survey in one of its suburbs: should we build a train station here? The response was a resounding yes. But once the station was built, it got practically no traffic. When the city followed up with its survey respondents, they all admitted that they supported the train station because they thought their neighbors would use it, and therefore there would be less traffic when they drove to work.
The moral of the story is: while individuals are experts on their own pains and needs, they are not going to do a good job of generalizing for the overall population. Users are not professional researchers; they don’t have the training to do this and it’s not their job to do this. Outsourcing your research to your users is not only ineffective, but also unfair.
Your users also don’t have any insight into the system as a whole; what is possible and desirable for your company to build. At best, their ideas will achieve only local optimization. At worst, they will ask for feature bloat that interferes with other workflows and degrades the user experience.
The plural of anecdote is not data
Research only works if you take a systemic approach to it. Relying on Sales, Marketing, Customer Support, or other “user proxies” to gather feature ideas and then act as the “voice of the customer” is not only constrained by the user’s limited visibility, but is also going to be affected by the proxy’s own biases (often, saliency bias or recency bias) and personal incentives.
A customer saying “what we really want is X” or “competitor Y has this feature, can you add it?” is not a feature request. Rather, it’s an excellent opportunity to start some research. Ask them — what goal will this feature help you achieve? What do you do today, without this feature? Can I talk to the people who would be using it to understand their perspective?
Take the answer, and file it away. Follow up with other sources about their goals and problems (without ever asking “would you like us to add this feature”). When you have enough data, bring the team together and go through a synthesis process for distilling actionable insights out of that data. And then let your designers do the job of finding the system’s global maximum.
