Plan user adoption alongside technical deployment

A deployed service is only available; it is not adopted. Users need a credible reason to change, permission to challenge the output and support for the new exception path.

Build the decision artifact

Segment affected roles and describe the old and new behaviors. Identify barriers such as trust, incentives, time or unclear ownership. Co-design training from real failure modes, create champions and support channels, and measure eligible use, successful completion, overrides, edits and drop-off. Pair every rollout wave with adoption and operational gates.

The commercial leadership lab makes the artifact inspectable with authored inputs:

from leadership_cases import adoption_case

result = adoption_case()
assert result["gates"]["training_complete"] is True
assert result["gates"]["adoption_target_met"] is False
assert result["full_rollout"] is False
assert result["coercive_metric"] is False

Training and support are ready in the fixture, but the adoption target is not met, so full rollout stays false. The plan avoids a coercive activity metric; forced clicks would raise usage without proving value.

Protect the decision from weak evidence

Survey enthusiasm is weak evidence. Observe workflow behavior and interview non-users. Avoid punishing overrides, which are often a safety signal. Feed recurring edits into evaluation and product priorities.

Keep these artifacts for review:

• role and behavior-change map
• barrier-specific intervention plan
• eligible-use and outcome funnel
• feedback, override and rollout decision log

This practice aligns with the discovery, productisation, client enablement, technical leadership and capstone sequence in the FDE for Professionals course. The course link describes the pathway; the local scenario is fictional and does not claim a client engagement, investment result, hiring decision or certificate.

Practice task

Choose two user groups and define one different barrier for each. Create a measure that can distinguish non-adoption from technical failure.

Continue learning

This article is part of the Commercial judgement and delivery leadership sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Set a handover boundary between delivery and support.
• Continue with Turn field feedback into a product prioritization memo.

Reference: GOV.UK Service Manual: Helping People Use a Service.