The design brief should be provided by the customer. This is the theoretical expectation. However, in many cases—especially when the project is not too large or when you have an established relationship with the customer—the brief may be very brief. It might even be a single sentence, such as, “Can you design an application for young art enthusiasts?”

In such instances, your task is to gather all the necessary information to begin the project. It is crucial not to delay and “wait for an answer.” If you already have a commitment from the customer (perhaps even an upfront payment), you should continue working on different areas to expedite progress. You might consider starting DesignOps or outsourcing initial research.

In corporate environments or job listings, this part of the work is often referred to as “requirements gathering” or “requirements refinement.”

What Should a Design Brief Contain?

Consider your design brief as a foundational document akin to a contract; this approach can simplify the process. Even in a large organization, starting a new engagement acts as a form of signing a contract. You are agreeing to deliver specific work under particular conditions, similar to a contractual job. Thus, the design brief should encompass all the information necessary to determine if the project can be completed within the given time frame.

1. Overview
   This section should provide a clear explanation of the project and the sponsor’s vision. A few sentences in the customer’s own words can greatly assist in guiding your work.
2. User Profile or User Group
   Include a detailed description of the target users for the design. The more specific the description, the better. Ideally, this should be based on solid market research. For enterprise application design, having a well-defined group of key users is essential. If the customer can specify names rather than just roles, it creates a more informed design process.
3. Objectives
   It is beneficial if the customer outlines specific objectives and success indicators. These could be framed in terms of Key Performance Indicators (KPI) or Objectives and Key Results (OKR). For example, “I want the project to be in the top five downloaded apps on the App Store within a year,” or more generally, “I want the application to function smoothly and have an intuitive interface.” When defining objectives, feel empowered to challenge those you don’t impact as a designer, and be wary of vanity metrics (e.g., likes, views, etc.). Many clients favor these, but designers often have minimal influence over them. Remember that not all objectives are easy to measure; some rely on shared understanding, especially when aiming for emotional effects or artistic goals.
4. Competition
   There is always competition. Even if a customer claims there are no similar products in the market, don’t argue—conduct your own research. In nearly all cases, you will find competitors, whether they are direct or indirect, or located in different regions. Understanding competitors can provide valuable insights, so ask yourself what they did well and why.
5. Aesthetic Expectations
   This section should clarify the customer’s tastes and understanding of beauty. While user preferences are crucial, it’s important to consider who is funding the project—the users or the customer. Many exceptional designs fail to receive approval due to emotional reactions rather than logical assessment. To mitigate this, include aesthetic guidelines in the brief, clearly stating measurable requirements. If a customer wants the design to convey tranquility, for example, request examples to better understand their vision. This is especially critical for projects aimed at children.
6. Branding, Tone of Voice, and Visual Styling
   While these might not heavily influence strictly UX projects, neglecting them can lead to significant challenges later on. For instance, if you design an entire application flow for a hotel mobile app only to discover that the brand’s visual language emphasizes airy, wide visuals while the app focuses on a flat, technical UI, you may face major inconsistencies. Brand colors can also greatly affect usability.
7. Benchmarks
   Benchmarks might cover aspects of both “Competition” and “Aesthetic Expectations,” but they are not necessarily limited to these. I have often encountered statements like “we want this application to be like XYZ,” where XYZ is unrelated to the project subject. Clients may see XYZ as a standard for service or UX. Understanding your benchmarks before beginning design is crucial; use them to gauge what constitutes “good enough” for the customer and what represents your “Holy Grail.” Keep an open mind and ask for benchmarks from both digital and physical spaces.
8. Budget, Deliverables, Communication, Feedback, and Deadlines
   Many consider this the most important part of the design brief. Even if you aren’t directly managing the budget, understanding the project’s scale is critical. Establishing the budget should be one of your first inquiries if it isn’t explicitly stated in the brief. Mismatches in this area often lead to major complications.

Budget should be one of the first questions you ask if it’s not clearly stated in the brief. In my opinion, mismatches with client expectations regarding budget can be the most costly for your career. The simplest way to avoid this is to ask. If both sides are satisfied with the response, you can proceed. If the discrepancy is minor, you might continue and negotiate either the budget or the project scope. However, if the difference is significant, it’s generally better to “stop and part ways.” In a corporate environment, you may need to discuss the project with a senior manager or at least raise a “red flag” in an email with related managers in CC.

It’s crucial to note that when businesses mention “budget,” they do not only mean “money.” The size of a project can also be measured in man-hours, man-days, or other agreed-upon units. This serves as an additional lesson for designers. Although the time needed for a creative process is challenging to measure or determine upfront, designers must learn to estimate how long it will take to complete their work. This is essential.

Deliverables are directly connected to the budget. Many designers perceive outputs such as design documentation, screen variations, flow diagrams, and user profiles as mundane tasks that consume time. However, these outputs are necessary for the customer to understand the direction of the work, evaluate the designer’s comprehension of their intentions, and manage the project effectively.

Though it may sound abrasive, it’s important to understand that proper documentation does not create hostility; instead, it equips informed stakeholders to assess the potential success of the project at the design stage. This can lead to budget confirmation, project adjustments, or even a budget extension.

In the context of digital products, deliverables are equally vital to the development team. Early in the design process, developers can suggest changes to the original concept that may lead to greater success or save money. They can also evaluate the technical feasibility of proposed solutions; for this to happen, project participants need to understand what the designer envisions.

With the appropriate outputs established, stakeholders and developers can provide feedback at the right stages of the process.

Feedback and Communication

Proper feedback is crucial for every collaborative project. Ideally, the brief should specify how feedback will be delivered, who will provide it, and how many feedback sessions will be agreed upon. Determining the last number can be tricky when committing to collaborative tools like Figma.

However, it’s important to keep in mind that constant changes in direction due to ongoing feedback can disrupt the project’s flow. It is your responsibility to manage these dynamics. Much of this discussion pertains to communication, so I’ll return to that topic later.

Many designers, especially those with an art direction background, often request inspiration materials as part of the brief. While I appreciate having that input, I prefer to refer to them as benchmarks, considering mood boarding, desk research, and visual benchmarking as part of the designer’s role during the process.

Lastly, it’s essential to clarify who will be the point of contact (POC) between the design or development team and the customer within the brief. A good practice is to define a default POC on both sides, along with deputies. This can save a lot of headaches later on.

Two typical scenarios immediately come to mind: one involving someone being offline during the process, which can hinder communication flow, and the other where too many people want to contribute their opinions during feedback. Ideally, POC roles should be assigned to individuals with sufficient responsibility to manage the project. If this isn’t possible on the customer’s side, ensure that the POC maintains direct communication with the decision-maker.