We’ve all been in projects where we’ve started to doubt ourselves. We start to question the whole thing with thoughts like:
- What’s the purpose?
- Why are we doing this now?
- Are we going down the right path?
- Who are we really serving?
- How do we know we’ve been successful?
We need a North Star to guide us through.
It’s easy to lose track of the big vision, but a Design Brief is a powerful tool to guide us. Just like a North Star, a Design Brief grounds you and your team as the opportunity you’re tackling gets more wicked and complex. Simply put, your Design Brief is a charter for your project that helps you focus your approach to solving a specific design challenge.
What is a Design Brief?
This document is generally co-created as a team at the beginning of a project and becomes your compass along the way. Each and every team member should contribute to and review the Design Brief to ensure shared understanding at all levels. At the onset, it is tempting to make the Design Brief perfect, but it doesn’t have to be. Just settle for good enough rather than tirelessly capturing every detail and nuance. The Design Brief is meant to be a guide, not a set of rules.
Why? Rules limit our flexibility once a project is underway. Over time, project conditions change. We have new metrics or learning goals to meet. New insights or leadership force us to move in a different direction. We want to be able to stay nimble so we have room to pivot and adapt, rather than being held to fixed criteria that may become obsolete by the time the project is finished.
How to Build a Design Brief
When building a Design Brief, remember to keep it short and simple. If an idea can’t be conveyed in one to two sentences (or a handful of bullet points), it could use some more finesse.
Now, let’s start with the basics.
Project Description: This is the “why” of your project. If you’re conducting research or exploring a new offering or market, it’s easy to frame the Project Description as a question or a challenge statement starting with, “How might we ____?” A “how might we” statement doesn’t focus on what we are delivering, but invites possibility to explore how we might meet our objective. On the other hand, if you know what you likely need to build, the Project Description might be a value proposition instead. This value proposition should be clear about what customer need or pain point it tackles and how it meets that need.
Scope: This is probably the trickiest part of the Design Brief. Here we want to define the limits of what we will or will not deliver, rather than outline the deliverables in the project. The list of deliverables is more likely to change over the course of a project (and can always be added to), but the scope limits help us ensure that our project is discrete and bounded. Good limits prevent a project from getting out of control by keeping our efforts focused only on what we committed to in the Design Brief.
Constraints: While the Scope section outlines our projects limits, the Constraints section should outline what obstacles and pressures we will face in this project. Typically, Constraints fall into four categories: time, resources, capabilities, and willpower.
- Time: Deadlines, lead times, milestones, and other windows of opportunity that will change how we execute the project.
- Resources: Human capital, technology, and budget. What do we have to work with?
- Capabilities: Expertise, skills, tools, processes, and anything that will define the means and quality of execution.
- Willpower: Motivation, buy-in, and need to succeed. Sometimes project partners have emotional needs that we have to keep in mind to complete our project in the long run.
Target Users: Target Users should specifically define who is impacted by our project or is the early adopter of our product or service. This target may be defined by demographic factors (age, gender, income, location, etc.), or by situational or psychographic factors (relationships, behaviors, preferences, attitudes, etc.). If we are in a research or discovery phase, we might not yet exactly know who our target users are yet, but we can at least identify if they are new or existing or perhaps what market they are in (for example, B2B or B2C). And remember, your Target User or early adopter may not be the same user as your early or late majority.
Exploration Questions: Exploration Questions represent our learning goals for the project. These questions should represent our biggest assumptions or unknowns that we want to understand. Typically, these assumptions are prioritized because they pose the greatest risk if we can’t either confirm or disconfirm them. If we don’t meet our learning goals for the project, it makes it difficult to move forward with confidence.
Expected Outcomes: Expected Outcomes should outline the impact or results of our project. Sometimes Expected Outcomes take the form of a positive change for our organization or our customers, while at other times they are evidence of behaviors we believe to be real or true. Simply put, if we ask an Exploration Question, this section collects our anticipated answers.
Success Metrics: We often conflate Success Metrics with performance goals, which is not always the same. If you are using a Design Brief to experiment with a new sales or operations approach, a performance goal is likely appropriate. For most other projects, Success Metrics should be defined by learning goals that must be completed or by how we will measure impact, rather than a target itself. If not carefully selected, performance targets can demotivate our teams when sometimes the failure to meet the target is a much more valuable learning outcome.
When to Use a Design Brief
Throughout the project, refer to your Design Brief at each of your project’s milestones and ask yourself the following:
- What have we learned since our last milestone?
- In light of what we’ve learned, is the Design Brief still valid?
- What can we fine tune in the Design Brief?
- Are we on the right path?
The Design Brief is a living document that should be flexible as the project moves forward. That is not to say if you face a challenge along the way that the Design Brief can be used to lower the bar for success. Instead, the Design Brief is an opportunity to reflect and understand why these challenges exist and possibly find a new path forward that aligns with our North Star.
If you find that the Design Brief needs to change based on the status of your project, bring the team together and discuss how you can adapt and what needs to happen next. If you reach a milestone and find that the Design Brief is still the right path or, better yet, your team has accomplished some of their goals, it’s time to celebrate together and decide what to do next.
With a Design Brief in hand, we hope that you have one more tool to help navigate your project towards success. Whenever your project gets tough or you feel like you’re starting to lose your way, remember that you aren’t alone and there’s always a successful path ahead of you.
