LabPlus: What do design sprints, game design and government have in common?

Guest blog post by Dr Hazel Bradshaw, Service Innovation Lab service designer.

TL;DR

As a member of the Service Innovation team, I recently ran an adaptation of a Google Design Sprint to unpack the requirements for an all of government service analytics solution.

I specialise in design approaches for the creation of serious games; a serious game being a game designed for a primary purpose other than pure entertainment. (If you want a dive into this field you can access my thesis on Structural Playability for the detail.) Read on if you’re interested in how to run an adapted Sprint over 3 days integrating principles from serious game design. These approaches can be useful for designing engagement strategies for better government services.

Game design approaches for greater service engagement

A Sprint usually takes place over 5 days and brings together a core team of designers, experts in their fields, and decision makers. For this Sprint however I needed to fit it into 3 intense days while also adapting the standard format to bring in elements of game design practise.

Game design approaches are useful as we deliver government services. A game aims to engage its audience with challenges which increase in difficulty over time and provide feedback and reward for actions taken, and be fun, engaging and enjoyable. If we can design services with similar engagement, we can reduce levels of confusion and frustration and promote confidence in our systems for citizens when they access government processes.

Service analytics design sprint

The challenge for the Service Analytics Design Sprint was to explore what a positive, effective customer experience looks like when based on a real-world life event (see this blog post about the value of life events). The desired outcomes were for a quantitative solution, using analytics to support three prioritised project deliverables:

1. a reporting dashboard
2. a user journey map
3. a recommendations engine (API or Application Programming Interface).

The outcomes of this work provide an opportunity to demonstrate an all of government solution from our proof of concept. 

Intentions we wanted to explore in the design sprint:

• Method for implementing joined customer data for reporting collected via Web and contact centres
• Creation of anonymised heat-mapping of user flow patterns
• Highlight service use-patterns across a range of interaction points
• Reveal service bottle-necks, dead ends and successful interactions
• Understanding the customer journey via joined-up web and in-real-life experiences
• Create opportunities for deeper data analysis to reveal statistical relationships between services
• Generating useful data to inform decisions on service improvements
• How a recommendations engine functions to support customer experience

The outcomes from this Sprint will form a series of future blog posts so keep an eye out for them. 

Our Design Sprint structure looked like this:

• Day 1: Gather/ Define – Define the problem and assess solutions
• Day 2: Ideate / Storyboard – Exploring solutions – feasibility, capability, usability
• Day 3: Prototype / Decide – Rapid Prototyping our solutions | Decide on prototype to build

Day 1 - We gathered information on our topic and defined what our problem space looked like. Applying game design practise involved defining clear end-goals, understanding audience types and mapping motivations (inner drives or external pressures). Game design always prioritises creating the best player experiences possible, and this should be the same for government service design.

Day 2 –We listed the features and qualities of each solution and mapped them back to each identified problem, so we could outline scenarios.

In game design we apply narrative threads to move a player along a gameplay path. In designing government services our customers must navigate through a defined process path. Neither players nor government customers fully understand their path when they begin.

The scenario must have a simple narrative written from the audience perspective. At the end of this process our design sprinters rated each scenario against their feasibility, capability and usability.

• Feasibility – is this feasible within our constraints?
• Capability – are we capable of building a solution that fits this?
• Usability – will the target audience be motivated to engage with what we have proposed?

Day 3 - We visualised all the content previously uncovered, took our highest rated scenarios and created a storyboard to reflect our imagined user journey. From our storyboard we created very low fidelity (Lo-fi) prototypes or mock-ups of the experience. Our prototypes enabled us to test our assumptions and design decisions with real end users and audiences.

If we adopt fast and efficient prototyping techniques such as the Google Design Sprint process, and combine them with the user centric focus of game design, we can fast track scoping and discovery of our service solutions and make sure we build the right thing for the right reasons in the right way - with the end user at heart.

If you would like more information about this design sprint or any of the other work in the Service Innovation Lab, please comment below or get in touch with the team. We’d love to hear from you.