Two Fundamental Approaches to Designing UX

The Prescription vs The Platform

Picture 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 smart, 35, and a working professional. He spends his evenings answering work emails and watching Dora the Explorer with his two young daughters.

Now, as a designer working for the startup, your task is simple: make Jon’s salmon roasting experience out-of-this-world-amazing. What do you do?

Design for what you don’t know

The first answer would probably be to jump right in and do problem research. Interview Jon. Ask him about 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, all good insight. But there comes a critical junction in the decision-making process of the designer. Once he or she is armed with knowledge and context around the problem, the question that slowly starts rearing its head more and more is:

Do I now know enough about the problem to prescribe what I believe will be an ideal experience?

1. The Prescription

Many times the designer will answer yes. What results is a toaster oven that is so perfectly tailored to one specific use case that any deviance in the user’s needs or wants results in catastrophic failure. 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 salmon-rubber for two hours didn’t make for a splendid evening. Even when paired with a nice Chardonnay.

Sure, any designer in their right mind would have realized that the user has different preferences for different situations. Designers would never design a toaster oven that tries to prescribe “the best” process.

And yet, that’s what they did — cue the $1500 toaster oven. There were many technical problems with the product as well. But 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

It’s the user’s fault!

You could say that it’s the user’s fault. Jon said he wanted it slightly overcooked, so that’s what he got. And yet, Jon found that he’d said something that 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 their preferred outcomes vary depending on the situation. You are absolutely at liberty to make the definitive claim that a prescriptive approach is best. But you had better be damn sure that you really do have enough insight into their needs and wants or 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.

Even if you blame the user, at the end of the day if they can’t use it they won’t. If you ask your users to read a 500 page manual to operate a toaster, they might choose not to purchase it because it’s too difficult to understand. So whose loss is it?

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.

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 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. This 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

In economics there’s a concept known as price discrimination. It sounds complicated, but it’s really not. All it really 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 going about doing this, of course. Car salesman use “1st degree” price discrimination. That means they haggle with you until you both agree on a price and are red in the face. In this case, the salesman figured out exactly the most you were willing to pay. Then he gave you a great offer to match.

Except there’s a problem with 1st 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 2nd and 3rd degree discrimination come in.

Companies can set the price too high and lose you as a customer (and receive a total of $0). Or, they can put out different kinds of offers to let the user determine what he or she wants. For example, airlines had a hunch that there were a group of users who had more money and were willing to spend more for nicer seats. Hence, they offered business class.

All of a sudden, customers can self-select into what’s ideal for them. 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 6-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.

Sound familiar? The key is for the designers to admit what they don’t know. Because once you do that, you can then design around it.

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 we’re not confident about it, take the Platform approach. Provide a bed of utility that the users can self-select into. Go to any e-commerce site and test out their search.

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 fast as possible. Once they know your preferences, based on your behavior, then 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 by giving 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 has categorized himself, prescribe the solution.

For example, a possible solution could ask Jon — are you on a date night? Or are you cooking for your kids? And once he self-selects, then the oven could 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 realize they have no idea which one we would need and when and so instead of trying to be overly prescriptive they sat back and let the user opt-in.

We laugh and dismiss it as an amateur mistake, but I can’t stress enough how often this point of judgement surfaces.

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. Then the app would 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. But 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. This would render the app too difficult to use.

For example, after a user had found the 5 recipes they wanted to cook this week, a friend might call and ask them out to dinner on Wednesday. The user would then have to start the process from scratch. That just wasn’t something I discovered during the preliminary user interview.

Designers, beware the age of 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 considering all the value that can be added to people’s lives.

While engineers and business people fawn over the 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, and we take it from there? 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.

Join me for weekly product design insights where I share conversations I’ve had with top designers from companies like Dropbox, what I’ve learned from scaling a Series A startup into the millions in revenue, and more!