A one-week sprint with inspectors to test a case-management idea before anyone signed a contract.
Choosing a case-management tool too early risked locking in the wrong workflow.
Ran workshops, mapped current casework, and developed testable prototypes.
Clarified what future case-management support needed to include.
Helped the team move quickly while staying grounded in how inspectors worked.
A government planning and regulation body needed to understand how inspectors and case teams could manage complex cases more effectively. There was pressure to move quickly, but also a risk: procuring or implementing a tool before understanding how people actually worked could lock the organisation into a solution that did not fit.
Rather than running a long discovery or jumping straight to procurement, the team used a lightning sprint. We brought inspectors, case managers, and internal staff into a structured process of mapping the problem, generating ideas, prototyping concepts, and testing what better case management could look like.
My role as a mid-weight service designer was to support the sprint through research, workshop activity, mapping, synthesis, and prototyping, turning messy input into clearer concepts the team could discuss and test.
Case management for complex planning work could not be properly understood from process documents alone. The real complexity sat in how inspectors and case teams worked day to day: how they found evidence, tracked progress, managed deadlines, shared information, and made decisions.
If the organisation moved straight into procurement without that understanding, there was a real risk of buying something that solved document storage without supporting actual casework, leaving inspectors with a tool that did not fit how they worked.
The team needed a way to learn quickly, get evidence in front of decision-makers, and test ideas before committing to a solution.
The sprint combined workshops, co-design, rapid synthesis, journey and workflow mapping, prototyping, and testing with the people closest to the work. Inspectors and case teams helped us understand how cases moved through the organisation, where information got lost, where admin slowed them down, and what they needed from a future case-management service. Because the work was visual and prototype-led, the team could move quickly from abstract requirements into something people could react to, which helped expose assumptions early and reduce the risk of committing to a tool that did not reflect how inspectors actually worked.
The real complexity was in how inspectors and case teams worked day to day: finding evidence, tracking progress, managing deadlines, sharing information, and making decisions. A sprint format let people map and explain this together, which helped surface it quickly.
Inspectors, case managers, and internal staff were all involved in case progression, but they experienced the pain points differently. Bringing them into the same workshops surfaced where handoffs broke, ownership was unclear, or information went missing.
The organisation could have rushed into procurement, but without understanding the work properly, it risked buying something that stored documents but did not support the actual job. The sprint gave the team what they needed to know before locking in a decision.
Instead of debating abstract requirements, the team gave inspectors and staff something to react to. That made it easier to see what worked, what did not, and what needed to change.
The sprint gave the organisation a faster route to learning. It did not replace deeper delivery work, but it gave the team enough evidence to make better next-step decisions.
The lightning sprint moved the organisation quickly from uncertainty about inspector case management to a clearer, co-created direction. It created a shared understanding of the casework problem, surfaced the needs of inspectors and case managers, and turned early ideas into prototypes the team could discuss and test.
The work reduced the risk of jumping straight into procurement or implementation without understanding the service need. It gave the team a practical basis for deciding what the future case-management service needed to support: workflow, evidence, role differences, deadlines, handoffs, and decision-making.
The main value was speed with substance: a short, structured design process that helped the organisation learn quickly before making bigger delivery decisions.