Work / Ministry of Defence

CASE STUDY PUBLIC SECTOR · DEFENCE INTERNAL SERVICE

Redesigning a Case Management Service Around Real Caseworker Needs

A fragmented, form-heavy internal tool was slowing MOD caseworkers down and creating inconsistent records. I led discovery, redesigned the core workflow around real caseworker tasks, and worked with engineering to ship an accessible, tested service.

ROLE
UX Designer & User Researcher, led discovery
ORGANISATION
Ministry of Defence
TIMELINE
Sep 2021 – Sep 2022
TEAM
Product · Engineering · Business stakeholders · Caseworkers
STANDARDS
GOV.UK Service Standard · WCAG 2.1 AA

THE PROJECT IN STAR FORMAT

  1. S · SITUATION

    A fragmented, form-heavy internal tool was slowing caseworkers down and creating inconsistent records.

  2. T · TASK

    Lead discovery, redesign the core workflow around real tasks, and ship an accessible, tested service.

  3. A · ACTION

    Researched with caseworkers, designed a task-first case view, tested it in rounds and built it with engineering.

  4. R · RESULT

    Average case processing time down 38%, complete records up from 68% to 94%, and zero critical accessibility issues at formal assessment.

STAR · 1 OF 4

Situation

SITUATION · THE CHALLENGE

A tool organised around forms, not around casework

Caseworkers moved between disconnected screens and long forms to progress a single case. The tool captured data, but it didn't help anyone decide what to do next, and the same information was entered in different places, in different ways.

  • ✕Fragmented: a routine update spread across 12 screens and side systems
  • ✕Form-heavy: long linear forms for small updates
  • ✕Inconsistent records: free text where structure was needed
  • ✕No clear next step: progress depended on memory and workarounds

BEFORE · ONE CASE UPDATE

Case details form

long · linear

re-key →

Status update screen

no history visible

re-key →

Side tracker / inbox

workaround for "what's next?"

Each hop meant re-entering data, the main source of record drift.

STAR · 2 OF 4

Task

TASK · MY BRIEF

What I was responsible for

As UX Designer and User Researcher, I owned the research and design of the service from discovery through to release.

  1. RESPONSIBILITY 01

    Lead discovery

    Find out how caseworkers really progress cases and where the current tool gets in the way.

  2. RESPONSIBILITY 02

    Redesign the core workflow

    Rebuild the service around real caseworker tasks rather than the shape of the old forms.

  3. RESPONSIBILITY 03

    Ship with engineering

    Work alongside developers to deliver an accessible, tested service, not just a design.

What success looked like

  • Caseworkers progress cases faster, with fewer workarounds
  • Records are complete and consistent across the team
  • Every change to a case is traceable

Constraints

  • GOV.UK Service Standard and WCAG 2.1 AA
  • Internal service with audit requirements
  • Caseworkers working across two sites

STAR · 3 OF 4

Action

ACTION · APPROACH

Double Diamond, run in the open with caseworkers and engineers

  1. PHASE 01

    Discover

    CONTEXTUAL RESEARCH

    Shadowed 14 caseworkers across two sites; mapped every workaround they'd built around the legacy tool.

  2. PHASE 02

    Define

    TASK-BASED MODEL

    Reframed the service around caseworker tasks rather than internal database structure.

  3. PHASE 03

    Design & test

    PROTOTYPE & VALIDATE

    Three rounds of usability testing with serving caseworkers, including assistive technology users.

  4. PHASE 04

    Deliver

    BUILD & HANDOFF

    Paired with engineering through build; documented the resulting patterns into the shared system.

ACTION 01 · DISCOVER

Watching the work before redesigning the tool

I led discovery to understand how cases really move, not how the forms assumed they did.

METHOD

Contextual inquiry

Shadowed 14 caseworkers across two sites working live cases, mapping every workaround they'd built around the legacy tool.

METHOD

Interviews

Sessions with caseworkers, team leads and business stakeholders.

METHOD

Task analysis

Mapped the recurring tasks behind every case type.

METHOD

Record audit

Sampled live case records to locate where inconsistency entered.

What we learned

  1. 1

    Caseworkers think in tasks; the tool was built in forms.

    The question at every case was "what do I need to do next?", and nothing on screen answered it.

  2. 2

    Records drifted because data was entered more than once.

    The same facts were re-keyed across screens, often as free text, in different formats.

  3. 3

    History was hard to find and hard to trust.

    Understanding who did what, and when, meant hunting across screens: a problem for handovers and audit.

ACTION 02 · DEFINE

Framing the problem around the caseworker's job

I reframed the service around caseworker tasks rather than the internal database structure, creating a task-based model that shaped every screen that followed.

PROBLEM STATEMENT

Caseworkers need to see what a case needs next and record it once, so that cases move faster and every record is complete and consistent.

How might we…

  • …surface the next action without the caseworker hunting for it?
  • …capture each fact once, in a structured way?
  • …make a case's full history clear at a glance?

Design principles

Task first

Lead with the next action, not the form.

One case, one view

Everything needed to act, on one screen.

Record once

Structured fields, no re-keying.

Accessible by default

Keyboard and screen reader from day one.

ACTION 03 · DESIGN & TEST

One case view, built around five jobs

I moved from sketches to clickable prototypes, testing each round with caseworkers. The workflow settled into a single case view with five clearly bounded areas, each mapped to a task we'd seen in discovery.

Case management

Signed in as J. Morgan · Caseworker

My cases

SORT: DUE DATE ↑ · FILTER: STATUS, TYPE, CASEWORKER

  • CW-24-0291

    Compensation claim

    Overdue

  • CW-24-0318

    Records request

    In progress

  • CW-24-0302

    Pension query

    Awaiting info

  • CW-24-0287

    Address change

    New

CW-24-0318

Records request

Claimant
A. Khan
Case type
Records request
Status
In progress
Opened
12 May 2022
Last updated
Today 09:42
Due
Today
Change case details

Activity

  1. TODAY 09:42 · J. MORGAN

    Stage changed to Gather

  2. YESTERDAY 16:10 · J. MORGAN

    Identity check completed

  3. 12 MAY 11:05 · SYSTEM

    Case created and assigned

NEXT ACTION

Request service record from records office

Due today · Standard priority

  • Confirm identity
  • Request service record
  • Check record is complete

Visible to the whole case team. Timestamped and searchable.

YESTERDAY · J. MORGAN

Claimant prefers contact by email.

REDESIGNED CASE VIEW · ILLUSTRATIVE DATA
  1. 1

    CASE LIST

    Filter · sort · status

    • Full caseload at a glance, newest or most urgent first
    • Filter by status, case type or assigned caseworker
    • Sort by due date or priority
    • Status tags: New · In progress · Awaiting info · Overdue
  2. 2

    TASK PANEL

    Next action

    • Surfaces the single next action required, not a full form
    • Due date and priority shown alongside it
    • Mark complete without leaving the case
  3. 3

    CASE SUMMARY

    Key fields

    • Case reference, claimant details, case type and status
    • Key dates: opened, last updated, due
    • Visible at a glance, no digging through sub-forms
  4. 4

    ACTIVITY LOG

    Audit trail

    • Full timestamped history of every change
    • Records who did what, and when
    • Supports formal review and audit requirements
  5. 5

    NOTES

    Caseworker input

    • Free-text entries, timestamped and attributed
    • Visible to the whole case team, not just one caseworker
    • Searchable across the case history

ROUND 1 · SKETCHES

Co-sketched layouts with caseworkers to test the one-case-view idea before any detail.

ROUND 2 · PROTOTYPE

Clickable prototype tested with caseworkers on real tasks, with findings fed directly into the next sprint.

ROUND 3 · CODED

Tested the built service with serving caseworkers, including assistive technology users, before formal accessibility assessment.

ACTION 04 · DELIVER

Shipping it with engineering, accessible and tested

I worked closely with engineering to turn the redesigned workflow into an accessible, tested service, consolidating a fragmented 12-screen process into one guided workflow.

Working with engineering

  • Detailed specifications for every screen and component
  • Defined interaction states: empty, error, loading and success
  • Wrote acceptance criteria for each story
  • Paired with engineering through build to resolve edge cases
  • Documented the resulting patterns into the shared system

Accessibility

  • Designed to WCAG 2.1 AA standards
  • Full keyboard navigation with visible focus states
  • Compatible with the NVDA screen reader
  • Zero critical accessibility issues at formal assessment

Testing

  • Three rounds of usability testing with eight serving caseworkers, including assistive technology users
  • Task-based scenarios to identify improvements
  • Findings fed directly into each sprint

STAR · 4 OF 4

Result

RESULT · IMPACT

15 → 8 min

to complete a routine case update, almost half the time

68% → 94%

of records with every required field completed

12 → 1

fragmented screens consolidated into one guided workflow

−38%

reduction in average case processing time

92%

of caseworkers rating the new tool "easy to learn"

0

critical accessibility issues at formal assessment

RESULT · OUTCOME & REFLECTION

Less hunting, cleaner records, clearer accountability

By redesigning the service around real caseworker tasks rather than the structure of the legacy forms, I helped simplify the workflow, reduce unnecessary steps and make it easier for caseworkers to capture complete, consistent information. Caseworkers could now see and act on a case from one place, and the activity log gave team leads a trustworthy record of every change.

MEASURED RESULT

A routine case update took 8 minutes, down from 15 minutes on the old tool. Records with every required field completed rose from 68% to 94%.

Average case processing time fell by 38%, 92% of caseworkers rated the new tool "easy to learn", and the service had zero critical accessibility issues at formal assessment.

What I'd take forward

Discovery time spent watching real work paid for itself many times over: every major design decision traced back to something we saw caseworkers do.

What I'd do differently

  • Bring engineers into discovery. Having developers in research sessions earlier would have surfaced technical constraints while concepts were still cheap to change.

What's next

  • Keep measuring. Continue tracking task time and record completeness as the service evolves, to make sure the gains hold.
  • Extend the task model. Apply the same task-first approach to other case types and a team-lead view for allocating work.
NEXT CASE STUDY Transforming the Household Support Grant Application into a Digital Service VIEW →
Back to portfolio →