When the stage becomes relevant
Adopt can become relevant when:
- a product or capability becomes available to an intended audience;
- awareness or enrollment appears high but meaningful use remains low;
- people begin a journey but do not complete or repeat the intended behavior;
- users continue relying on a legacy process, workaround, or competing product;
- employees, partners, or customers need to change workflows or responsibilities;
- support contacts reveal confusion, access barriers, or unmet expectations;
- different user groups adopt at substantially different rates;
- mandated use produces compliance without intended benefit;
- a live product adds a material capability or enters a new audience;
- an evolved product requires users to learn or change established behavior.
Adoption planning can begin during Define, Design, Develop, and Launch. The Adopt stage becomes distinct when real behavior and transition evidence guide the decision.
Questions and decisionsRead section
Intended behavior and benefit
- Which behavior indicates that a user has begun using the product meaningfully?
- What continuing use, task completion, or outcome would indicate effective adoption?
- How often should use occur for this product and need?
- Which behavior is optional, required, seasonal, event-driven, or one-time?
- How does the behavior connect to user and organizational benefit?
Audience and access
- Which intended users know about the product and can access it?
- Which groups experience identity, permission, device, language, disability, literacy, confidence, policy, or channel barriers?
- Are users being asked to change an established habit, tool, workflow, or relationship?
- Do affected employees, partners, and support teams have the access and knowledge they need?
Experience and trust
- Do people understand what the product does, when to use it, and what to expect?
- Can they complete important tasks and recover from errors or exceptions?
- Does the product provide accurate, timely, and credible information?
- Which concerns about privacy, security, reliability, fairness, or consequence affect willingness to use it?
- Does the wider experience reinforce or contradict the product?
Organizational enablement
- Which communications, onboarding, learning, incentives, policies, workflows, leadership behaviors, and support influence use?
- Are existing processes or measures rewarding the old behavior?
- Can frontline teams reinforce the intended experience?
- Which barriers require product changes and which require organizational changes?
Evidence and response
- What do behavior, feedback, support, research, and outcome evidence show together?
- Where do adoption patterns differ by audience, context, channel, or product condition?
- Are measures capturing meaningful use or only exposure and activity?
- Should the product, rollout, communication, learning, support, workflow, audience, or intended behavior change?
- Should availability expand, remain limited, pause, or reverse?
Activities and evidenceRead section
Useful adoption work may include:
- defining audience-specific adoption behavior, progression, and expected benefit;
- establishing baselines for current behavior and alternatives;
- examining awareness, access, activation, task completion, repeat use, abandonment, substitution, and support patterns;
- conducting research with people who adopted, struggled, delayed, declined, or stopped using the product;
- analyzing differences across audience, channel, accessibility need, device, geography, workflow, and other relevant contexts;
- observing how the product fits real work and surrounding services;
- evaluating onboarding, guidance, communications, learning, incentives, policy, and leadership reinforcement;
- identifying trust, identity, permission, data, performance, accessibility, content, and experience barriers;
- testing changes to the product and surrounding enablement;
- creating feedback paths that lead to accountable decisions;
- monitoring unintended behavior, exclusion, burden, or harm;
- connecting early behavior to product outcomes without claiming causation that the evidence cannot support;
- recording changes, decisions, evidence limitations, and next review conditions.
Adoption evidence should combine behavior with context. A rising usage count may reflect benefit, mandate, curiosity, repeated failure, or lack of alternatives.
Typical outputsRead section
Useful Adopt-stage outputs may include:
- an audience and adoption model;
- definitions of awareness, access, activation, effective use, continuing use, and benefit appropriate to the product;
- adoption baselines, measures, segments, and evidence limitations;
- onboarding, learning, communication, support, and workflow changes;
- identified barriers with responsible owners;
- research findings from adopters and non-adopters;
- product, experience, content, access, policy, or operational changes;
- updated rollout and audience decisions;
- feedback and support patterns connected to priorities;
- a recommendation to expand, maintain, change, limit, investigate, pause, or reverse availability.
The output should support decisions, not create a generic adoption score. Different user groups may require different evidence and responses.
Contributing responsibilitiesRead section
Product leadership
Product management connects adoption evidence to users, outcomes, product direction, value, rollout, and investment. Product ownership connects adoption barriers and product changes to backlog decisions without treating every request as equal evidence.
Research, experience, content, and accessibility
Research specialists help explain why behavior occurs. Experience and content specialists address comprehension, task flow, onboarding, errors, and trust. Accessibility specialists and disabled users provide evidence about barriers that aggregate measures may hide.
Communications, learning, change, and customer-facing teams
Communications, learning, change, marketing, customer-success, sales, and support contributors shape awareness, understanding, capability, workflow integration, and continuing reinforcement. Their evidence should inform the product rather than remain a separate campaign report.
Data, analytics, operations, and engineering
Data and analytics specialists define reliable measures and limitations. Operations, support, and engineering contributors identify access, performance, incident, data, integration, and service barriers and implement necessary changes.
Business leaders align policies, incentives, capacity, ownership, and expectations with the intended behavior. Security, privacy, legal, compliance, and risk specialists address trust and obligation conditions.
Cross-lifecycle considerationsRead section
- Define establishes intended users, outcomes, measures, and organizational implications.
- Design shapes onboarding, comprehension, access, and the complete experience.
- Develop implements instrumentation, feedback, support, and product behavior needed for adoption.
- Validate and Launch provide the accepted product, audience, readiness conditions, and rollout.
- Operate sustains the product and continues adoption measurement.
- Evolve addresses persistent barriers, changed needs, and new audiences.
- Retire requires adoption of a replacement or transition behavior when the underlying need continues.
Adoption evidence may require renewed Discover, Define, Design, Develop, or Validate work. Low use does not identify the cause by itself.
Common mistakesRead section
Equating launch with adoption
Availability creates an opportunity for use. It does not establish awareness, access, effective behavior, continuing use, or benefit.
Measuring only logins or enrollment
Surface activity can hide confusion, repeated failure, mandated access, or abandonment. Define behavior that connects to the product purpose.
Treating low adoption as a communications problem
The cause may involve product value, usability, accessibility, trust, data, performance, workflow, policy, support, or a poor product definition.
Studying only adopters
People who delay, decline, abandon, or rely on alternatives often reveal the most consequential barriers.
Assuming mandated use equals success
People can comply while experiencing burden, workarounds, poor outcomes, or harm. Evaluate effectiveness and consequences.
Applying one target to every audience
Needs, frequency, access, and expected behavior differ. Segment only where the distinction changes a decision.
Ending adoption work after an initial campaign
New users, product changes, organizational turnover, and changing conditions create continuing adoption needs.
Decision signals
Expand or continue
Expansion may be appropriate when intended users can access and understand the product, meaningful behavior is developing, material barriers are addressed, support and operations remain sustainable, and evidence supports broader exposure.
Change the product or enablement
Change when evidence identifies a correctable experience, content, access, workflow, communication, learning, support, trust, or product-value barrier.
Revisit an earlier stage
Return to Discover when needs or causes remain unclear, Define when the intended audience or outcome is wrong, Design when the experience creates barriers, Develop for implementation changes, or Validate when a material change requires renewed evidence.
Limit, pause, or reverse
Limit or pause when a group cannot use the product responsibly, support capacity is insufficient, or product health threatens trust. Reverse availability when continued exposure creates material harm or an unsupported experience.
Move into continuing operation
Adoption can move into normal operational governance when intended behavior and support patterns are sufficiently understood, accountable owners can sustain the product, and ongoing adoption measures have a defined home.
Applied-example continuation
The status product launches to customers with eligible active requests. Early evidence shows that many customers view status after receiving an optional notification, but some visit repeatedly because they do not understand when the next update should occur. Customers using screen readers complete the main task successfully after the earlier focus correction. Support teams report confusion when a request enters an uncommon exception state.
Research with users who did not enroll in notifications shows that some prefer account-only access and others did not understand the consent language. The organization simplifies the preference explanation without making notifications the required path. It adds clearer expected-update language, improves the exception state, and updates support guidance.
Adoption evidence shows fewer avoidable status contacts among customers who use the experience, while request types with overnight data remain excluded. The organization expands gradually within the reliable-data group and moves continuing adoption monitoring into Operate. Expansion to other request types requires improved source data and renewed validation.
Source notesRead section
- GOV.UK Service Manual — How the beta phase works. Supports learning from real users, cross-channel support, accessibility, iteration, and evidence about service performance.
- GOV.UK Service Manual — How the live phase works. Supports continuing user research, support readiness, measurement, accessibility, quality, and improvement after availability.
- U.S. Digital Services Playbook. Supports understanding real user needs, addressing the complete experience, assigning accountable ownership, and using data to guide decisions.