Meet Jon. Jon is a first adopter (early consumer) of a startup that's trying to design a better way to roast salmon using a toaster oven. He’s a smart 35-year-old working professional. He spends his evenings answering work emails and watching Dora the Explorer with his two young daughters.
As a designer working for this startup, your task is simple: make Jon’s salmon roasting experience out-of-this-world amazing.
What do you do?
Two ways to approach designing for what you don’t know
There are a couple approaches you can take to start designing around gaps in your knowledge about a certain market or customer. I'll walk you through both approaches—and discuss some of their drawbacks—below.
1. The Prescription Approach
Your first approach to understand Jon's needs would probably be to jump right in and do problem research. Interview Jon to understand his salmon preferences. Does he like it overcooked or undercooked? How big of a filet does he like to roast for dinner? How often does his family eat salmon? Do his daughters ever complain that the salmon is too thick, thin, salty, or bland?
All good questions and insights. But as a designer, once you're armed with knowledge and context around the problem, you have to ask yourself if you now know enough about Jon's problem to prescribe what you believe will be an ideal experience.
Most designers will answer yes to this question. And what results is a toaster oven so perfectly tailored to one specific use case that any deviance in the user’s needs or wants results in catastrophic failure.
For instance, maybe Jon said he wanted slightly overcooked salmon because his daughters were afraid of raw meat. Then he had a date night alone with his wife where he found that chewing rubbery salmon for two hours didn’t make for a splendid evening, even when paired with a nice Chardonnay.
You might think any designer in their right mind would have realized users have different preferences for different situations. Thus, you might think designers would never design a toaster oven that tries to prescribe “the best” process.
And yet, that’s what the designers of June did: cue the $1,500 toaster oven.
Aside from the many technical problems with the product, I would argue that the largest issue was simple: designers assumed they knew exactly what users wanted.
“Automated yet distracting. Boastful yet mediocre. Confident yet wrong.” — Mark Wilson, Fast Company Don't blame this type of mess-up on your users
You could say this mistake is on the user. Jon said he wanted his salmon slightly overcooked, so that’s what he got. And yet, Jon found that he’d said something he later realized he didn’t mean.
Users aren’t omniscient. They can—and will—emphatically declare things that simply aren’t true, even about their own habits.
Not only that, but as you talk to more and more people, there are many cases where users' preferred outcomes vary depending on the situation. You are absolutely at liberty to make the definitive claim that a prescriptive approach is best. But if that's the approach you want to take, you'd better be sure you really do have enough insight into your users' needs and wants, or else you’re in for a rude awakening.
The June. It knows what kind of food is in it, and also how you like it cooked. Supposedly, anyway.
At the end of the day, users simply won’t use an unusable product. If you ask your users to read a 500-page manual to operate a toaster, for instance, they might choose not to purchase it because it’s too difficult to understand.
Sometimes we all need a bit of a reality check. Designers need to acknowledge what they don’t know (which is a lot) and flag that as a risk to be mitigated.
So when should you use a prescription approach to design?
Once you peg an assumption as risky, you can design around it. The danger lies in being “pretty sure” and filling in the gaps. But sometimes there’s nothing to suggest how you should actually fill them.
When use cases are clear, we can tailor a specific flow that’s optimized for the outcome we know users want. A prescription approach is the best approach if we are confident that we know what those cases are and what percent of the population they represent. For the other cases, there’s another approach.
2. The Platform Approach
In economics, there’s a concept known as price discrimination. It sounds complicated, but it’s really not. All it means is that companies can make the most money if they charge customers exactly the maximum they’d be willing to pay.
There are various ways of doing this, of course. Car salesmen use “first degree” price discrimination. They haggle with you until you both agree on a price and are red in the face. In this case, the salesman figured out the highest amount you were willing to pay, then gave you a great offer to match.
Except there’s a problem with first degree price discrimination: it relies on the company’s knowledge of exactly what their customers are willing to pay. What happens if they don’t know?
Here’s where second and third degree discrimination come in.
Companies can set their prices too high and lose you as a customer, receiving a total of $0. Or they can put out different kinds of offers to let users determine what they want. Take the sale of toilet paper as an example. Does Charmin know exactly how much toilet paper different people need? Nope. But they have a six-pack, 12-pack, and sometimes even a 48-pack (my favorite). Whichever category their customer fits into, they’ve got something for them.
Don’t know what users want? No problem.
The key is for the designers to admit what they don’t know. Once you do that, you can design around the gaps in your knowledge.
Case in point: search results. This design pattern is everywhere. The inherent nature of search is that we have a general idea of what the user wants but nothing specific. If we don’t specifically know what they want or aren't confident about it, we can take the platform approach: provide a bed of utility that users can self-select into.
Go to any e-commerce site and test out their search to see how this works.
Amazon.com’s homepage search tries to suggest categories. Many products will not only provide a platform approach for you, but they also try to figure out as much about you as quickly as possible. Once they know your preferences (based on your behavior), they can prescribe a specific experience tailored to you.
Remember the story about the pitfalls of interviewing users? What better way to know if Jon really wants his salmon overcooked than to give him multiple options? Push him to self-select into the situation he’s in as early as possible in his salmon-roasting journey. Then, once he's categorized himself, prescribe the solution.
For example, a possible solution could be to ask Jon , "Are you on a date night? Or are you cooking for your kids?" Once he self-selects, the oven can automate from there.
A note of caution
The toaster oven example is a very obvious one. A regular toaster oven gives us all the cooking options we could ever want. Designers realized they had no idea which options we would need and when. So instead of trying to be overly prescriptive, they sat back and let the user opt into the experience of their choice.
We laugh and dismiss the June failure as an amateur mistake, but I can’t stress enough how often this point of judgement surfaces.
My own experience with mistakenly using a prescription approach instead of a platform approach—and what it cost me
A few years ago, I designed an app that helped grocery shoppers figure out what to buy. All the user had to do was select preferences like how many meals they wanted and what cuisines they liked. The app would then spit out a set of recipes that all shared similar ingredients, telling you how much of each to buy. It sounded great on paper. You could even swipe to replace recipes on that list, and the new recipe would still share the same ingredients for efficient shopping.
But again, the app was too prescriptive. I kept tunnelling in on designing the ideal experience for the ideal user. I lost sight of the degree of variance that came with all the user interviews I was conducting.
A good effort but an ultimately flawed design
As a result, I designed an inflexible system. Users would have a great time until some small deviation in their plan happened that rendered the app too difficult to use.
For example, after a user had found the five recipes they wanted to cook that week, a friend might call and ask them out to dinner on Wednesday. The user would then have to start the process from scratch. This difficulty wasn’t something I discovered during my preliminary user interviews.
Designers, be prepared to pump the brakes on automation
If you read the headlines of technology today, you’re likely to come across automation topics like AI, machine learning, bots, etc. Technology is incredibly powerful. Everyone is giddy with excitement when considering all the value that can be added to people’s lives.
While engineers and businesspeople fawn over amazing ways to automate life, designers need to be the voice of caution. Do we really know exactly what users want to the point where we can automate it? Or is a platform approach better, letting the user self-select the value they want?
It’s easy to fall into the trap of throwing around a powerful weapon like machine learning without knowing where to point it. In a likely scenario, we’ll end up wasting time, money, and human effort on something that should be left to the user.
I always preferred my salmon pan-fried anyway.