When the stage becomes relevant
Design can become relevant when:
- a defined product direction requires an understandable and usable experience;
- several possible experience approaches could support the same outcome;
- users move across channels, teams, products, or operational touchpoints;
- an existing interface, workflow, service, or content experience creates confusion or exclusion;
- a product must support complex states, exceptions, permissions, decisions, or data;
- accessibility and inclusive-use needs require deliberate experience choices;
- a new capability must fit an existing product, design system, information architecture, or customer journey;
- development teams need clearer interaction, content, state, and acceptance conditions;
- validation, adoption, support, or operational evidence reveals an experience problem;
- an evolving product must accommodate changed needs, behavior, technology, policy, or organizational processes.
Design responsibility continues after an initial interface has been created. Live products require design whenever evidence shows that the experience should change.
Questions and decisionsRead section
User goals and journey
- What are intended users trying to accomplish, understand, decide, or avoid?
- What happens before and after the product interaction?
- Which channels, people, systems, and organizations shape the complete journey?
- Where do users encounter effort, uncertainty, delay, repetition, loss of context, or failure?
- Which moments have the greatest effect on trust, access, and outcomes?
Experience structure
- How should users find, enter, move through, and leave the relevant experience?
- What information and actions belong together?
- Which concepts, categories, labels, and navigation structures will users understand?
- Which states, errors, exceptions, interruptions, and recovery paths must the product support?
- How should the experience preserve context across sessions, channels, devices, or handoffs?
Content and communication
- What do users need to know at each decision point?
- Which language reflects the users’ understanding rather than internal terminology?
- How should the product communicate status, uncertainty, consequences, next actions, and errors?
- Which communications belong inside the product and which require notifications, support, documentation, or organizational outreach?
- How will content remain accurate, governed, and maintainable?
Accessibility and inclusive use
- Which accessibility needs, assistive technologies, environments, languages, devices, literacy levels, and levels of digital confidence must the experience support?
- Can people perceive, operate, understand, and reliably use the experience?
- Which groups may be excluded by identity, data, device, channel, policy, or workflow assumptions?
- What alternatives or assisted-support paths are necessary?
- How will accessibility requirements become implementation and validation conditions?
Operational and technical coherence
- Which operational processes and responsibilities must work for the designed experience to remain truthful?
- What data is available, how current is it, and how should uncertainty or missing data appear?
- Which privacy, security, consent, legal, and compliance conditions affect the interaction?
- Which existing platforms, patterns, integrations, and technical constraints should influence the design?
- What happens when a dependency fails or a user cannot complete the intended path?
Evidence and direction
- Which assumptions present the greatest experience or outcome risk?
- What level of representation is sufficient to test each assumption?
- Which users and contexts must participate for the evidence to be credible?
- Does the evidence support the experience direction, a different concept, a narrower boundary, or a return to Define or Discover?
- Which experience conditions must Develop preserve and Validate examine?
Activities and evidenceRead section
Design activities should produce evidence and implementation clarity, not merely finished-looking artifacts. Useful work may include:
- reviewing discovery evidence, product direction, requirements, measures, constraints, and unresolved assumptions;
- mapping user journeys, service interactions, information flows, decision points, backstage operations, and cross-channel handoffs;
- developing information architecture, navigation, task flows, interaction models, and state models;
- designing language, instructions, status messages, notifications, errors, confirmations, and support content;
- exploring sketches, storyboards, wireframes, prototypes, content models, service blueprints, and other representations suited to the question;
- using existing design-system components and patterns when they support the user need;
- testing concepts and prototypes with representative users, including disabled people and people who face relevant access barriers;
- evaluating comprehension, usability, accessibility, task success, confidence, error recovery, and fit within the wider journey;
- reviewing operational feasibility, data truthfulness, technical feasibility, security, privacy, legal, compliance, and support implications with specialists;
- defining responsive behavior, keyboard and assistive-technology needs, focus order, interaction states, and content hierarchy;
- identifying analytics and qualitative evidence needed to understand behavior after implementation;
- recording experience decisions, alternatives considered, evidence, limitations, and open questions;
- translating supported decisions into experience requirements and acceptance conditions that Develop and Validate can use;
- revisiting the product boundary or intended outcome when design evidence challenges the definition.
The fidelity of a prototype should match the question. A simple representation may be more useful than a polished prototype when the organization is testing language, sequence, scope, or a risky assumption. Production code may be appropriate for questions that cannot be answered credibly through a simulation, but building is not the default evidence standard for Design.
Typical outputsRead section
Useful Design-stage outputs may include:
- an experience direction connected to product outcomes and evidence;
- user journeys, service blueprints, task flows, and information architecture;
- interaction, navigation, state, and error-recovery models;
- content models, terminology, instructions, messages, and notification principles;
- sketches, wireframes, prototypes, or tested design-system compositions;
- accessibility and inclusive-design requirements;
- responsive, assistive-technology, keyboard, and interaction-state specifications;
- operational, support, channel, policy, data, and service-touchpoint definitions;
- research and usability findings with participant context and evidence limitations;
- experience acceptance conditions and traceability to relevant needs and requirements;
- analytics, feedback, and post-launch learning needs;
- a record of design decisions, rejected approaches, tradeoffs, unresolved questions, and the recommendation for what happens next.
Outputs should communicate the intended experience and its evidence. They should not require every design decision to live in one file or imply that artifacts are complete merely because they appear polished.
Contributing responsibilitiesRead section
Experience and service design
User experience (UX), interaction, service, and visual designers shape the experience across interfaces, states, touchpoints, and surrounding workflows. They connect evidence to design decisions and maintain coherence as implementation reveals new constraints.
Research, content, and accessibility
Research specialists guide credible evaluation with representative users. Content specialists shape language, information, instructions, and governance. Accessibility specialists contribute standards knowledge, testing approaches, assistive-technology expertise, and evidence about inclusive use. Accessibility remains a shared responsibility and does not belong to one review at the end.
Product management and product ownership
Product management connects design decisions to users, outcomes, product direction, boundaries, value, and priorities. Product ownership connects supported experience decisions to backlog clarity, ordering, acceptance conditions, and delivery tradeoffs. Neither responsibility substitutes for design or research expertise.
Engineering, architecture, data, quality, and operations
Engineering and architecture specialists assess feasibility, performance, maintainability, integration, and implementation tradeoffs. Data specialists clarify availability, quality, meaning, latency, lineage, and permitted use. Quality specialists help make acceptance and validation needs testable. Operations and support specialists ensure that backstage processes, recovery paths, service ownership, and assistance can support the intended experience.
Business and obligation specialists
Business and operational leaders clarify policy, workflows, ownership, and organizational change. Security, privacy, legal, compliance, risk, and other specialists identify conditions that influence identity, consent, data use, communication, access, retention, and user protection.
Users and affected stakeholders remain participants in the evidence, not merely recipients of a completed design.
Cross-lifecycle considerationsRead section
- Discover provides evidence about people, the business problem, context, barriers, and wider journey.
- Define provides product purpose, outcomes, boundaries, requirements, assumptions, and decision rights.
- Develop can expose feasibility, data, integration, performance, or implementation evidence that changes the design.
- Validate combines experience evidence with functional, technical, security, privacy, data, operational, and acceptance evidence.
- Launch requires designed communications, onboarding, support paths, contingencies, and cross-channel readiness.
- Adopt reveals whether people discover, understand, begin using, and continue benefiting from the product.
- Operate supplies behavior, feedback, support, accessibility, incident, and product-health evidence.
- Evolve uses design to address changed needs, expand capability, improve experience, or reposition the product.
- Retire requires a designed transition experience, clear communications, alternatives, support, and redirects.
Design decisions should remain connected to the evidence and requirements they address. That traceability makes it easier to understand why a design changed and what later evidence should evaluate.
Common mistakesRead section
Treating user experience as interface decoration
User experience includes the complete interaction and surrounding journey, not only colors, typography, or layout. Begin with user goals, information, behavior, accessibility, states, touchpoints, and evidence.
Designing only the ideal path
Real experiences include incomplete data, delays, errors, exceptions, interruptions, repeated attempts, and users who need assistance. Design these conditions before they become accidental implementation behavior.
Using internal language
Product, technical, policy, and operational terms may be precise internally but confusing to users. Test whether people understand the language and know what to do next.
Deferring accessibility
Accessibility affects structure, interaction, content, technology, research, and operational support. Addressing it after development can preserve exclusion and create avoidable rework.
Treating preference as evidence
Stakeholder approval, design trends, and aesthetic preference do not show that users can understand or use the experience. Connect decisions to credible evidence and product outcomes.
Confusing a polished prototype with a validated product
A prototype can answer selected design questions. It does not establish production quality, data integrity, security, reliability, operational readiness, or product acceptance.
Designing without delivery and operational contributors
An experience that cannot be implemented, supported, kept accurate, or operated responsibly is incomplete. Include the relevant contributors while design decisions can still change.
Freezing the design before development
Working increments can reveal constraints and opportunities that representations cannot. Preserve the design intent while allowing evidence-informed refinement.
Decision signals
Advance to Develop
Advancing to Develop may be appropriate when:
- the experience direction supports the defined users, goals, product outcomes, and boundary;
- important journeys, information, actions, states, exceptions, content, and support paths are clear enough to implement a coherent increment;
- representative-user evidence supports the most consequential experience assumptions;
- accessibility and inclusive-use needs are expressed as design and implementation conditions;
- technical, data, operational, security, privacy, legal, and support contributors have identified material constraints and responsibilities;
- experience acceptance conditions and unresolved questions are visible;
- the organization knows which evidence Develop and Validate must produce.
Advancement does not require every future screen, feature, content variation, or edge case to be finalized. Design and Develop may continue together.
Continue or compare design approaches
Additional design work may be appropriate when a material journey, interaction, exception, accessibility need, or high-risk assumption remains unresolved. Compare only approaches that could lead to a meaningfully different decision.
Revisit Define or Discover
Return to Define when the product boundary, outcome, requirement, priority, or ownership model requires change. Return to Discover when evidence reveals that the business problem, user need, affected group, or context was misunderstood.
Narrow, limit, or route
The experience may need a narrower audience, simpler initial scope, different channel, stronger assisted path, or connection to an existing product. Preserve the underlying user need when changing the response.
Pause or stop
Pause when essential evidence, access to representative users, technical feasibility, data, ownership, or an obligation prevents responsible development. Stop when credible evidence shows that the proposed product direction cannot support the intended need or does not justify continued investment.
Applied-example continuation
Starting point
Define established a direction centered on trustworthy status visibility for selected active service requests. The product should reduce customer uncertainty and avoidable support contacts while improving operational accountability. The boundary includes understandable status, next steps, exceptions, optional notifications, preference management, and an assisted-support path.
Experience exploration
Design maps the journey from request submission through completion and identifies the moments when customers need reassurance, must take action, or need help. The team explores status visibility within the existing authenticated account experience, optional email and text notifications, support handoffs, and ways to explain delayed or incomplete status data.
Prototype research shows that several internal status labels appear precise but mean little to customers. People understand a smaller status model when each state explains what has happened, whether they need to act, and when they should expect another update. Research also reveals that a generic “in progress” state creates more uncertainty when requests remain there for several days.
The experience direction therefore includes plain-language status, a visible last-updated time, expected next step, meaningful exception states, optional notification preferences, accessible interaction, and a direct route to assistance. The design distinguishes a data delay from a genuinely stalled request so the product does not present false certainty.
Decision
The Design-stage decision advances a coherent initial experience to Develop. Experience acceptance conditions cover comprehension, keyboard and assistive-technology use, notification consent, preference changes, error recovery, exception handling, and the support handoff. Data freshness and operational ownership remain material dependencies that may limit the first release.
Source notesRead section
- GOV.UK Service Manual — How the alpha phase works. Supports testing risky assumptions with proportionate prototypes, addressing the wider journey and connected channels, involving operational contributors, and considering accessibility before production implementation.
- Web Content Accessibility Guidelines 2.2. Provides the W3C Recommendation for accessible web content, including principles and testable success criteria. This profile treats conformance as one part of broader inclusive product responsibility.
- U.S. Digital Services Playbook. Supports addressing the complete experience, making services simple and intuitive, using real-user evidence, and bringing technical, policy, and operational contributors into product decisions.