An Idea Isn’t Good Just Because It Came From a User

Cover photo by AbsolutVision on Unsplash

First of all, let me just clarify what I think about centering your design process around your users: You should absolutely do it. No question about it. Talk with them, observe them, test with them, evaluate ideas with them, put them up on the wall (in the form of personas, for instance), and analyze their behavior in your metrics. I’m a huge proponent of all that, whether we call it human-centered, user-centered, or something else.

Design is very much about understanding people’s needs and problems and then developing and marketing solutions to them. Your users know a lot about their needs and their relationship with your product, and you should absolutely take advantage of that. But there are good ways and bad ways of doing this.

‍

What user-centered design is NOT

I see a lot of design teams applying a user-centered approach to their design process. Which is awesome, of course! They do user research, analyze their findings, dig to the root cause of problems, come up with a range of potential solutions, test out a few promising options with users, and ultimately implement the best solution.

However, this process still seems daunting to some. It requires upfront time and resources that some are just not willing (or able) to invest. But they still want to be able to say “We talked with our users so we know this is the best feature to develop.” It’s a great way to argue your case, especially towards executives who hear this “user-centered design” is the shit, but who don’t see why you would need such a luxury as time to actually do it.

So what do we as designers tend to do in situations like this?

Sometimes we simply cut out a few steps of the process. Instead of the approach I mentioned above, our user-centered design approach looks more like: 1) Do user research, 2) develop the exact solution(s) suggested by users. Perhaps with a quick usability test slapped on so late in the development process that the findings won’t really matter anyway. Working at a startup for the past two years, I know I’m guilty of taking this approach a few times myself…

So, did we develop a solution to a problem? Yup. Did we talk with our users? Sure. Did we stay within budget and meet the deadline? Hell yes. Everyone’s happy! Sort of…

‍

Why it’s a problem

The thing is, we’re typically great at coming up with a quick solution when faced with a problem. And then we stop looking for solutions since we already found one! Overcoming this inclination to stick to the first idea is arguably one of our most important jobs as Designers. It’s not the job of our users, however.

What we should do when a user, or anyone else, has an idea for a specific feature, is simply to acknowledge it, take it into consideration when evaluating ideas (plural!), and perhaps ask the person behind it to elaborate. And then you explore the underlying problem. You dig deep. And you get to the root cause. And when you’re confident you fully understand the problem, you’re a lot better equipped to explore potential solutions! Bring the problem to the rest of your team and let them come up with solutions. Have a workshop with your users. Do an ideation session. Consider a wide variety of ideas, pick the most promising ones, test them out, iterate, refine, and ultimately settle on the best solution for the problem.

That’s user-centered design. Or Design Thinking. Or just “good design”. Problem seeking is just as important as problem-solving. Perhaps even more important. So talk with your users about their problems, not just their ideas. Resist the urge to simply implement a feature or design change just because a user suggests it. Instead, see that idea for what it really is: a signal that there’s a problem that needs to be solved. Then go find the actual problem, and come up with the best possible solution for it. Your users, as well as your manager, will thank you.