The power of a UX project brief (template included)
👉 UPDATE 2022: Many thanks for all the positive feedback, claps and highlights ❤️ I’ve updated the article with new learnings and useful topics/questions I’ve gathered over the past two years. This new version is published on my blog at https://matejkaninsky.com/blog/ux-project-brief-template/ Hope it’s even more useful than before! Matej
Design projects are often started without much clarity on what outcomes they aim to achieve. An initial request from the business might be sometimes as short as:
“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 to 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:
- Reducing ambiguity
- Making the team think deeper about the key project inputs
- Helping to discover gaps in the team’s understanding of the project
- Facilitating constructive team discussions by making things more tangible and specific
- Reducing inefficiencies by clarifying roles and establishing basic ways of working
- Enabling much faster project onboarding of new team members later
How it came about 📜
I have 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, and recently I have tweaked a few more things to get it into its current form. It’s fairly simple but trust me, it makes a difference.
Here it goes.
UX Project Brief [Template]
Name of the project
Started on:
Last updated on:
Background
Describe what the project is about, what’s its context and background.
Describe why it’s being carried out. If it’s a part of a wider customer journey, link it here.
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
How will you know the project was successful once it’s finished?
Think KPIs, OKRs, UX metrics, benchmarks, company targets (whatever your company is using).
Target audience
Describe the target audience for this project.
You can link to your personas.
The team and stakeholder map
Define team roles and responsibilities.
List stakeholders and describe what level of involvement is needed/expected.
Who is the decision-maker (sign off)?
[Note: One way of doing this can be a RACI matrix]
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.
E.g. What are the risks to the success of this project? What would happen if we don’t meet the deadline?
Deliverables
List tangible artefacts that this project is expected to deliver.
Timings
Link to a product road map.
List currently known deadlines and milestones.
Add the expected project start date [if filling in before the team is assembled] and the expected delivery date.
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 you use?
How will you document the project?
How will you share your designs 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?
Additional notes
If there is something else, specific to this project, state it here.
How to use this UX project brief template ✍️
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 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 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. Thanks and enjoy your next project 👋
Many thanks to my lovely wife Klara, and my good friend and colleague Ondrej Homola for their valuable feedback and suggestions for improvement.
