Don’t design what users want

My job as Head of User Experience at the Mobile Majority is to make sure our mobile marketing platform is easy, intuitive, and helps our users reach their marketing goals.

Without getting user feedback, we’d have no idea whether our product is meeting people’s needs. We get feedback via email, service request tickets, in-person exercises, phone calls, and through our salespeople and account managers.

All this information allows us to understand the pains and frustrations users experience as they use our product and see problems or trends we might have otherwise missed.

But here’s the thing: you shouldn’t design what users tell you they want.  

“You shouldn’t design what users tell you they want.”

You might be thinking, “Aren’t we supposed to build things that delight users and help them reach their goals?”

Sure, but that doesn’t mean you need to build exactly what they ask for.

Too many product designers are in the pattern of simply taking user feedback and implementing it immediately with limited research, questioning, or thought.  

It’s like when a kid wants candy for lunch, but their parents insist on a healthier meal because that’s what the kid needs.  

People in everyday life don’t really know what they need—they just tell you what they think they want. People don’t always do what they say, and they rarely know how they’ll act in the future.

Think about how many people say they’re going to go on a diet tomorrow—and the next day they’re eating a double-bacon cheeseburger for lunch.

This kind of thing happens all the time when someone uses a product. And to help illustrate my point,  I’ve got a perfect example. The following will show you exactly why you shouldn’t always design what people want—you should design what people need.

What the user thought they wanted

One piece of feedback we received was a feature for a user to get an email every single time a specific event occurred for one of their campaigns. Our user wanted to know every time a campaign started, ended, was performing poorly, hit the halfway mark, was off to a bad start, had little traffic, or reached its spending limit.

The emails would have looked something like this:

Now, imagine having 20 mobile campaigns running on any given day and receiving 20-30 emails all within a short time frame. Despite what the user wanted, this would have overwhelmed their inbox with non-actionable items in a non-organized way.

Time to figure out what they really need

Rather than simply do what they asked, I pressed a little deeper. I needed to figure out the root problem and figure out why the user made this request and why they wanted these emails.

I can hear you saying, “But you just said we shouldn’t design what users want.”

Yes, but I’m not trying to find out what the user wanted. I’m trying to figure out why they want it.

“Don’t try to figure out what the user wants—figure out why they want it.”

To do this,  I set up a handful of video chats and in-person interviews.  We distilled all our findings and focused on the user’s one basic need: they simply wanted to know if their campaigns are doing okay.

Yet, as helpful as interviews can be, the best way to get user feedback: watch your user in action. Whether you watch them use the actual product or you watch how they currently perform their task, each observation can give you great insight into what they’re trying to achieve and how you can help them do it.

The biggest insight I found was that our users logged into our platform every morning and would skim the list of campaigns looking for any anomalies. This is something I could use.

We decided to give the user what they needed

So, after learning more about why the user wanted these emails, we decided to build something they needed instead of what they wanted. Instead of an automatic email system, we built notifications within the platform itself.

Since we know our users will be viewing our platform daily, we use this as an opportunity to notify them if anything is wrong and highlight any campaigns as necessary.

We took this daily habit into consideration when we implemented this feature. This solves many of the problems our users mentioned above and further prevents problems that would have happened if we implemented the solution they asked for.

Getting user feedback is the most important thing any UX designer, engineer, business owner, and product manager could do. Watching someone use your product is the best way to get feedback, and it should be done frequently.

“Build what users need, not what they want.”

But don’t just take that feedback and design a solution based on what the user says. Remember, people don’t always do what they say, and people don’t really know what they may do in the future. Carefully consider their feedback, but don’t forget to ask why they want what they want. Dig deeper to figure out your user’s root problem.

Once we showed our users the notification system, they were impressed and confessed they’d never thought of the idea. I know we’re saving them time and hassle—and that feels good.