Digital Government and Service Delivery
This domain tests service design and delivery: whether a digital channel actually completes the user's task, and whether the service is accessible, secure, and procured sensibly.
Core rules and concepts
- Design from user research and the life event, not the organisational chart. Map the journey and measure drop-off at each step of the transaction.
- Accessibility is a requirement from the start, not a retrofit: content must be perceivable, operable, understandable, and robust, and must be tested with assistive technology.
- Identity assurance should be proportionate to risk - do not demand more proof of identity than the transaction warrants.
- Interoperability and shared platforms usually beat bespoke builds: reuse components, publish data standards, and plan the retirement of legacy systems.
- Procure in modules with defined exit rights, avoiding single multi-year monoliths that lock in a supplier.
- Always provide an assisted channel. Digital-only delivery excludes people and shifts cost onto them.
Worked example
An online benefit form shows 45% abandonment, concentrated at the identity-verification step. Reasoning: the funnel, not the form length, is the constraint, so the team first tests whether the verification requirement is proportionate, then introduces a lower-assurance route with post-hoc checks, adds save-and-resume, and keeps an assisted channel open. Success is judged by completion rate and time-to-decision for users, not by page views or visits.
Traps that cost marks
Equating a website with a service; retrofitting accessibility after launch; assuming channel shift cuts cost while ignoring the assisted capacity still required; reporting visits rather than completed transactions; letting a legacy system's data model dictate the user journey.