The challenge
One service, several handovers.
The requester needs to understand which product and role to choose. The approver needs enough context to make a safe decision. Between them sit emails, product metadata, permission structures and responsibilities outside the interface.
My contribution
Make the whole journey visible.
I mapped requester and approver journeys, captured risks and dependencies, and developed current and future service maps. I designed and iterated role selection, request details, justification, expiry, review and confirmation steps.
Prototyping and GDS principles
I use the GOV.UK Prototype Kit and NHS Prototype Kit to explore accessible interactions in code. GDS Service Standard principles inform my approach to user needs, iterative design and joined up services.
For access requests, this supports exploration of form structure, role selection, review and confirmation alongside the wider service journey.
Design decisions
Give people context at the point of choice.
The work explored clearer role explanations, richer approval notifications and more useful status communication. I connected individual screen decisions to the wider service, so that simplifying a request did not remove information needed for approval.
| Service need | Design response |
|---|---|
| Requesters need to understand the access they are selecting. | Clearer role explanations and request details at the point of choice. |
| Approvers need enough context for a safe decision. | Justification, review steps and richer approval notifications. |
| Access depends on work outside the form. | Map system, email and organisational handovers alongside the interface. |
| The request needs an appropriate lifecycle. | Explore expiry, consent, confirmation and status communication. |
Working within constraints
Balance usability and access governance.
I worked with product owners, delivery leads and technical stakeholders to align on priorities. Platform constraints and access governance shaped the design, alongside the need for consistent and accessible interaction patterns.
What the work produced
A direction for service improvement.
The outputs included future journey maps, reusable interaction patterns and prioritised product, process and communication improvements. The work reached service design and handover; approval time was not measured.
The service change behind the screens
The service map made three connected design responsibilities visible. These are proposed service improvements developed through the mapping and design work.
Before a request
Problem: people need to understand which product and role fit their task.
Design response: bring product and role information into the selection journey.
At approval
Problem: approvers need context that can be lost when a form is simplified.
Design response: retain justification and review information, supported by richer notifications.
After submission
Problem: access continues through system and organisational handovers.
Design response: include status, confirmation and expiry in the future journey.
My contribution was to connect these decisions across the requester, approver and system journey. Product owners, delivery leads and technical stakeholders were involved in aligning priorities within access governance and platform constraints.
How I would evaluate the next iteration
A useful next evaluation would follow a request across the whole service: can a requester select an appropriate role, can the approver decide with the information provided, and can both understand what happens next?
Measures would include clarification requests, task completion and time spent awaiting a decision, with a baseline taken before changes are introduced. This is a proposed measurement approach, not a reported project result.
The principle behind the work
A clearer form only helps when the handovers around it are clear too.