Analyzing Design Brief Requirements

Welcome back. In the previous lesson, you learned that user-centered design is iterative: teams learn about people, define a problem, explore ideas, prototype, test, and revisit earlier decisions when evidence changes. Before any of that work is useful, though, a team needs to understand the project they have been given.

A design brief is often the starting point. It may contain a mix of genuine goals, proposed features, deadlines, technical facts, stakeholder opinions, and untested claims about users. Your task is not to treat every sentence as equally reliable or immediately start drawing screens. It is to extract three forces that shape the work:

1. User needs: what people need to achieve and why.
2. Business goals: the organizational outcome the project is meant to create.
3. Technical constraints: the boundaries imposed by the systems, platforms, data, security, and performance realities of implementation.

By the end of this lesson, you will be able to turn an unstructured brief into a short, traceable set of these inputs—without confusing a requested feature with the problem it is supposed to solve.

---

A brief is a starting point, not a source of truth

A design brief gives a project direction and establishes shared expectations. It may state the intended audience, objectives, timeline, deliverables, available resources, and restrictions. However, a brief is usually written before the design team has completed research. It therefore contains claims to investigate, not just facts to obey.

Watch this overview of what a strong design brief normally includes. Although the example is oriented toward creative projects, its core distinction between scope, objectives, audience, and deliverables is useful for digital product work.

Consider the statement:

“We need a map so customers can find a nearby pickup location.”

This may sound like a requirement, but it bundles together several different things:

• Proposed solution: a map.
• Possible user need: customers need to find a suitable pickup location.
• Possible business goal: more customers complete orders with pickup.
• Unknowns: Do customers fail because they cannot find locations, because opening hours are unclear, because locations are too far away, or because they do not trust availability?

The map is a solution hypothesis. It might turn out to be appropriate, but a brief alone does not prove it is the right answer. Extracting needs, goals, and constraints creates enough clarity to research and design responsibly.

The three circles are not three separate documents handed to three separate teams. They influence one another. For example, a user may need confidence that an item is available; a business may want to reduce abandoned orders; and the inventory system may update only every 15 minutes. A good experience acknowledges all three realities rather than promising certainty the system cannot provide.

---

Distinguish the three categories precisely

The following distinctions will prevent many early UX mistakes.

Category	The question it answers	Good form	Common confusion
User need	What does a particular user need to accomplish, and why?	“Returning shoppers need to confirm pickup availability so they can place an order with confidence.”	A feature, such as “users need a calendar.”
Business goal	What change does the organization seek, and how will it know?	“Increase completed pickup orders by 20% this quarter.”	A project activity, such as “launch pickup.”
Technical constraint	What implementation boundary must the solution respect?	“Inventory data refreshes every 15 minutes.”	A preferred visual style, such as “use a clean design.”

A user need describes an outcome, not an interface object. “Users need a search bar” is not a need; it names a possible solution. A better formulation is “users need to locate a specific product efficiently.” Search may be one response, but browsing, filtering, recently viewed items, or a well-organized category structure might also help.

This short NNgroup video explains the difference particularly well.

A business goal describes value for the organization. It often relates to revenue, retention, conversion, cost reduction, risk reduction, operational efficiency, trust, or market positioning. Strong goals are measurable or at least measurable in principle.

Compare these statements:

• “Create a faster checkout.” This is a solution direction.
• “Reduce checkout abandonment.” This is a business goal, though it needs a target and timeframe.
• “Reduce checkout abandonment from 42% to 30% by the end of Q3.” This is a measurable business goal.

A technical constraint is a boundary that affects what can be designed or how it must behave. It might concern:

• Supported platforms and browsers
• Existing systems, APIs, and databases
• Data availability and data-refresh timing
• Authentication and account rules
• Security and privacy requirements
• Performance, reliability, and connectivity
• Accessibility standards
• Required integrations or legacy technology

The Interaction Design Foundation groups these implementation boundaries under non-functional requirements. Read the two short sections below to see why requirements must connect user and business concerns, and why constraints are not merely developer details.

Constraints can be user-visible. A slow connection may require loading states and the ability to retry. A security rule may require multi-factor authentication. A fixed data refresh interval may require language that distinguishes “available now” from “last updated.” The constraint is not the screen design; it is the reality that the design must respect.

---

Read a brief in two passes

When you receive a brief, resist the urge to rewrite it immediately. First, preserve what it actually says. Then interpret it carefully.

Pass 1: Mark claims by category

Read the brief once for its overall project context. On a second pass, highlight statements using four labels:

• U — User: user group, activity, context, frustration, desired outcome.
• B — Business: organizational outcome, metric, strategic priority, cost, deadline tied to value.
• T — Technical: system, platform, data, integration, security, performance, or implementation boundary.
• P — Parking lot: proposed features, vague preferences, unsupported claims, and information that fits none of the first three categories.

The parking-lot label is important. A statement such as “Use a chatbot” should not vanish, but neither should it be mistaken for a user need. Record it as a proposed solution to examine later.

Pass 2: Rewrite each marked statement as an atomic item

A brief sentence can contain several claims. Break it apart so each extracted item has one clear meaning and remains traceable to the source.

Use these practical formats:

Category	Rewrite template
User need	[User group] needs to [action or outcome] so that [reason or desired result].
Business goal	The organization aims to [measurable outcome] by [timeframe], because [business reason].
Technical constraint	The solution must work within [specific boundary], which means [known limitation or condition].

For every item, preserve the original sentence or section where you found it. This source link matters because it lets you distinguish an explicit statement from your interpretation later.

A useful extraction sheet has these columns:

Category	Extracted item	Brief source	Status	Follow-up needed
User	Returning shoppers need to reserve a convenient pickup time.	“Audience and service scope”	Stated, not validated	Which factors make a time convenient?
Business	Increase completed pickup orders by 20% this quarter.	“Success measures”	Stated	What is the current baseline?
Technical	Pickup-slot data refreshes every 15 minutes.	“Systems”	Confirm with engineering	Can the interface request a manual refresh?

The status column is a guardrail against overconfidence. A brief might clearly state the organization’s target, but it does not validate the claim that users want a particular feature.

---

Worked example: extracting from a fictional brief

Imagine you receive this brief for a grocery retailer:

QuickCart wants to introduce a mobile web grocery-pickup experience for returning customers. Leadership wants to increase completed pickup orders by 20% this quarter and reduce support calls about substitutions. Shoppers should be able to reserve groceries for same-day pickup. The experience must use the existing account and checkout services. Inventory and pickup-slot data refresh every 15 minutes. The mobile web experience must support the latest Safari and Chrome browsers. The team may not store payment-card data. Launch is required before the autumn campaign in eight weeks.

At first glance, this seems straightforward. But it mixes user, business, technical, and project information.

1. Extract provisional user needs

The brief gives one direct indication of what shoppers are trying to do:

Brief statement	Extraction	What to avoid assuming
“Shoppers should be able to reserve groceries for same-day pickup.”	Returning shoppers need to reserve groceries for same-day pickup so they can obtain an order without an in-store visit.	Do not assume why they prefer pickup, how often they use it, or which steps they find difficult.
“Reduce support calls about substitutions.”	Shoppers may need to understand or manage substitutions while ordering.	The brief identifies an operational issue, not proof of the exact user problem. They may be confused, dissatisfied with choices, or unable to find the policy.

Notice the word may in the second extraction. It is an informed interpretation, not a confirmed fact. Keep it as a provisional need to research.

Also notice what is not a user need:

• “Build a mobile web experience” is a platform and delivery choice.
• “Use the existing checkout” is a technical constraint.
• “Same-day pickup” may become a service capability or functional requirement, but the user’s underlying desired outcome is convenience, control, speed, or avoiding an in-store trip. Research is needed to know which matters.

2. Extract business goals

Two organizational outcomes are explicit:

Brief statement	Extraction
“Increase completed pickup orders by 20% this quarter.”	Increase completed pickup orders by 20% during the current quarter.
“Reduce support calls about substitutions.”	Reduce substitution-related support calls.

The first is stronger because it gives a metric and timeframe. The second is still a legitimate goal, but it needs clarification: reduce calls by how much, from what baseline, and without increasing another cost such as refunds or abandoned orders?

“Launch before the autumn campaign” is not itself a business goal. It is a delivery constraint tied to a commercial event. Record it, because it affects scope and prioritization, but do not pretend it explains why the product should exist.

3. Extract technical constraints

Now isolate the facts that limit implementation:

Brief statement	Technical constraint	Early design implication to investigate
“Use the existing account and checkout services.”	The pickup flow must integrate with existing account and checkout systems.	Identify where the user enters, leaves, and returns to the pickup flow.
“Inventory and pickup-slot data refresh every 15 minutes.”	Availability data may be up to 15 minutes old.	Do not imply real-time certainty; determine what information or recovery is needed if availability changes.
“Support the latest Safari and Chrome browsers.”	The solution must work in the specified mobile browsers.	Check interaction patterns and layouts in both browsers.
“May not store payment-card data.”	Payment handling must use an approved external or existing service.	Understand what payment steps occur outside the product’s direct control.

The right-hand column contains design implications, not final solutions. For example, the 15-minute refresh constraint does not automatically require a particular warning message or refresh button. It tells the team what must be understood before choosing an interaction.

This distinction is central:

A constraint describes a boundary.
A design decision describes the team’s response to that boundary.

---

Handle tensions without choosing a side too early

The three categories often conflict. That conflict is not evidence that one category is wrong; it is the material of product design.

In the QuickCart example:

• Users may expect an item marked “available” to remain available.
• The business wants more completed orders and fewer support calls.
• The data system refreshes only every 15 minutes.

A design that falsely guarantees availability might encourage an immediate order but create disappointment, refunds, and support burden later. A design that overemphasizes uncertainty might discourage orders. The team needs evidence about what shoppers understand and what language supports confident, informed decisions.

When you find a tension, write it down as a decision area:

Tension	What must be learned or decided
Customers need confidence, but inventory is not real-time.	What degree of availability information is accurate, understandable, and useful?
The business wants rapid growth, but the launch window is eight weeks.	Which core tasks must work at launch, and which ideas can wait?
Existing checkout limits flexibility.	Can pickup selection occur before checkout without creating a confusing handoff?

Do not hide trade-offs in a polished interface. Make them visible early, discuss them with product and engineering partners, and use research to determine which compromise best serves the project.

---

A compact brief-extraction routine

For a small project, use this sequence:

1. Read for context. Identify the proposed product, audience, organizational situation, and scope.
2. Mark statements. Label each relevant claim as user, business, technical, or parking lot.
3. Split compound statements. Separate a target user, a feature request, a metric, and a system restriction when they appear in one sentence.
4. Rewrite neutrally. Express needs as outcomes, goals as organizational change, and constraints as specific boundaries.
5. Keep the source. Record where every item came from in the brief or stakeholder conversation.
6. Mark confidence. Use labels such as stated, inferred, confirmed, or unknown.
7. List unanswered questions. These become inputs to research, stakeholder conversations, and feasibility checks.

A short extraction document is more useful than a beautifully formatted summary that silently mixes facts with assumptions. It gives the team a shared view of what is known, what is desired, what is constrained, and what still needs evidence.

---

Key takeaways

A design brief is a useful project input, but it is not a validated research report. Read it critically and separate its different claims:

• User needs describe what a specific group needs to accomplish and why; write them as actions and outcomes, not features.
• Business goals describe the organizational value the project should create; make them measurable whenever possible.
• Technical constraints describe real implementation boundaries, including systems, data, platforms, security, performance, and integrations.
• Treat requested screens, features, and visual preferences as solution proposals, not proof of user needs.
• Preserve the source and confidence level of every extracted item so the team can distinguish stated facts from inferences.
• Delivery factors such as budget and deadlines matter, but should not be mislabeled as technical constraints.

Next, you will build on this extraction work by identifying the assumptions in a product brief that need evidence before they can guide design decisions.