Policy making is hard. Coming up with different ideas to answer a problem is even harder.
A design sprint can help. The purpose of a design sprint, is to embed design thinking principles in the way you work.
Design thinking utilizes elements from the designer’s toolkit like empathy and experimentation to arrive at innovative solutions. By using design thinking, you make decisions based on what future customers really want instead of relying only on historical data or making risky bets based on instinct instead of evidence. — IDEO
Trawling the excellent, design sprint kit from Google, I’ve came up with a structure I think will work best with policy makers.
Photo by Pixabay https://www.pexels.com/photo/abstract-blackboard-bulb-chalk-355948/
Before you start your design sprint
I recommend circulating the information below to participants of the design sprint before you meet.
Introduction Provide a brief two sentence summary about the policy area.
Current state of the project What’s happened so far? Who have you spoken to? What are the user needs?
Problems What are the main problems identified so far?
Team structure Who do you want at the design sprint?
For example:
- Policy professionals — they know the policy area
- Delivery manager — help with keeping the design sprint on track
- Product manager — makes sure people keep the user in mind
- User researcher — help with user testing
- Service designer — help with prototyping
- Content designer — help with writing content
- Technical architect — help with conversations around technology choices
Top tip: I recommend key decision makers attend. Design sprints help to build a shared understanding. Hopefully, after the design sprint, these key decision makers will become your biggest advocates, mainly because they’ve had an opportunity to contribute to the discussions.
Sprint challenge What are you hoping to achieve in the design sprint? Do you want to explore different options for a policy?
For example: The Secretary of State (SoS) wants a feature on a website, to help people affected by X. The SoS wants you to design this feature by next month. Are you up for the challenge?
Deliverables You want to produce clickable prototypes as an output from your design sprint. If this is not possible, then simple paper prototypes are fine.
An experience map describes the emotional state, behaviours, interactions, expectations, and journey of a user. A two day design sprint structure makes this output difficult to produce — if you have time though, this output is valuable.
Key phases of a design sprint
-
Understand: the team comes together to explore the business problem from all angles.
-
Sketch: team members are given the time and space to brainstorm ideas on their own.
-
Decide: is when the team chooses which ideas should be prototyped.
-
Validate: users interact with the prototype.
Finally:
-
Decide on a venue
-
Buy materials needed for the design sprint e.g. sticky notes
-
Make sure you have the right tech in place e.g. for user testing
-
Recruit users
-
Recruit speakers for lightning talks (I talk about this below)
Photo by picjumbo.com https://www.pexels.com/photo/notebook-beside-the-iphone-on-table-196644/
Sprint schedule day 1
Please note: I will link to more information about the activities.
9–9.30 am Arrival and set-up for the day
9.30am Welcome, overview of sprint and rules (5 mins), introductions between team members (15 minutes), introduce the challenge (3 mins), direction for ‘how might we’ note taking method (2 mins).
I recommend reading about ‘how might we’. Google do an excellent job of explaining why it is helpful.
10am Get people inspired by running 10 minute lightning talks.
Suggested lightning talks:
- One around the policy area
- One around the competitive landscape
- A talk from a user
- Playback of any previous work
As people are speaking, make notes on sticky notes by following the how might we method.
11am-12pm Ask people to place their sticky notes onto a wall. As they do, get them to talk about their ideas. Group similar sticky notes together. Groups/ideas/themes will start to emerge.
After grouping, dot vote on the idea that stands out to you. Each person gets three dot votes. The policy professional gets five dot votes — mainly because they are ultimately responsible for the policy area.
12–1pm Lunch — time to refuel those batteries.
1–2pm Crazy sketching time. Release your inner artist! By yourself, sketch 8 different ideas, in 8 minutes. You can have longer if need be — hence why I allowed for more time here.
Again, I won’t go into too much detail about this technique as Google do an excellent job explaining the concept. Ultimately, this exercise is about coming up with a bunch of different ideas — fast.
3–4pm Present your ideas back to the group. Crit, challenge and discuss the different ideas presented.
4–4.30pm Solution sketch time. The purpose of solution sketching is to narrow down your ideas into one, well defined idea. You may find yourself liking some of the ideas presented — take them and incorporate them into your own if you want.
4.30–5.15pm Present your solution sketch back to the team. Choose, which idea you all like by dot voting on your favourite. This is what you will prototype.
Sprint schedule day 2
9–9.30am Arrival and settle in.
9.30am Recap yesterday’s events. You have settled on an idea you would like to prototype by this point.
10.00am Prototype time!
Google’s Design Sprint Kit talk about the different ways you can prototype here.
How you prototype depends on the skill set you have in the room. Creating wireframes using pen and paper is fine. Alternatively, you can use basic tools like Balsamiq to prototype.
If you have a multi-disciplinary team:
- A designer can mockup a visual
- A content designer can work with a policy official to write content
- A user researcher can prepare the user research script
- Identify a person to ask questions (this can alternate)
Importantly, you want to produce something of sufficient quality, which you can then present to users.
Photo by Kaboompics // Karolina https://www.pexels.com/photo/working-in-a-group-6224/
1–2pm Lunch
2–3.30pm Validate your prototype by testing it with users. Ask broad and open questions, and ask your users what they think about your prototype.
Aim for five user interviews. Be sure to take breaks, and make sure you have an opportunity to debrief.
Further reading:
3.30–4.30pm Debrief, and discuss the day’s event. What did your users say? What stood out to you?
If senior leaders have been unable to take part in the design sprint, then this is a good opportunity to present back your findings to them.
Conclusion
A design sprint is a good way to inject design thinking into policy making. Usually, design sprints last five days. I went with two days, as policy makers are busy people, and I wanted to maximise the time I had with them. Do what works for you. I recommend reading Google’s Design Sprint Kit in more detail.
Good luck with your own design sprint!
