The power of a UX project brief (template included)

“We need to redesign this ______ (website, app, etc.)”

“We need a new vision for this _______ (product, service, etc.)”

Do we really? Why is it so? What are we trying to improve/fix/solve? For whom?

To find the right direction faster and make the project team more efficient, put your initial assumptions, hard facts, goals, and other relevant information into a written form — a UX project brief. This helps to facilitate meaningful discussions and to get designers, product managers and software engineers on the same page before any research and design activities even start.

Benefits of a UX project brief ☑️

The power of a UX project brief comes primarily from:

1. Reducing ambiguity
2. Making the team think deeper about the key project inputs
3. Helping to discover gaps in the team’s understanding of the project
4. Facilitating constructive team discussions by making things more tangible and specific
5. Reducing inefficiencies by clarifying roles and establishing basic ways of working
6. Enabling much faster project onboarding of new team members later

How it came about 📜

I’ve been using variations of this UX project brief since 2015. We developed the initial version of it while I was a UX designer at Which?, the UK consumer association. I then enhanced it further with our team at the BBC. I’ve been further developing it over the past few years, mainly adding more questions and a few more topics. It’s still fairly simple but trust me, it does makes a big difference.

Here it goes.

Note: Just copy and paste it into your fav tool ⌨️

UX Project Brief

Name of the project

Started on:
Last updated on:

Background

Describe what the project is about, what’s its context and background.

• Why is this project being carried out? What is the motivation?
• Is it a part of a wider customer journey? [link it here]

Prior UX experiences

• Who did you work with before? What was the experience like? Anything you particularly liked or disliked?
• What is your biggest frustration UX-wise at the moment, what would you change immediately if you could?
• What is your biggest like at the moment? What do you think is your killer feature/experience?

Business proposition and competition

(This might only be relevant if you are about to work with a new company/client.)

• What is your vision and what is your brand aiming to represent?
• What is your company/project elevator pitch? Value proposition?
• Who are your biggest competitors? What’s good and bad about them? Where do you want to compete?

Objective

Describe what is the ideal future you want to have once this project is finished.

• What is the outcome you’re looking to get out of this?
• How does this fit into your team’s and/or company’s wider goals? (Link them here.)
• What is the benefit for the business?
• What is the benefit for the user?

Key results & Success criteria

Think KPIs, OKRs, UX metrics, benchmarks, company targets (whatever your company is using).

• How will you know the project was successful once it’s finished?

Target audience

Describe the target audience for this project. You can link to your personas.

• Who is the target audience(s)? Who is buying vs who is using it? How much do we know about their needs?
• Who / where / when / how often is going to be using this / get value out of this?
• Do we have access to this target audience? How?
• Are there any special needs we should be aware of? (slow internet, tech savviness, language mutations, special devices, accessibility considerations?)
• Typical day in the user’s life?
• Customer service / Customer relationship management – how does it work at the moment?

Data

• What data and documentation do we have?
• What research has been conducted so far (what methods)? What has worked well and what didn’t? Why? What did you learn?
• Analytics: current problems, most used paths, what devices and resolutions they used the most, etc., how many users, frequency of use, length of a session
• Quantitative – surveys results, top tasks identified?
• Qualitative reports?

The team and stakeholder map

Define team roles and responsibilities. List stakeholders, subject matter experts (SMEs) and team members and describe what level of involvement is needed/expected. One way of doing this can be a RACI matrix.

• Who is the ultimate decision-maker (sign-off)?
• Any people who are strong supporters/challengers of this activity?
• Any committees we need to go to? [Find out more about the way they work.]

Scope

What’s in scope

Describe what definitely needs to be worked on and why.

What might be in scope

Often, there are those ‘maybe areas and topics’ — list them and describe conditions under which they could be included (e.g. if we have time, if we find out enough evidence in user research, etc.)

What’s not in scope

Describe what the design team should not challenge (e.g. hard technical constraints, change of CMS, major design overhauls during a platform migration project, etc.)
[Note: I use this one more as a guide to understand which topics will be hard to change, which things shall be taken as project constraints, and what the business values as a status quo. However, in practice, if you make some key discoveries which could significantly help the product and you have a really strong rationale for them, everything can be challenged.]

Dependencies

• Are there any other teams, people, technology or anything else that the success of this project is dependent on? Describe them.

Risks

List risks and caveats that need to be considered.

• What are the risks to the success of this project?
• What could go wrong? Why?
• What would happen if we don’t meet the deadline / or if this project is not carried out at all?
• What could not be done if this project doesn’t go through?

Deliverables

List tangible artefacts that this project is expected to deliver.

• What deliverables are expected?
• What will they be used for next?

Timings

Link to a product road map if available.

• What are the currently known deadlines and milestones?
• What is the expected project start date [if filling in before the team is assembled]?
• What is the expected delivery date?
• In case, there is a delay, what would happen?

Ways of working

Team routines

• What will be the team ceremonies and who shall be involved?
• Will you work in sprints? One-week, two-week ones?
• Will you have regular check-ins? Design crits? Retrospectives? Etc. When? Who shall organise those?

Communication

• What communication tools will you use and what for? (Email vs Slack vs JIRA vs Zoom, etc.)

Design, collaboration and documentation tools

• What design and collaboration tools will we use?
• How will we document the project?
• How will we share our work with stakeholders and development?

Shared data

• Where is the project space/folder and all the materials relevant to the project
• Does everyone have access? If not, who will make sure everyone has it?

Budget [if relevant]

• What is your budget for this?
• What does the approval process look like?

Additional notes

If there is something else, specific to this project, state it here.

How to use the UX project brief ✍️

Option 1: Fill in as a team in a workshop or asynchronously

Use this template as a tool to make your kick-off workshop more structured and to gain initial project knowledge from all team members. Or fill it in asynchronously using your favourite collaboration tool. Then put the final touches and agree on it together.

Option 2: Let your product owner (PO) fill it in and discuss it together

I often like to use this template before there is any project team assembled — to understand how mature the PO’s thinking already is, and to see which design skills would benefit the project most.

In those cases, I send the template straight to the PO and ask if they could fill it in for me. We then go through it together once it’s done. The results depend on how senior the PO is, what the project is about, and how much is known already. However, almost always I hear that it helped them think about the project in a more structured way and that they themselves now have a better understanding of what they want to achieve. That’s good. When we invest a lot of money, time, effort and passion into something, it’d better have a solid base.

Option 3: Fill it in yourself and then discuss it together

When the person requesting the project is not easily reachable or is too high in the hierarchy for you to send them a brief to fill in, fill it in yourself. Then come back to them and validate if your interpretation matches their expectations. Again, as there is now something tangible to talk about, it facilitates deeper and more fruitful discussions.

Good luck and get in touch ⌨️

Hope this simple template helps you get more clarity and put your team on the same page. If you have any suggestions for improvement or stories to share once you’ve tried it, I’d be super happy if you shared them in the comments below. If you need help setting up your new project or initiative, contact me 👋

Many thanks to my lovely wife Klara, and my good friend Ondrej Homola for their valuable feedback and suggestions for improvement.