As a product designer, you will likely work with a cross-functional team on projects that can span months or even years. Often, these projects can be complex, intersect with other projects, and have multiple iterations — clear documentation is crucial for success. In this series of posts, I will focus on the ultimate guide to creating clear project documentation using design briefs, design sprints, Figma files, PowerPoint decks, and written posts. For part I, I will focus on the Design Brief: why it is important and what is included.
Why is the Design Brief Important
The design brief serves as a guide for designers and other project stakeholders to ensure that everyone is aligned and working towards the same goal. As a product designer, you take ownership of this document. It should serve as a launch point for the design work that follows. The product design team will start the brief and then will share it with partner stakeholders across product and engineering.
What to include in a Design Brief
Problem Statement: The problem statement is a concise description of the problem the project aims to solve and why it is important. It should not include the “How” (tactics) or “What” (solution), but should start with “We believe” and focus on the user. The statement is usually a combination of the primary user problem and your team’s main hypothesis. An example of a problem statement is: “We believe that people should have easy access to their insurance information on our site.”
Background: The background section provides information about why it is important to invest in this project, how it started, and what work has been done in the past. It is essential to back up your findings with research and data.
Hypothesis: To form a hypothesis that can improve your team’s key performance indicators (KPIs), such as user sentiment as measured by net promoter score (NPS). Use the standard “If …then” format. Based on what you know, try to anticipate what will happen.
People Problem: To identify the problem of your target users, it is important to consider pain points for different actors involved. For instance, in a food delivery app, the actors would include vendors, shoppers, drivers, and users. Their respective pain points should be rooted in research and data.
Design Principles: Design principles are guidelines and fundamental concepts that shape the decision-making process. They serve as a framework to enhance usability, force clarity and reflect the values of the organization. Consider organizing a workshop session with your product partners to create the design principles. This way, everyone can contribute and provide valuable insights.
Steps to write effective design principles:
Identify user pain points: Start by identifying user needs and pain points that you are addressing on this project.
Identify design goals: Define the design goals that the product should achieve. This could include usability, aesthetics, functionality, scalability, or other relevant factors.
Align with company values: Ensure that the design principles align with the company’s values and mission. This will help ensure that the product design is consistent with the company’s overall vision and goals.
Brainstorm design principles: Based on the user needs, design goals, and company values, create a set of design principles. Ensure the principles are simple, memorable, and applicable throughout the design process. Prioritize your principles based on their importance and relevance to your product, focusing on the top 3–5 critical design principles.
Iterate and refine: Keep refining your design principles as you go through the project.
Constraints: Identify the business, technical, or design constraints and how they might impact the current project. This way, everyone is aligned and is designing with them in mind.
Jobs to be done (JTBD): The JTBD framework helps align designers and partners on the use cases they are designing to solve. To use JTBD, identify the users, the specific job they need to get done, and the outcome they want to achieve. For example: “As a [type of user], I want to [type of job to get done], so I can [outcome to achieve].”
Scope of Work: To ensure alignment with cross-functional partners, it is extremely important to clearly define the expected design work for the project. This includes listing out the individual responsibilities of the designer, as well as any shared responsibilities with the product manager and other team members. Be sure to also note related or potential features that are explicitly not part of the project. By doing so, you maintain focus and limit scope creep.
Timeline and Deliverables: To effectively manage expectations and ensure there are appropriate resources for the project, it is crucial to establish a rough timeline for each deliverable. If there are multiple deliverables, specify what is expected for each version and provide a rough timeline for each.
Existing Ideas: If you have existing ideas, include a section on them to avoid duplicate efforts and to build upon past thinking and testing.
Q&A: This section includes questions that require clarification. During the document’s creation, tag partners and address the questions with them.
I look forward to sharing Part II of this series of posts with you soon! In the next post, I will share a deep dive into Figma documentation for product design.