Setting a UX Design brief

Aug 3

by Marvin Cheung, Head of Research and Strategy

Design is an iterative, hypothesis-driven process. Through preliminary research, you want to narrow down the set of hypotheses you want to test. The first step is to understand the problem space. There are several things you can do, for example:

Read through articles from online sources, eg. Google Search, Quora, other discussion forums. What questions are people asking?
Read through articles from academic sources, eg. on JSTOR. Has the problem been well researched?
Go through social media, eg. meme pages. What is the worst part of people’s experience of a particular problem?
Talk to friends in different industries. Might the solution be applicable to an unexpected target audience? What are some of the early thoughts?

By assigning different weights to different sources, you should arrive at a set of problem statements. Geunbae Lee’s article “Designer’s indispensable skill: the ability to write and present a solid problem statement” elaborates on what a problem statement should look like. Amy Ko’s article “How to understand problems” discusses some of the more technical qualitative user research methods, including user interviews, that can help you set a UX Design brief. People working with existing products will most likely have to work with quantitative user research as well. We will elaborate on user research methodologies in UX Research 101.

Nevertheless, there are two guiding questions behind all UX briefs:

What do we know to be true?
What hypothesis do we want to test? More specifically, what is the most critical hypothesis we need to test?

There are generally two entry points to a UX Design project. They have corresponding hypotheses:

There is a new product, and you have to test the product vision ie. “Do people want the solution we are offering?”
There is an existing product, and you want to figure out “How can we serve User Group X better?”

Practically speaking, a UX brief should have these components:

Problem statement: What is the problem you are trying to solve?
Goal: What are you optimizing for? Eg. engagement, transactions
Users: Who will use the product? (We will elaborate on Jobs to be Done in the next section)
Stakeholders: Who needs to sign off on the project? Does any regulatory body need to be involved?
Constraints: How might we anticipate and navigate around different limitations?

Throughout the project, you will find yourself refining and iterating on the brief, maybe even scrap it altogether and start a new brief based on the information you discover. That is entirely okay! The goal here is to do as little work as possible to test as many different assumptions as you can. Make sure to keep a log of everything you learn along the way, and all the assumptions you did not manage to test. This list will be invaluable as you continue to develop the product.

As an aside, the main criticism of many spec (speculative) projects in design portfolios is that they do not do enough to reflect the real world challenges of creating a product. Here we want to acknowledge some of the questions that need to be asked beyond “Do people want our product?” but are not within the scope of this course book. Innovation by Design: MVP 101, Product Management 101 will be released soon.

Will anybody be willing to pay for what we are offering?
Will they pay enough to maintain the quality of the new offering?
Will the new product or feature fit into the overall business?
Will it cannibalize the sales of an existing offering?
Will it encourage nefarious activities in any way?
Will it be compatible with the company mission?
Will it require expertise that will be very difficult to hire for?
Will the additional work be fulfilling to the team in the long term?

Setting a UX Design brief

Know the field: Competitive Analysis, Mobile-first Approach, Information Architecture, and Jobs to be Done

The Atomic Design Methodology: UX Design in an ideal world