Validating Product Brief Assumptions Before Design Decisions

Hello. In the previous lesson, you separated a product brief into user needs, business goals, technical constraints, and proposed solutions. That work matters because a brief often states desired outcomes and feature ideas with the same confidence as verified facts.

This lesson adds a crucial professional habit: identifying the beliefs hidden inside a brief before those beliefs become screens, flows, and costly implementation decisions. By the end, you will be able to spot decision-relevant assumptions, distinguish them from facts and goals, and prioritize the ones that need evidence first.

---

An assumption is a belief, not a confirmed input

In UX work, an assumption is a belief the team is currently treating as true about users, their behavior, their context, the business, or the technology—without enough relevant evidence to justify relying on it.

The important phrase is decision-relevant. Teams make harmless assumptions constantly, such as whether a meeting room will be free. In product design, focus on assumptions that would change what you design, build, prioritize, or measure if they proved false.

For example:

“Customers need a map to find a pickup location.”

This is not one fact. It contains several assumptions:

• Customers cannot currently find pickup locations easily.
• Finding a location is a meaningful reason they abandon an order.
• A map is more useful than a searchable list, postcode lookup, or clearer location details.
• Customers are comfortable sharing location data or entering a postcode.
• Location data is accurate enough for the map to be trustworthy.

A team that immediately designs the map has silently accepted all of these beliefs. A UX practitioner makes them visible first.

Read this short guidance on replacing opinion-led language with evidence-led language.

The wording of a meeting can be diagnostic. These statements should make you pause:

Red-flag statement	Hidden assumption
“Users will obviously understand this icon.”	Users interpret the icon as intended.
“Nobody wants to create an account.”	The target users will abandon or avoid account creation.
“A progress bar will make the form feel easier.”	Seeing progress improves understanding or completion.
“Users only use this on mobile.”	The relevant users, contexts, and tasks are mobile-only.
“We researched this a few years ago.”	The earlier participants, context, and findings still apply.
“I would use it this way.”	The stakeholder’s preferences represent the target users’ needs.

These claims are not necessarily wrong. The problem is treating them as settled before examining the evidence.

---

Separate assumptions from facts, goals, and solutions

When reviewing a brief, use four labels. They prevent a useful fact from being dismissed as “just an assumption,” and prevent an untested claim from being accepted as a requirement.

Label	Meaning	Example	What to do
Verified fact or constraint	A condition supported by an authoritative source or current data.	“Pickup-slot data refreshes every 15 minutes.”	Confirm the source and design within it.
Business goal	A desired organizational outcome. It is a target, not proof of how to achieve it.	“Increase completed pickup orders by 20% this quarter.”	Clarify the baseline and success measure.
Assumption	A belief about what is true or what will happen.	“Same-day pickup will increase completed orders.”	Seek appropriate evidence before relying on it.
Solution proposal	A suggested response to a perceived problem.	“Add a slot-picker at the top of checkout.”	Identify the assumptions embedded in the proposal.

A stated technical constraint may still need verification, but that does not necessarily make it a user-research question. For example, an engineer, system documentation, or technical test should verify the 15-minute refresh interval. A legal requirement should be checked against the relevant policy or legal guidance. Evidence is not always a usability test.

Likewise, a business goal is valid because the organization has chosen it, but the causal story around it may be unproven. “Increase completed pickup orders” is a goal. “A redesigned pickup flow will increase completed pickup orders” is an assumption.

Common categories of product assumptions

Most assumptions in a brief fall into one or more of these categories:

1. User or desirability assumptions
   Beliefs about who the users are, what they need, what frustrates them, and what they are willing to do.
   Example: “Busy parents prefer pickup to delivery because they need precise control over collection time.”

2. Behavior and context assumptions
   Beliefs about when, where, and under what constraints people use a product.
   Example: “People reserve a pickup slot while commuting and have unreliable connectivity.”

3. Usability and comprehension assumptions
   Beliefs that people will understand labels, navigation, instructions, feedback, or a new interaction pattern.
   Example: “Users will understand that ‘allow substitutions’ applies to every item in the basket.”

4. Solution-effectiveness assumptions
   Beliefs that a particular feature or interface will solve a stated problem.
   Example: “A progress indicator will reduce form abandonment.”

5. Business or viability assumptions
   Beliefs about value, demand, revenue, cost, risk, or operational outcomes.
   Example: “Reducing substitution-related support calls will reduce service costs.”

6. Technical or feasibility assumptions
   Beliefs about what systems, data, integrations, or platforms can support.
   Example: “The existing checkout service can preserve a selected pickup slot if the user changes their basket.”

The final category is especially easy to mishandle. A stakeholder may say, “The existing checkout can handle that,” but until the right technical evidence exists, it is an assumption—not a constraint you should confidently design around.

---

Make vague beliefs specific enough to examine

Not every sentence that sounds user-centered is a useful assumption. Consider:

“Users need a simple checkout.”

This is a desirable principle, but it is too vague to guide a decision. Its opposite—“users need a complicated checkout”—would be absurd, so the statement cannot help you choose between credible design options.

A useful assumption is specific, plausibly false, and consequential.

Watch this excerpt from UX Tea Break: Testing Assumptions in User Research by David Travis. It gives three practical tests for deciding whether a belief deserves validation.

Use this three-part check when you encounter a claim in a brief:

1. What exactly is the belief?
   Rewrite it without a vague adjective or a feature name.

2. Could a plausible opposite be true?
   If reasonable people could believe either side, it is likely an assumption worth examining.

3. Would being wrong change a meaningful decision?
   If the answer is yes, prioritize it. If the answer is no, record it but do not let it dominate early work.

For instance, transform this statement:

“Customers want a flexible substitution feature.”

Into a more useful assumption record:

Field	Example
Assumption	Returning grocery shoppers want to choose substitution preferences while placing a pickup order.
Context	They are ordering items that may be unavailable when staff prepare the order.
Plausible alternative	Shoppers may prefer to choose substitutions only after an item becomes unavailable, or may prefer no substitutions at all.
Decision affected	Whether the flow asks for preferences during ordering, after ordering, or not at all.
Consequence if false	The team could build an unnecessary step that slows checkout and still fails to reduce support calls.
Current evidence	Brief mentions support calls; no direct evidence yet about shoppers’ preferred control.

Notice that this does not claim that the feature is bad. It makes the team’s reasoning inspectable.

---

Prioritize assumptions by risk and evidence

A brief can produce dozens of assumptions. You do not need to validate every possible belief before doing any design work. Instead, prioritize the assumptions that are both:

• Important or high-risk: being wrong would harm user value, business value, compliance, delivery, or the basic viability of the product.
• Weakly evidenced or unknown: the team has no relevant, credible, current basis for treating the belief as true.

The assumptions map shown here uses known versus unknown evidence on its horizontal axis and importance or risk on its vertical axis. Its four areas provide a practical triage system:

Map area	Interpretation	Appropriate response
Important, unknown	A major decision depends on a belief without sufficient evidence.	Investigate before committing to a solution.
Important, known	Evidence currently supports a high-stakes condition.	Treat it as a working requirement, while noting scope and date of evidence.
Unimportant, unknown	The belief is unproven but does not meaningfully affect the initial product.	Defer it rather than spending early research time on it.
Unimportant, known	The belief has support but does not drive the project’s core decisions.	Keep it available for later evaluation.

“Known” should not mean “someone senior said it.” For a high-stakes claim, record what supports it:

• the source of the evidence;
• when it was gathered;
• which users or situations it represents;
• whether it directly addresses the current decision;
• important limitations or gaps.

A support-ticket theme may suggest a real issue, but it does not necessarily explain why it occurs. Analytics may show where people leave a flow, but not what they were thinking. Older research may be useful background but may no longer represent current users or technology. These inputs can be valuable; they simply deserve the right confidence level.

A related way to prioritize appears in the following assumptions-mapping video. Its horizontal axis is ease of validation, rather than the evidence axis in the image above. Treat it as a complementary decision: after identifying a risky unknown, consider whether it can be checked quickly or will require more substantial investigation.

---

Worked example: finding assumptions in the QuickCart brief

Return to the grocery-pickup brief from the previous lesson. It stated that QuickCart wants a mobile web pickup experience for returning customers, wants to increase completed pickup orders, and wants to reduce substitution-related support calls.

Here is how an assumption register might begin:

Brief statement or team claim	Classification	Assumption requiring evidence	Priority
“Introduce a mobile web grocery-pickup experience for returning customers.”	Delivery direction with embedded user assumptions	Returning customers want to use mobile web for pickup orders rather than another channel.	High if mobile web is the only planned channel
“Increase completed pickup orders by 20%.”	Business goal	Improving the ordering experience is a major cause of incomplete pickup orders.	High
“Reduce support calls about substitutions.”	Business goal	Customers contact support mainly because they cannot understand or control substitutions in the current experience.	High
“Let customers choose substitutions during checkout.”	Solution proposal	Asking for substitution preferences during checkout reduces uncertainty without creating friction or abandonment.	High
“Inventory and pickup-slot data refresh every 15 minutes.”	Stated technical constraint	The refresh interval is accurate, consistent, and exposed to the interface in a usable way.	High, but validate technically
“Support latest Safari and Chrome.”	Stated platform constraint	None about user desire; this needs implementation and browser verification.	High for delivery, not a user-needs assumption
“Use a purple confirmation screen.”	Visual preference	Purple supports trust, comprehension, or the brand better than alternatives.	Usually low unless brand or contrast requirements make it consequential

This table shows a useful distinction: a feature request such as “choose substitutions during checkout” is not automatically a user need. It is a proposed answer. The UX task is to uncover the belief that makes the answer seem reasonable, then determine whether that belief has adequate support.

The assumptions with the highest priority are usually those that affect the product’s core value proposition:

• Do users have the problem the product claims to solve?
• Is this user group the right one to prioritize?
• Does the chosen service model fit users’ real circumstances?
• Will the proposed solution help rather than add work or confusion?
• Can the underlying technology support the promised experience?
• Does the business model depend on a behavior that may not occur?

---

Keep an assumption register, not just sticky notes

An assumptions map is useful for group discussion, but its value disappears if the assumptions cannot be traced back to the brief and revisited later. Maintain a lightweight register alongside it.

Field	Purpose
Assumption ID	Gives the claim a stable reference, such as A-01.
Assumption statement	States one specific belief in neutral language.
Category	User, behavior, usability, solution, business, or technical.
Source	Notes the brief section, stakeholder statement, data source, or team discussion.
Current evidence	Records what supports the claim and how reliable it is.
Impact if wrong	Explains what product decision would need to change.
Priority	Marks whether it needs attention now, later, or not at all.
Status	Uses clear labels such as unknown, partially supported, confirmed, or disproved.

This register protects the team from a common failure mode: a provisional idea becomes familiar through repetition, then starts being treated as fact.

The following case studies show why that discipline matters. They describe a live government service, so the teams can make changes and compare outcomes, but the principle applies much earlier in a project: name the assumption, state what would count as evidence, and learn from the result rather than defending the original feature.

The goal is not to delay every design decision until uncertainty disappears. That is impossible. The goal is to be explicit about uncertainty, avoid making high-stakes choices on untested beliefs, and update the work when evidence contradicts the team’s first idea.

---

Key takeaways

A product brief contains facts, goals, constraints, solution proposals, and assumptions mixed together. Before designing, make the hidden beliefs visible.

• An assumption is a decision-relevant belief treated as true without sufficient, relevant evidence.
• Separate assumptions from verified constraints, stated business goals, and proposed features.
• Look for assumptions about users, contexts, comprehension, feature effectiveness, business outcomes, and technical feasibility.
• Turn vague claims into specific beliefs with a plausible alternative and a clear consequence if wrong.
• Prioritize assumptions that are both high impact and poorly evidenced.
• Record the source, evidence, risk, and current status of each important assumption so it does not become “fact” through repetition.

Next, you will turn high-priority assumptions into focused research questions. That step connects the uncertainty you have identified to the evidence your team actually needs.