Central Government Department.

Redesigning a Government Department’s services.

Key Deliverables

Lightning Sprint

The challenge.

The way in which the Department gathers information, or submissions, is responsible for a number of downstream issues.

Poor submissions cause delays and inefficiencies in other areas of the Department’s work, with personnel being required to deal with information that hasn’t been submitted on time, which is missing key data, or which is incorrect.

The Department wanted to investigate the submission process and develop its understanding of the root causes of poor submissions, such as unclear guidance, and help users get their submissions right first time, alleviating many of the downstream pains.

The sprint.

Day 1  |  Understand

Day 1 was about getting to know the sprint team, discussing the challenges around submission of information and setting a sprint goal for what we wanted to achieve.

We spent the day asking “How Might We do X?, allowing the team to pinpoint challenges around submission such as incorrect documents, manual checking and confusing guidance.

We pinned these challenges on a process map which allowed us to see where the most significant pains were in the process, allowing us to focus our sprint.

Day 2  |  Sketch

Day 2 started by looking at existing services outside Government that had innovative and applicable features to inspire our sketches.

Looking at how organisations like Google, Monzo and Amazon innovate, inspired the team to think about intuitive and user-friendly ways to use their own platforms to submit requests or receive updates. Applicable and relevant features were recorded.

By the end of the day, we had sketched ideas for solutions for each area of the submission information process and presented these to the sprint team.

Day 3  |  Decide

We collated and reviewed all of the sketches and decided on which ideas to develop further and visualise through detailed drawings.

Of note, there were many overlapping ideas and we found that an easy platform with strict auto-validation, that would only allow entry of the correct information, was a popular concept.

We ended the day with a set of wireframes, a storyboard and a list of functions to carry forward into prototype.

Day 4  |  Prototype

Day 4’s goal was to develop the new workflows for case management and programming. The team worked together to decide on key features and capabilities and build out new streamlined processes with the developer.

The outcome of the day was a new and improved workflow design, from which the prototype would be based and developed on, on day 5.

Day 5  |  Validate

To test and validate the prototyped solutions, user testing was conducted on Day 5 to obtain valuable feedback from the primary users of the system. We conducted testing with both chosen users and via guerrilla research, with the aim of getting varied feedback.

“Quick links to services in Prototype 1 puts me on the exact road I want to be on“

Feedback suggested that the current website was dated, and that Prototype 1 was generally more popular with users in terms of design and service/media structure.

“The Lightning Sprints have energised the whole organisation. Even 4 weeks after we are still buzzing.”

Deputy Product Owner . UK Government Department