DWP - Fraud & Error Benefit System
Led user research and interaction design for a critical government benefit fraud and error system, achieving full WCAG 2.2 compliance while reducing development rework by 35% through prototype-driven validation.
The Challenge
The DWP needed to digitise complex fraud and error benefit processes while ensuring accessibility for all citizens, including vulnerable users. Existing workflows were paper-based, inconsistent across regions, and difficult to navigate. The challenge was translating intricate policy regulations into intuitive digital services that met stringent GDS Service Standards and WCAG 2.2 accessibility requirements.
The Solution
Built end-to-end service journeys using the GOV.UK Prototype Kit to test policy interpretations and UI options before any engineering commitment. Conducted extensive moderated and unmoderated usability testing to refine content design, interaction patterns, and error states. Collaborated closely with policy teams to translate complex regulations into user-centred flows. Applied Design Thinking and Lean UX methodologies within agile delivery teams to ensure rapid iteration based on real user feedback.
Discovery & Research
- 1Stakeholder interviews with policy leads, fraud investigators, and operations managers
- 2User interviews with benefit claimants who had experienced fraud/error processes
- 3Contextual inquiry sessions observing caseworkers processing claims
- 4Card sorting to understand mental models around benefit categories
- 5Tree testing to validate information architecture decisions
- 6Moderated usability testing with GOV.UK Prototype Kit prototypes
- 7Unmoderated remote testing for scale validation
- 8Accessibility testing with assistive technology users
What We Learned
Policy Complexity
Benefit fraud and error regulations contained nuances that even experienced caseworkers interpreted differently. Digital services needed to encode these rules unambiguously while remaining flexible for edge cases.
Emotional Context
Users navigating fraud/error processes were often stressed, confused, or fearful about their benefit status. The service needed to reassure while collecting necessary information.
Caseworker Burden
Front-line staff spent significant time on administrative tasks that could be automated, reducing their capacity for complex case assessment.
Regional Inconsistency
Different DWP offices had developed local workarounds, leading to inconsistent citizen experiences and data quality issues.
Accessibility Gaps
Existing digital touchpoints failed basic accessibility requirements, excluding users with visual, motor, or cognitive impairments.
Testing Gap
Policy interpretations were being coded directly into production systems without user validation, leading to costly rework when issues emerged.
Design Principles
Prototype Before You Build
Every policy interpretation and UI decision was tested with real users in the GOV.UK Prototype Kit before any engineering work began. This caught issues early when they were cheap to fix.
GDS Design System First
Used proven GOV.UK Design System components wherever possible. These patterns are already tested for accessibility and usability, reducing risk and speeding delivery.
Accessible by Default
WCAG 2.2 compliance wasn't a final checkbox - it was built into every design decision from day one. Tested with screen readers, keyboard navigation, and users with disabilities throughout.
Plain Language Always
Government policy is complex; citizen-facing services shouldn't be. Every piece of content was written at accessible reading levels and tested for comprehension.
One Thing Per Page
Applied the GDS principle of asking one question per page, reducing cognitive load and improving completion rates for complex multi-step journeys.
Design with Data
Used analytics and research findings to prioritise improvements. Focused effort where it would have the greatest impact on user success.
Prototype-Driven Design with GOV.UK Kit
The GOV.UK Prototype Kit was central to our design process. Rather than static wireframes, we built fully interactive HTML prototypes that looked and behaved like the real service. This allowed us to:
Why Prototype-Driven Design?
- Test complex multi-step journeys with real conditional logic
- Validate policy interpretations with users before engineering commitment
- Demonstrate accessibility compliance to stakeholders
- Iterate rapidly based on usability testing feedback
- Hand off proven patterns directly to developers
- Reduce miscommunication between design and development
Technical Approach
- Built journeys using Nunjucks templating with GOV.UK Frontend
- Implemented branching logic to test different policy scenarios
- Created realistic error states and validation messaging
- Integrated with session storage to maintain user state across pages
- Version controlled prototypes for team collaboration
Rigorous Testing at Every Stage
Alpha
8 participants • Moderated in-person
Key Findings & Changes
- Users confused by benefit category terminology - simplified language
- Multi-step form felt overwhelming - broke into smaller chunks
- Unclear what documents were needed - added checklist upfront
Beta (Round 1)
12 participants • Moderated remote
Key Findings & Changes
- Error messages too generic - made specific to each field
- Users unsure of progress - enhanced progress indicator
- Timeout caught users off guard - added warning 2 minutes before
Beta (Round 2)
15 participants • Mix of moderated and unmoderated
Key Findings & Changes
- Screen reader users missed dynamic content - added aria-live regions
- Mobile users struggled with date picker - simplified to text inputs
- Users with cognitive disabilities needed more reassurance - added confirmation steps
Pre-Live
6 participants • Accessibility-focused testing
Key Findings & Changes
- Minor focus order issue in one component - fixed
- Contrast ratio marginal on one status indicator - increased
- All critical issues resolved before launch
Measured Results
"Kam's approach to prototyping fundamentally changed how we work. By testing policy interpretations with real users before development, we caught issues that would have been incredibly expensive to fix later. His accessibility expertise ensured we met our obligations to all citizens."
What I Learned
- 1
The GOV.UK Prototype Kit is transformative for government services - it bridges the gap between policy intent and user reality
- 2
Accessibility testing with real users reveals issues that automated tools miss - budget for it from the start
- 3
Policy teams become design allies when they can see their regulations working in realistic prototypes
- 4
One thing per page really works - it feels slower but completion rates prove it's faster
- 5
GDS patterns exist for a reason - resist the urge to innovate when proven solutions exist
- 6
Agile doesn't mean no documentation - lightweight but clear handoffs prevent implementation drift