Requirements, User Experience and Product Design

Introduction

Product management converts uncertain customer and organisational needs into products that create measurable value. Requirements, user experience (UX), and product design are the disciplines through which this conversion becomes concrete. A product manager must understand not only what should be built, but also why it matters, for whom it matters, how users will experience it, and how the team will know that the solution is acceptable.

Weak requirements often produce technically complete but commercially unsuccessful products. A team may deliver every requested feature while leaving the underlying user problem unresolved. Conversely, a beautifully designed interface may fail because it addresses a low-value problem, violates operational constraints, or cannot be delivered sustainably. Effective product work therefore connects strategy, discovery, requirements, design, engineering, operations, and measurement.

This chapter presents practical and analytical foundations for developing problem statements, epics, user stories, acceptance criteria, product specifications, information architecture, service blueprints, accessible experiences, and coherent end-to-end journeys.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Distinguish customer problems, opportunities, requirements, solutions, and specifications.
2. Write evidence-based problem statements and outcome-oriented product requirements.
3. Decompose product scope into themes, epics, capabilities, user stories, and tasks.
4. Develop effective acceptance criteria and assess story quality.
5. Explain the relationship between UX research, interaction design, visual design, and service design.
6. Apply principles of information architecture, usability, accessibility, and inclusive design.
7. Collaborate with designers, engineers, researchers, operations teams, and stakeholders.
8. Evaluate an end-to-end product experience and manage trade-offs responsibly.

1. From Business Intent to Product Requirements

A requirement is a statement of a needed capability, constraint, or outcome. Requirements may originate from users, business strategy, regulation, technology, operations, or market conditions. They are not identical to feature requests. A feature request proposes a solution; a requirement should clarify the need or result that the solution must satisfy.

For example, “Add a biometric login button” is a solution-oriented request. A more fundamental requirement might be “Users must be able to access their account securely without repeatedly entering a long password.” The second formulation leaves room for several solutions, such as passkeys, biometric authentication, or a password manager integration.

A useful hierarchy is:

This hierarchy prevents premature commitment to a particular interface. It also makes prioritisation more rational: the product manager can ask which requirement most strongly contributes to the intended outcome.

1.1 Requirements sources

Important sources include:

• qualitative interviews, field observation, and usability research;
• quantitative product analytics, support contacts, search logs, and surveys;
• strategic objectives and commercial analysis;
• legal, regulatory, security, privacy, and accessibility obligations;
• operational knowledge from sales, service, fulfilment, and customer support;
• technical constraints, platform capabilities, and architecture decisions;
• competitive and market research.

No single source is sufficient. Analytics can show where users abandon a process but rarely explains why. Interviews reveal motivations but may not estimate prevalence. Stakeholders understand operational realities but may overrepresent their own interests. Product decisions should triangulate evidence rather than treating one source as unquestionable truth.

1.2 Problem statements

A problem statement expresses a meaningful gap between a current situation and a desirable situation. It should identify the affected user or stakeholder, the context, the difficulty, and its consequence without prescribing an untested solution.

A practical structure is:

[User or stakeholder] needs to [perform a task or achieve an outcome] in [context], but [barrier or unmet need], resulting in [impact].

For example:

First-time small-business sellers need to understand when their marketplace payout will arrive, but payment information is distributed across several screens and uses unfamiliar terminology, resulting in avoidable support contacts and reluctance to sell.

A strong problem statement is specific enough to guide discovery but open enough to permit alternative solutions. It should be supported by evidence and bounded by a segment, situation, or journey stage. “Users dislike the app” is too broad; “new sellers cannot predict the timing of their first payout after an order is completed” is more actionable.

A problem statement is not a product objective, a feature list, or a design brief. The statement “Build a payout dashboard” has already selected a solution. The statement “Sellers need confidence about payout timing” identifies the need.

1.3 Outcomes and requirements

Outcome-oriented requirements define the change expected in user or business behaviour. A product team might specify that users should complete a task with fewer errors, understand a policy before purchase, or recover from an interrupted workflow. Outcomes should be measurable where appropriate, but measurement must not encourage harmful optimisation. Reducing average completion time, for instance, could be undesirable if it increases errors or excludes users requiring assistive technology.

A useful product requirement includes:

• the affected actor or user segment;
• the capability or outcome;
• relevant conditions and constraints;
• rationale and evidence;
• priority and dependencies;
• acceptance conditions;
• risks and unresolved assumptions.

Requirements should be negotiable in form but not vague in meaning. Product teams should expect requirements to evolve as discovery produces better evidence. This is controlled learning, not poor planning, provided that changes are documented and communicated.

2. Backlogs, Epics and User Stories

A product backlog is an ordered set of product work, including capabilities, improvements, defects, technical work, research, and compliance activities. Ordering is not merely ranking features by stakeholder preference. It reflects expected value, urgency, risk reduction, dependency management, learning value, effort, and feasibility.

2.1 Themes, epics, capabilities, and stories

A theme is a broad strategic area, such as “improve seller trust.” An epic is a substantial body of related work that may require multiple releases or teams, such as “give sellers transparent payout information.” A capability is a coherent product ability, such as “show expected payout date.” A user story is a concise description of a user need that can be discussed, designed, built, and evaluated within an appropriate delivery increment.

These levels are not universal standards with rigid boundaries. Their purpose is to create progressively greater clarity while preserving traceability to outcomes.

A common user-story form is:

As a [type of user], I want [capability or action], so that [benefit or outcome].

Example:

As a new seller, I want to see the expected payout date for each completed order, so that I can plan my cash flow.

The “so that” clause is especially important because it explains value and helps the team challenge unnecessary solutions.

2.2 The INVEST quality heuristic

The INVEST heuristic is often used to assess stories. A good story should be:

• Independent, so that it can be scheduled with limited coupling;
• Negotiable, because the story is a basis for conversation rather than a contract prescribing every design detail;
• Valuable, providing a recognisable benefit to a user or stakeholder;
• Estimable, sufficiently understood for the team to assess effort or uncertainty;
• Small, appropriate for the team’s delivery horizon;
• Testable, with observable conditions for determining whether it works.

INVEST is a heuristic, not a rigid compliance test. Some valuable work, such as architecture or regulatory compliance, may not fit a conventional user perspective. Such items should still articulate their value, risk, and verification method.

2.3 Decomposition

Large items can be decomposed by workflow step, user role, business rule, data state, risk, platform, or happy-path versus exception-path behaviour. Decomposition should preserve vertical value. Instead of separating work into “database,” “API,” and “front end” stories that produce no usable outcome independently, a team may deliver a thin end-to-end slice: display a payout date for one order type, then expand coverage.

Example decomposition of the payout epic:

1. Display the estimated payout date for completed standard orders.
2. Explain the factors that may change the estimate.
3. Provide details for delayed or held payouts.
4. Notify sellers when a payout date changes.
5. Support international settlement and local holidays.

This sequence allows early learning while exposing complex exceptions before broad release.

3. Acceptance Criteria and Product Specifications

Acceptance criteria describe the conditions that must be met for a requirement or story to be considered acceptable. They create a shared understanding among product, design, engineering, quality assurance, operations, and stakeholders.

Acceptance criteria should be:

• specific and observable;
• related to user value and business rules;
• testable without relying on subjective interpretation;
• inclusive of important error, empty, loading, and boundary states;
• clear about permissions, data, privacy, and accessibility where relevant.

A useful format is Given–When–Then:

Given a completed standard order with a confirmed payment,

When the seller opens the order details,

Then the product displays the estimated payout date and explains that the estimate may change.

Additional criteria might state:

Given a payout is on hold, when the seller views the order, then the product displays the hold reason, expected review status, and an appropriate next action.

Acceptance criteria are not the same as test cases. Criteria define what must be true; test cases describe particular procedures and data used to verify it. Nor should criteria encode every pixel-level design decision. Visual and interaction specifications may be maintained in design documentation, while the story records the behaviour and constraints that matter.

3.1 Functional and non-functional requirements

Functional requirements describe what a system does: create an account, calculate a shipping estimate, or allow a user to export data. Non-functional requirements describe qualities or constraints: performance, security, reliability, privacy, accessibility, maintainability, and legal compliance.

A product specification should connect these categories. For example, an upload feature may require supported file types, progress feedback, recovery after interruption, malware scanning, encryption, data-retention rules, keyboard operation, and understandable error messages. Focusing only on the visible interface would omit essential product behaviour.

A concise product specification commonly includes:

1. context, problem, and desired outcome;
2. target users and use cases;
3. scope and explicit non-scope;
4. user flows and key states;
5. functional requirements;
6. non-functional requirements;
7. data, integration, and permission considerations;
8. accessibility and localisation requirements;
9. analytics and experimentation needs;
10. acceptance criteria, risks, assumptions, and open questions.

Specifications should be “just sufficient” for shared understanding. Excessive detail becomes costly to maintain and can suppress professional judgement. Insufficient detail creates rework and inconsistent interpretations.

4. User Experience as a Product Discipline

User experience encompasses the perceptions, emotions, behaviours, and outcomes associated with interaction with a product or service. It includes interface interactions but extends to expectations, onboarding, support, fulfilment, notifications, pricing, trust, and recovery from failure.

Several design disciplines contribute to UX:

• User research investigates behaviours, needs, motivations, and contexts.
• Interaction design structures actions, feedback, states, and flows.
• Information architecture organises content and functionality for findability and understanding.
• Visual design communicates hierarchy, identity, affordance, and meaning through typography, colour, spacing, and composition.
• Content design uses language, labels, instructions, and messages to support comprehension and action.
• Service design coordinates front-stage experiences with backstage processes, people, policies, and systems.
• Accessibility and inclusive design address variation in abilities, contexts, devices, languages, and resources.

The product manager need not perform every specialist activity, but must integrate the outputs and make responsible decisions when trade-offs arise.

4.1 Usability

Usability concerns whether intended users can achieve goals effectively, efficiently, and satisfactorily in a specified context. A usable product makes the next action understandable, provides feedback, prevents avoidable errors, and supports recovery when errors occur.

Common usability principles include visibility of system status, consistency with user expectations, recognition rather than recall, user control, error prevention, clear error recovery, and progressive disclosure. These principles should be applied with evidence rather than mechanically. For example, hiding advanced controls may reduce clutter but can also reduce discoverability for expert users.

Usability evaluation may include moderated testing, unmoderated tasks, heuristic review, cognitive walkthroughs, diary studies, support analysis, and behavioural analytics. A completion rate alone is insufficient: users may complete a task while misunderstanding its consequences or experiencing unacceptable effort.

5. Information Architecture and Service Design

Information architecture (IA) concerns the organisation, labelling, navigation, search, and relationships among information and functionality. Good IA enables users to form a reliable mental model of where things are and what labels mean.

IA activities include content inventories, card sorting, tree testing, navigation modelling, taxonomy design, and search analysis. Product teams should distinguish between organisation that reflects internal departments and organisation that reflects user goals. A bank may be structured internally around departments, but customers usually think in terms of paying, saving, borrowing, and resolving a problem.

Service design extends attention beyond a single interface. A service blueprint commonly maps:

1. user actions;
2. front-stage touchpoints visible to the user;
3. backstage employee or system actions;
4. support processes and dependencies;
5. evidence or artefacts produced at each stage.

For an online grocery order, the journey may involve search, substitution preferences, payment authorisation, picking, delivery, notification, and refund handling. A smooth checkout cannot compensate for an opaque substitution process or an unhelpful refund experience. Product managers must therefore examine the full service promise and identify handoffs where responsibility becomes unclear.

Figure: A service blueprint connects visible customer interactions with backstage and support activities.

6. Accessibility and Inclusive Product Design

Accessibility means that people with diverse abilities can perceive, understand, navigate, and operate a product. It is both an ethical obligation and, in many contexts, a legal or contractual requirement. Inclusive design also considers temporary and situational limitations: a person may have a permanent visual impairment, a temporary injury, or difficulty reading a screen in bright sunlight.

Product requirements should address accessibility from discovery through delivery, not as a final inspection. Relevant considerations include:

• keyboard and alternative input operation;
• meaningful structure and labels for assistive technologies;
• sufficient contrast and non-colour communication;
• captions, transcripts, and alternatives for media;
• scalable text and responsive layouts;
• clear focus indicators and predictable navigation;
• understandable language and error recovery;
• adequate target sizes and tolerance for motor variation;
• compatibility with localisation, reading direction, and multiple languages.

Teams should use applicable accessibility standards, such as the Web Content Accessibility Guidelines, while recognising that conformance is not identical to a good experience. Automated tools can detect some technical issues but cannot determine whether instructions are understandable or whether a task is genuinely usable with assistive technology. Testing with people who use assistive technologies is therefore essential.

Inclusive design is not an argument for designing only for an average user. It asks teams to understand variation and to avoid unnecessary exclusion. It may improve the experience for everyone: captions help users in noisy environments, clear error messages help novices and experts, and flexible authentication helps users with different devices and abilities.

7. Designing Coherent End-to-End Experiences

A coherent experience has continuity across stages, channels, devices, and organisational boundaries. Customers should not have to repeat information, infer contradictory policies, or understand internal ownership structures. Coherence requires agreement on terminology, identity, data, status, responsibility, and service recovery.

Product managers can evaluate a journey by mapping:

1. the user’s goal and expected outcome;
2. stages and touchpoints;
3. user actions, questions, emotions, and risks;
4. system and organisational dependencies;
5. failure points and recovery paths;
6. measures of success and harm.

A journey map is a hypothesis about an experience, not a substitute for research. It should be validated with evidence. Special attention should be given to transitions: browsing to purchase, online to physical service, automated decision to human review, and successful task to post-task support.

7.1 Design trade-offs

Product design involves trade-offs among user value, business value, feasibility, risk, speed, consistency, and long-term maintainability. The product manager should make these trade-offs explicit. A quick workaround may reduce immediate effort while increasing support cost or creating inaccessible debt. A highly configurable product may satisfy advanced users while overwhelming beginners.

Useful decision questions include:

• Which user group benefits, and which may be harmed?
• What evidence supports the proposed design?
• What is the cost of being wrong?
• Is the decision reversible?
• Which constraints are genuinely fixed?
• What is the smallest safe experiment?
• What operational capability must exist for the experience to work?

8. Collaboration and Product Delivery

Effective collaboration is a continuous process rather than a handoff from product manager to designer to engineer. Discovery, design, and delivery should overlap. Designers and researchers contribute to problem framing; engineers identify technical implications and alternative solutions; operations teams expose service constraints; legal and security specialists identify obligations early.

Useful collaborative practices include:

• shared discovery workshops and assumption mapping;
• story-mapping sessions that connect user journeys to releases;
• design critiques focused on evidence and goals rather than personal taste;
• three-amigo conversations among product, design, and engineering;
• specification reviews before implementation;
• usability testing of prototypes and working increments;
• release-readiness checks covering analytics, accessibility, support, and rollback.

Traceability is valuable. A decision record can link a strategic outcome to a problem statement, evidence, requirement, design decision, acceptance criteria, release, and measured result. Traceability supports learning and governance without requiring every decision to be documented bureaucratically.

9. Worked Application: Reimagining a University Fee-Payment Service

The following is an illustrative case.

Background

A university receives frequent enquiries from students who are uncertain whether tuition payments have been received, when instalments are due, and what happens after a failed payment. The existing portal shows a generic “submitted” message and directs students to a separate finance page for details.

Problem analysis

Research combines support-ticket analysis, interviews with students, and observation of the payment journey. Students report three recurring difficulties: they cannot distinguish a pending transaction from a successful payment; due dates are difficult to find; and international students do not understand bank-transfer processing times. The university also experiences duplicate payments and avoidable support work.

The problem statement is:

Students need confidence that they understand their fee status and next required action, but payment status, due dates, and processing explanations are fragmented across the portal, resulting in anxiety, duplicate payments, and support contacts.

The desired outcome is not simply “build a payment dashboard.” It is improved understanding and correct next action without increasing financial risk.

Requirements and decomposition

An epic, “Help students understand and complete fee obligations,” is decomposed into capabilities:

• show current balance and next due date;
• show payment status using understandable states;
• explain expected processing times by method;
• provide a receipt and reference number;
• identify failed or reversed payments and next actions;
• route exceptional cases to finance support.

A representative story is:

As a student who has submitted a payment, I want to see its current status and reference number so that I know whether I need to take further action.

Acceptance criteria include:

• Given a successfully confirmed card payment, when the student opens fee status, then the system shows “Paid,” the amount, date, and receipt reference.
• Given a payment awaiting bank confirmation, then the system shows “Processing,” explains the expected timeframe, and warns the student not to pay again unless instructed.
• Given a failed payment, then the system identifies the failure at an understandable level and provides a secure next action.
• The status is available by keyboard, is announced appropriately to assistive technology, and does not rely on colour alone.

Design approach

The team creates a journey map and prototype. Information architecture places “Fees and payments” within the student’s primary financial tasks rather than under an internal finance department label. The service blueprint identifies dependencies on the payment gateway, student records, finance reconciliation, and support staff.

Design research tests three status labels: “Submitted,” “Processing,” and “Confirmed.” Students interpret “Submitted” as completed, so the label is replaced with “Waiting for bank confirmation.” The prototype includes a prominent next-action panel, a receipt, and an explanation of processing time.

Outcome and evaluation

In a pilot, the team measures successful status comprehension through task-based research, duplicate-payment incidents, support contacts about payment status, and accessibility findings. The product manager avoids treating faster page completion as the sole success measure: a student who quickly initiates a duplicate payment is not a successful outcome.

The case illustrates that requirements, UX, IA, service design, accessibility, and operations are interdependent. The visible status component is only one part of a broader service capability.

10. Challenges, Governance, and Contemporary Practice

Ambiguity and changing requirements

Requirements change because evidence changes, technology reveals constraints, markets shift, or regulations evolve. The response should be disciplined adaptation: record the reason, assess impacts, revisit priorities, and communicate changes. Freezing all requirements early is unrealistic; changing them without traceability is dangerous.

Stakeholder conflict

Stakeholders may optimise different outcomes. Marketing may seek conversion, finance may seek control, support may seek fewer contacts, and users may seek transparency. Product decisions should make the conflict visible and establish decision principles. A metric that rewards one group by transferring cost or risk to another is not a complete success measure.

Ethical and regulatory issues

Requirements and design must address privacy, consent, data minimisation, security, fairness, consumer protection, and accessibility. Dark patterns—interfaces that manipulate users into choices they would not freely make—undermine informed consent. Examples include hidden fees, confusing opt-outs, false urgency, and privacy choices designed to favour disclosure.

Product managers should ask whether a design is understandable, proportionate, reversible, and fair across affected groups. High-impact automated decisions require additional attention to explanation, appeal, data quality, monitoring, and human accountability.

AI-assisted requirements and design

AI tools can help summarise research, identify duplicate backlog items, generate alternative wording, create prototypes, and explore edge cases. However, generated outputs may contain fabricated evidence, omit minority experiences, reproduce bias, or expose confidential information. AI should assist professional judgement, not replace research, accessibility testing, security review, or accountability. Teams should document source evidence, protect sensitive data, verify generated content, and retain human ownership of decisions.

Best practices

1. Start with the user problem and desired outcome, not the requested feature.
2. Triangulate qualitative, quantitative, operational, and regulatory evidence.
3. Keep requirements testable while avoiding unnecessary implementation prescription.
4. Include non-functional, accessibility, privacy, and failure-state requirements early.
5. Decompose work into valuable vertical slices.
6. Use prototypes and research to reduce uncertainty before expensive delivery.
7. Map backstage processes and handoffs, not only interface screens.
8. Treat acceptance criteria as a shared conversation about observable behaviour.
9. Measure comprehension, successful outcomes, harms, and support consequences.
10. Maintain traceability while allowing evidence-based change.

Chapter Summary

Requirements translate strategic intent and user needs into capabilities, constraints, and measurable outcomes. A problem statement should describe an evidence-based user difficulty without prematurely prescribing a solution. Themes, epics, capabilities, and user stories provide progressively actionable levels of scope, while INVEST offers a useful—though not absolute—quality heuristic.

Acceptance criteria make expected behaviour observable and testable. Product specifications should include functional and non-functional requirements, states, dependencies, data, accessibility, analytics, risks, and open questions. UX is broader than interface appearance: it includes research, interaction, content, visual design, information architecture, accessibility, and service operations.

Information architecture supports findability and mental models; service blueprints connect front-stage interactions to backstage processes and support systems. Inclusive and accessible design must be integrated from discovery through delivery. Coherent experiences depend on consistent language, data, responsibility, and recovery across channels. Finally, product managers must govern trade-offs ethically, collaborate across disciplines, and use AI cautiously as an assistive tool rather than an authority.

Key Terms

Acceptance criteria: Observable conditions that must be satisfied for a requirement or story to be accepted.

Accessibility: The degree to which people with diverse abilities can perceive, understand, navigate, and operate a product.

Backlog: An ordered collection of product work, including features, defects, research, technical work, and compliance items.

Capability: A coherent product ability that contributes to an outcome.

Epic: A substantial body of related work that is decomposed into smaller capabilities or stories.

Information architecture: The organisation, labelling, navigation, and relationships among information and functionality.

Inclusive design: Designing for variation in abilities, contexts, identities, languages, devices, and resources.

INVEST: A heuristic describing desirable qualities of user stories: independent, negotiable, valuable, estimable, small, and testable.

Non-functional requirement: A quality, constraint, or operational property such as security, performance, reliability, or accessibility.

Problem statement: An evidence-based description of an unmet need or difficulty and its consequences.

Product specification: A shared description of context, users, scope, requirements, states, dependencies, constraints, and verification.

Service blueprint: A map connecting user actions and visible touchpoints to backstage processes and support systems.

Theme: A broad strategic area that groups related opportunities or work.

User experience: The perceptions, behaviours, outcomes, and feelings associated with interaction with a product or service.

User journey map: A representation of stages, actions, needs, emotions, touchpoints, and failure points in an experience.

User story: A concise description of a user need, capability, and benefit.

Usability: The extent to which intended users can achieve goals effectively, efficiently, and satisfactorily in context.

Vertical slice: A small increment that delivers value across relevant layers of a product rather than completing only one technical layer.

Review Questions

Short Answer Questions

1. How does a problem statement differ from a feature request?
2. What is the purpose of the “so that” clause in a user story?
3. Define acceptance criteria and explain why they should be testable.
4. Name four disciplines that contribute to user experience.
5. What is the purpose of a service blueprint?

Long Answer Questions

1. Explain how strategic outcomes can be translated into themes, epics, capabilities, user stories, and implementation tasks. Use an example.
2. Discuss the INVEST heuristic and explain why it should be treated as a guide rather than a rigid standard.
3. Compare functional and non-functional requirements and explain why both are necessary in a product specification.
4. Explain how information architecture, usability, accessibility, and content design jointly influence product quality.
5. Discuss the role of the product manager in resolving trade-offs among user value, business value, feasibility, risk, and speed.

Analytical / Application Questions

1. A banking app shows that a transfer is “submitted,” although confirmation may take two days. Write a problem statement, one user story, and four acceptance criteria for improving this experience.
2. Analyse a service you use regularly and create a written service blueprint identifying customer actions, front-stage touchpoints, backstage processes, and support systems. Identify one critical handoff.
3. A team proposes a feature that increases conversion but uses confusing opt-out language and excludes keyboard users. Evaluate the proposal using usability, accessibility, ethical, and governance considerations, and recommend a course of action.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a product requirement?

A. A visual mock-up prescribing every interface detail

B. A needed capability, constraint, or outcome supported by evidence

C. A list of engineering tasks arranged by technical layer

D. A stakeholder preference that does not require validation

Correct Answer: B. A needed capability, constraint, or outcome supported by evidence

Question 2

Which user story is most outcome-oriented?

A. As a seller, I want a blue dashboard button.

B. As an engineer, I want to create a database table.

C. As a seller, I want to see my expected payout date so that I can plan cash flow.

D. As a manager, I want the team to work faster.

Correct Answer: C. As a seller, I want to see my expected payout date so that I can plan cash flow.

Question 3

In the INVEST heuristic, the letter T represents which quality?

A. Traceable

B. Technical

C. Time-boxed

D. Testable

Correct Answer: D. Testable

Question 4

What is the primary purpose of acceptance criteria?

A. To define observable conditions for accepting a requirement or story

B. To replace all usability research

C. To specify the organisation’s annual strategy

D. To prescribe the internal architecture completely

Correct Answer: A. To define observable conditions for accepting a requirement or story

Question 5

Which is a non-functional requirement?

A. The user can export an invoice

B. The system displays a shipping address

C. The service supports keyboard operation and appropriate accessibility semantics

D. The customer can add an item to a cart

Correct Answer: C. The service supports keyboard operation and appropriate accessibility semantics

Question 6

What does information architecture primarily address?

A. Employee compensation and reporting lines

B. The organisation, labelling, navigation, and relationships among information and functionality

C. Source-code performance only

D. The colour palette of a brand

Correct Answer: B. The organisation, labelling, navigation, and relationships among information and functionality

Question 7

What does a service blueprint add to a conventional interface flow?

A. Only a list of visual design tokens

B. A financial forecast for the product

C. Connections between visible interactions, backstage processes, and support systems

D. A replacement for all customer research

Correct Answer: C. Connections between visible interactions, backstage processes, and support systems

Question 8

Which practice best supports accessibility?

A. Communicating important information through colour alone

B. Testing only with automated accessibility tools

C. Adding accessibility requirements after launch

D. Supporting keyboard operation, clear labels, alternatives for media, and understandable errors

Correct Answer: D. Supporting keyboard operation, clear labels, alternatives for media, and understandable errors

Question 9

Why should product teams decompose an epic into vertical slices where possible?

A. To deliver learning and usable value across relevant product layers

B. To ensure that only database work is completed first

C. To eliminate the need for acceptance criteria

D. To prevent requirements from changing

Correct Answer: A. To deliver learning and usable value across relevant product layers

Question 10

What is an appropriate use of AI in requirements and design work?

A. Allowing generated summaries to replace research evidence

B. Using AI to assist synthesis while verifying outputs and retaining human accountability

C. Uploading confidential customer data without controls

D. Treating generated interface text as automatically unbiased

Correct Answer: B. Using AI to assist synthesis while verifying outputs and retaining human accountability