Home Office · Confidential

Designing clarity for complex government services.

RoleLead Product Designer
Timeline78 weeks
DisciplineUX Design · Design Systems
ToolsFigma · Salesforce
Home Office self-service dashboard design
anonymised, but you get the idea ↑

Overview

Consistency, accessibility, and delivery efficiency across the platform.

Led product design for confidential internal self-service journeys while creating and maintaining a reusable component library from scratch — improving consistency, accessibility, and delivery efficiency across the platform.

Salesforce Component Library Creation Figma Design Systems

The Problem

Inconsistent UI and no shared components slowed down every team.

Internal services had grown organically — each team building their own patterns without a shared foundation. This created accessibility gaps, visual inconsistency, and slow delivery as designers recreated the same components repeatedly.

What I Did

Component library from scratch

Audited existing UI patterns across the platform, identified shared components, and built a Figma component library covering forms, navigation, data tables, modals, and notification patterns — all meeting WCAG AA standards.

Self-service journey design

Designed confidential internal self-service flows for staff-facing journeys. Ran workshops with stakeholders and service owners to map pain points, then prototyped and tested improved journeys iteratively.

Home Office confirmation screen pattern
one of the reusable page patterns ↑

Empathy Map

Getting inside the user's head first.

Before mapping the journey, I built an empathy map from interviews and observation — capturing what users say, think, do, and feel while completing a request. It surfaced the anxiety and uncertainty that the journey then needed to design away.

Empathy map · Home Office say · think · do · feel ✦
Says

What are users saying about their needs or challenges?

“I just need to get this done quickly.” “There are too many records to search through.” “I don't want to make a mistake.” “Why can't I find the item I'm looking for?” “I need to know exactly what this change will do.” “Can I undo this if something goes wrong?”
Thinks

What might the user be thinking but not saying out loud?

“If I choose the wrong option, this could cause problems.” “I hope I'm looking at the right record.” “There must be a faster way to do this.” “The system should tell me what actions are available.” “I don't have time to contact support.” “I need confidence before I submit this.”
Does

What actions or behaviours does the user take?

Receives requests from colleagues. Searches and filters large datasets. Reviews records and their status. Compares information before making changes. Selects and submits actions. Tracks requests until completion.
Feels

What emotions or feelings does the user experience?

Uncertain Cautious Frustrated when information is difficult to find

Pains & Gains

What's getting in the way — and what would help.

I pulled the empathy map apart into the specific obstacles users face and the outcomes that matter most to them. This made the design priorities concrete: remove the pains, design for the gains.

Pains, gains & notes problems vs. outcomes ✦
Pain points

What problems or obstacles are they facing?

Large volumes of records make finding the right item difficult Similar records increase the risk of selecting the wrong one Eligibility rules are not always obvious Unclear consequences before submitting changes Manual processes create delays Limited visibility of request progress Reliance on support teams for simple tasks Fear of making an irreversible mistake Difficulty understanding technical terminology
Gains

What outcomes or benefits matter most to them?

Complete requests quickly and independently Find records faster with minimal effort, and feel confident the correct action is being taken Understand the impact of changes before submitting Reduce the risk of errors and rework Track request status without contacting support Receive faster outcomes and resolutions

Notes

Primary user: Administrator

  • Responsible for managing requests on behalf of colleagues and teams
  • Works in a fast-paced environment where accuracy is critical
  • Needs to balance efficiency with risk management
  • Values clear guidance, transparency and confidence throughout the process
  • Key design principles: error prevention, accessibility, consistency and visibility of system status
  • Opportunities include improving search and filtering, simplifying complex workflows, providing contextual guidance and making progress tracking more transparent
  • Success is measured through reduced task completion times, fewer user errors, increased self-service adoption and improved user satisfaction

User Journey

Mapping the journey behind the request.

I mapped the user journey from entry point through task completion, including loops like saving progress, gathering missing information, and seeking approval. The highest friction appeared where users had to interpret policy-driven rules — so I designed for clarity and error recovery at each decision point — with both decision points looping back so users can recover instead of hitting a dead end.

User journey flowchart decision points loop back ✦
Yes No Yes No Start Receive request Search for record Record found? Select record Action available? Review details Submit request Confirmation End Refine search Display guidance Choose another action

Search for record

Users need to find the correct record quickly among large datasets.

Select record

Action-led design prevents users selecting ineligible records.

Review details

Users need confidence and clarity before making changes.

Confirmation

Clear success messaging reassures users the request was submitted.

Outcome

Faster design delivery across teams using shared components
Component library adopted across the platform, WCAG AA compliant throughout
Reduced design inconsistency across service touchpoints
Next case study HMRC — Single Trade Window