A product design brief or ‘product spec’ outlines the main goals of a feature or product to be worked on by a product team. It should contain the key information that the team needs to know to ensure the thing they create meets all the needs of the brief. The document should outline the success criteria for that feature or product and be the barometer against which the future design is checked. It may include things like user stories or KPIs but may also be slightly vague and in need of more research to flesh out the scope.
A design brief is important because it helps align not just the designer, but the wider product team on the functionality that will be required to be built. Being able to create and understand design briefs is a great skill to learn and is especially important if the brief is very large and encompasses more than one team.
Writing A Brief
There are a few important things you need to include when writing a design brief. The depth of detail in each of these sections may vary depending on the research that has been done and the understanding of the problem space. The important thing is to outline what you do know, the requirements and areas that need to be explored further.
Questions To Answer
Who is the user?
Too often design briefs centre around the business needs and goals rather than the user needs and goals. A product will only be effective if it is meeting the needs of the end-user. So your design brief should outline who these people are. Outline who your users are: What is their job? How are you currently meeting their needs, if at all? Is there any direct quotes or research with these users that are pertinent to this brief that can add context?
What are their pain points?
Knowing who your users are is just the first step. Next, you need to understand the day to day struggles that you are trying to fix with your design. This section should outline their problems but not be descriptive with the solution to those problems. And finally try to stick to one or two problems to solve in this section, the more problems you have the less likely you are to find a solution that nicely covers them all.
What are the main deliverables?
This may be more applicable when working in an agency environment where you have to create a set of outputs from the brief but can also help guide an internal product team to know when they are ‘done’. The main deliverables may be a research summary, a detailed product specification or a set of interactive designs. Each design brief will be different and may not always require the same level of output or detail.
What are the constraints?
If there are any restrictions on the feature or product at all these should be listed here. This can include things such as timelines, budget, design file types, coding languages or security constraints. Anything at all that the team should be aware of before embarking on the design journey should be mentioned in this document. This can also apply to things like branding and design direction if you have already an idea of what you want these to be or look like (this really only applies when working with an agency).
Are there any existing solutions?
Do you have competitors already in the marketplace that are trying to solve the same problem as you? If so you should try to include these in the document. However, unless you have done extensive research into these competitors you should leave it up to the product team to evaluate these competitors against the problem space after they have conducted discovery to hone the scope of the problem area. This is so that they will then have a better idea of what your users need and how these competitors are or aren't meeting those needs.
What Not To Do
Specify how it should be implemented
Its human nature to find solutions to problems and it can be very easy to start inputting your ideas into how something can be solved when writing a design brief. However, solutionizing too early in the product process can mean better solutions aren’t discovered during the ideation phase of a design (and can have the side effect of making a designer feel like their creativity is being stifled). Depending on the length of the project there could also be new technology or functionality implemented by the time it comes to designing the solution which can be utilised to improve the product.
Write an essay
The expected length is right there in the title; brief. A design brief should be short and to the point. Use bullet points to get across and data or research findings that will guide the project and link to other documents for more context if needed. This document should be used as a kicking off point for exploration and research and to align the wider team and so needs to be quick and easy enough that anyone can take a few minutes to read it.
Shun amendments to the brief
As the team conducts discovery and validation research they may uncover that some or all of the brief may be wrong in its assumptions around user problems or user type. If this occurs you should be open to the brief being amended after the project has started. This should be noted down as an amendment and why it has been amended for posterity. Remember, the point of their brief is to ensure alignment within the team and as a measuring stick to check the design and features against. If the goals have moved, so should the documentation.
Final Thoughts
Though your product brief should be concise if you have any existing research, data or insights that are relevant to the brief you can always link to these documents in an appendix within the brief. Additional context is great and having them alongside your brief means anyone that needs or is interested in gaining a deeper understanding of the brief can look at them.
Rember: be concise, outline the problem area and users and don't solutionize. If you stick to this mantra you should be able to write a great design brief.
Sympli is a Saas company that creates tools for design collaboration, handoff, and version control. With more than 5 years on the market, we had helped thousands of designers and developers work together by providing a single source of truth and reducing back-and-forth communications, resulting in faster delivery.
