A design brief is an internal “contract” between key stakeholders that clearly states the agreed‐upon terms (e.g. timeline, scope, artifacts) an upcoming project will follow. Create a design brief at the very beginning of every project and as a first step in the product experience plan. It’ll anchor all the stakeholders and minimize points of confusion that may derail the project later on.

Who Are the Key players in the Experience Design Brief play?

ROLE	WHO’S INVOLVED	RESPONSIBILITIES
DRIVER	Experience strategist	Define the brief; Secure approval from the stakeholders; Monitor adherence with the brief at all times.
CONTRIBUTOR	Experience practitioners Peer practitioners	Provide perspective and gain alignment; Check for timeline feasibility.

THE HOW

To build an effective design brief play, you need to be mindful of:

1. Ensuring Universal Alignment on CONTEXT

Ensure each stakeholder, especially new hires/team members, has all the contextual information about the business, customer segment, or product necessary to be successful in the design phase. At the highest level, key elements to gather include the business, its product lines, unique selling propositions, product history, and target customer profiles.

2. Defining and Communicating the Insights and the PROBLEM Space

Identify and align on the problem you need to solve. Three sources of insights guide the definition of the problem space, the users, the business, and the product, so start by answering these questions:

What is the (user/business/product) pain point? + What is the root cause of the pain? + What is the impact?

It’s crucial to involve all of the key cross‐functional stakeholders to align and agree on the problem space. If not everyone is in agreement, then the team will be solving different problems—and time and resources will be wasted.

Once you have identified the insights and honed in on the problem space, leverage the design problem and opportunities play to correctly frame the questions before starting to design.

3. Clearly Stating a Set of Desired OUTCOMES

For the identified problems identify and align on: What are the user, business, and/or product outcomes you are looking to achieve? Compose a well‐defined outcome statement providing a full, clear visualization of your desired end state. It should be both:

• Qualitative, describing what the world looks like for the business and the user;
• Quantitative, articulating the expected numerical unit of improvement.

When documenting the outcome use the following syntax to add specificity and decrease ambiguity.

High‐level approach + direction of improvement (i.e. increase, decrease) + unit of improvement (i.e. time) + measurement of improvement where possible (i.e. 5%)

Make sure you get alignment across all key stakeholders. At the end of the project, revisit the outcome you’ve defined and ask yourself, “Have we achieved our goal?”

4. Identifying the Relevant and Necessary STAKEHOLDERS for the Project

Identify the relevant stakeholders you’ll involve throughout the process. Otherwise, there’ll be confusion around “Who is owning what,” “Who is the final approver,” “Whose feedback should I prioritize,” and so forth. Applying the DACI model, assign roles based on expertise and expected level of project involvement.

• Driver: the individual who has the highest level of accountability for the whole project, typically the experience strategist.
• Approver: The individual who is the final approver and has decision rights, typically the head of product or a general manager.
• Contributors: The individual or group of individuals who contribute to the project, typically consisting of the experience design practice and team members from the product and engineering teams.
• Informed: The individuals who should be kept in the loop about the status of the project, typically consisting of subject matter experts (SMEs), individuals from other business units such as marketing and customer support, and department heads.

5. Agreeing on SCOPE

Coming to an agreement on scope with all of the stakeholders is key to setting expectations and smooth execution. Scope comes from prioritization and alignment conversations between the key stakeholders, conversations that are typically held during initial project kickoff meetings.

Consider the following to help you define the scope against which your team will deliver:

• User—who are the user(s)?
• System—what is the system?
• Product—what product(s) are involved?
• Experiences and scenarios—what experiences and scenarios will you enhance?

Try to be as specific as possible when writing the scope. Make sure to clarify what is out of scope, as well; it’s a proactive way to mitigate potential scope creep.

6. Defining the TIMELINE and Major Milestones

Product experience plans contain detailed dates and deliverables. In contrast, design brief timelines only include major milestones, such as:

• Project start and end dates;
• Key meeting or review dates;
• Other major milestones.

7. Identifying the ARTIFACTS That Will be Delivered

Right from the beginning, set clear expectations about what deliverables will be handed off during the course of the project. The following major artifacts should be delivered:

8. Reflecting on LESSONS Learned during the Project

At the end of the project, revisit the design brief to reflect on and document any learnings. Bring back your original group of stakeholders, and discuss what worked, what didn’t work, and how to better work together so you can apply the learnings next time. This is an important step because it fuels constant growth and improvement.