How to make great design decisions

You’re paid to make great design decisions. But how?

As a UX/UI/Interaction/Product designer, you’ll be confronted with design decisions day in day out. Some of these decisions will have huge implications, some of them little. They often all start the same way though:

1. A team member suggests an idea (“I think this step in the flow is unnecessary”)

2. A customer suggests an idea (“can you make an app instead of a website”)

3. Your manager strongly suggests an idea (“Make this button blue. Now.”)

4. Nobody suggests anything and they’re all just waiting wistfully for your sage advice on what to do next (not likely!).

It can be scary — particularly since your value to the company often has a colinear relationship with your ability to make the correct judgement calls! The more often you’re right about something or make a good call, the more quickly you’ll be promoted/given more responsibility. 

So the stakes are high. What then is the best way to systematically ensure that you are making great decisions? I’ll offer a framework that has proven to work well for me and for the designers I’ve coached.

When presented with a design decision, follow these two steps:

1. Reduce the problem to first principles

2. Choose a direction based on the expected value

Let’s start with the first step.

1. Reduce the problem to first principles

*if you’re already familiar with this, feel free to skip to step 2.

Much has been written about first principles, you can read more about it here. But the long story short is — when people suggest ideas, they’re suggesting solutions. Your job as a designer is to peel back their intentions to make sure the solution is a good one.

For starters — you can’t possibly understand if the solution is a good one unless you first understand the problem.

Tactically, there are many ways to accomplish this. You can look at the Jobs To Be Done, you can ask the 5 why’s, or you can simply question whether the statement made or idea presented is in fact true or is just an assumption. 

Here’s a simplified example:

1. A team member (Jane) suggests we change a dropdown to a tab instead.

2. You ask why.

3. Jane says she received a customer complaint that the dropdown was confusing.

4. You ask what about the dropdown was confusing.

5. Jane says that the customer, after selecting an option from the dropdown, wanted to revert the dropdown back to the null state (empty value), but couldn’t.

6. Great! You’ve now drilled back to the first principle of the problem. It can’t be debated, this is simply what happened.

Now, let’s consider the range of solutions and ideas based on the expected value.

2. Choose a direction based on expected value

Expected value is a way of making a decision based on incomplete information. I’ll skim just the parts of the concept that are relevant to this post, the rest you can read about here. 

I’m not expecting any designer to actually do real math — after all, if you’re anything like me, math may be your Achilles heel. But you can still apply the concept without ever having to conjure up a number. In the previous situation above where your well-intentioned colleague suggested something, you’re faced with a decision.

I used to have nightmares about this thing

Frankly, you don’t know for sure if changing the dropdown to a tab will work. So what do you do? Well, with the expected value framework, we’re given the answer. 

Multiply each of the possible outcomes by the likelihood each outcome will occur, and then sum the total values.

In layman’s terms, figure out the risk/impact of each of the decisions you could make and multiply that by your best guess as to how likely they are to occur. You can sum it up at the end but for our purposes it’s not strictly necessary. 

Here’s a simplified version of how that would play out. From the example above, let’s say there are 3 possible routes we could take:

1. We change the dropdown to a tab

2. We leave the dropdown as is

3. We brainstorm something else

First, we look at what may happen in each scenario. What’s the risk of changing the dropdown to a tab? What’s the cost of brainstorming else? 

Then — we can do some mental math (not real math, again) to just quickly assess what the likelihood of each outcome coming to pass is if we made that decision.

1. We change the dropdown to a tab

• It’ll take the engineering team a day or two (highly likely)

• It will solve the problem for this person (not likely?)

• Could also screw up the workflows of other people (moderately likely)

2. We leave the dropdown as is

• Takes the engineering team no time at all (highly likely)

• Won’t solve the problem for this person (highly likely)

• This customer could leave, and it’s a big customer (not likely)

3. We brainstorm something else

• We have to rally the team together to brainstorm which takes time (highly likely)

• Could have a chance of coming up with something amazing though that solves everything and could be really quick for engineering to build. (highly likely)

Note — this isn’t a pros/cons list. It’s an evaluation of what could happen, weighted by the likelihood of it happening. 

You can see that by thinking this way, you start to get a sense of what would be the best route to take. Even though yes you could leave it as is and the customer is unlikely to leave, ifhe or she leaves it would be disastrous for the company. Even though you’re unlikely to brainstorm a win-win solution, it won’t take much time to try and if you do find something it’d be amazing! 

Maybe brainstorming for a day could actually be the best route to take. 

On building confidence

Identifying an outcome isn’t too difficult — if you make a large change, a customer could leave. Or, he/she could stay. 

Assigning a likelihood that the outcome will come to pass on the other hand, is much more challenging. Just because it’s challenging however doesn’t mean it’s not a worthwhile exercise — the more you exercise this muscle the stronger it will get. 

You may have noticed in the example above, I assigned a high likelihood of being able to brainstorm a solution that both solves the customer problem and is very easy for engineering to build. But how would one go about knowing this?

Here are some ways you can build your confidence on whether an outcome is likely to happen or not:

• Use data, any data. Quantitative, qualitative, behavioural and attitudinal data are all tools in the kit that can help inform your gut. Sometimes simply sketching on a napkin and throwing it in front of the user in question could give you a much stronger intuition on the likelihood of one outcome over another.

• Leverage common knowledge. Look up Nielson Norman studies, look at other companies/teams/products who have made this decision — how did it work out for them? 

• Leverage your experience. Have you done a lot of user testing in this one area? Maybe that can help give you confidence that one outcome will occur over another?

There’s no perfect manual to get it right 100% of the time, but hey — that’s why you’ve got a job! If it was easy to automate this process, designers wouldn’t be necessary. 

Now that you understand the process by which you can arrive at the best decision however, the onus is on you to constantly refine, identify, and predict outcomes so that you can always have the best chances of success.