Design the right thing first: How to write a UX design brief

There’s more to great UX design than what you see.

In fact, there is incredibly important work to be done long before you even open Figma.

One of the most powerful skills in design is being able to distill multiple inputs and constraints in a way that project stakeholders can mutually agree on so that there is complete alignment on what needs to be built.

Enter the Design Brief: The holy grail of creative documents that are far too often created half-heartedly.

In my 10+ years of designing, I’ve seen briefs that range from good to completely useless. When done right they minimize surprises, accelerate projects and maximize alignment and buy-in on what needs to be done. When done wrong, it can lead to nothing short of chaos and confusion.

That’s why I’ve mapped out the 6 foolproof steps to creating a design brief that doesn’t suck. Rather, it will ensure you nail your design, can speed up the project, help it run smoothly, and might even win you brownie points with your team.

Step one: Define the issue in a problem statement

One of the easiest ways to build something bad is by not figuring out what problem your design is aiming to solve and why the solution is valuable to your user.

It’s equally important that everyone on your team is aligned in their vision of which problem to solve. I’ve experienced meetings with seven people where I asked everyone to define the problem we’re solving, only to get 7 different answers back.

If a group of people can’t agree on a problem, how are they going to agree that a solution is right? Creating a problem statement that everyone agrees with is the only way to get buy-in from all stakeholders and is the only way to ensure you build a product that brings value to your users.

To define your statement start by asking:

• Who are the target users and what are their goals?
• What is the biggest problem area identified in our user’s feedback?
• How do we know this is a real problem?
• Why is it important to solve?
• How will we know if we’ve solved the problem?

Go through these questions with a team and narrow down responses until you have an agreement on the specific problem. Next write a statement that outlines who you are solving for, what their problem is, why it’s so important to solve it.

You’ll see that this step also helps you remove unrelated feedback from the mix which will help the design process run more efficiently down the line.

Step two: Define your project goals

Outlining your project goals will ensure you don’t diverge from your project’s success (don’t worry, you will soon be outlining a success statement too).

Your goals need to be specific. They should outline the key results your design will produce not only for the user experience but for the business as well.

To create goals, ask your team:

• What specific outcomes do you want for the user?
• How is this relevant to the user or business?
• By when should this goal be achieved?
• How will success be measured?

Generate answers to these questions from both a user experience as well as a business standpoint. Gather input from your team and then choose the top two or three goals that everyone agrees on.

Step three: Write out your ‘success looks like’ statements

Success statements provide a concise way to communicate your team’s vision for the ultimate project win. They also ensure that beyond just defining the problem, everyone is aligned with what the desired outcome of the solution should be.

Further, success statements help you uncover any further unalignment amongst your team. After all, if everyone has a different vision of success, you know you have some more work to do to get everyone on the same page.

These statements can be written as simply as “success looks like…”. Similarly to creating your goals, consult with your team. Once everyone has contributed their version of success, compare all statements to ensure there is alignment. Perhaps one statement will rise as the main version of success that everyone agrees on or a new statement will be written that is a conglomerate of one or two.

Step four: Identify your design principles

This is my favourite step and is the one that gets the most reaction from stakeholders.

Similarly to how you need to get alignment on what problem to solve, it also helps to have alignment on HOW you will go about solving the problem.

Design principles are a set of statements that define the method in which you are going to design the solution. This isn’t to say we are defining a solution here, rather the approaches and principles that you are going to abide by.

The way I usually do this is by first thinking of what the ideal design solution might look like. From there, I work my way back from that solution and write down all the features and the purpose for including those elements in the design. To learn more we’ve got a whole article on creating design principles here

This step helps articulate WHY you arrived at the solution you came to and helps everyone evaluate the design more objectively.

Step five: Create a hypothesis

A hypothesis statement is an “if and then” statement that supports your problem statement.

They can be incredibly simple and follow this equation:

If we [define the solution] then [intended user] will [desired outcome the solution creates].

For example:

If we implement a ‘compare pricing option’, then users will have fewer obstacles in their way when choosing the right upgrade for their product.

This statement is incredibly important if you’re working with a data-focused organization where your solution could affect their bottom line or whenever you need some extra buy-in for what is the value of doing this project.

Step six: Tell your Job Stories

Job stories allow you to identify the exact needs of your user by writing statements from their point of view. These statements should be written to express the situation, the motivation, and the desired outcome for your user.

For example:

“Before I upgrade my account (situation), I want to see what all the options are for upgrades (motivation) so that I can easily compare prices between packages (expected outcome)”

This statement tells you, as the designer, that the solution needs to showcase pricing in a way that allows the user to easily compare what each package offers.

Be sure that your job stories are written based on the feedback you gathered while conducting user research and not something fabricated based on any assumptions. As always, be sure to consult your team when writing your job stories so that you can all be in alignment with what the user wants to be done.

If you’re keen to go deep on learning to write great Job Stories check out this great post from Intercom.

The takeaway

Great design work starts with mapping out a shared understanding of what is being created and establishing alignment on the desired outcomes of the solution.

By writing a design brief that incorporates input from all stakeholders you will outline agreed-upon criteria for success from the get-go, generating investment in the project and more buy-in for what you want to create.

Nail these inputs and you’ll be setting yourself up for great design work, far fewer surprises, less room for misalignment or off-topic project requests. Every. Single. Time.

Your team will thank you for it.

Nick Foster is the founder of Sixzero, an agency that helps companies design apps and software with impact.

Illustration by: Muti, Folio Art