Could “Design Sprints” Work in Government?
Civic Hall Toronto looks at how design sprints can become a way to rethink digital service delivery for government.
“Design sprints” have become a quick way for tech firms to test drive a new idea without spending months in the development phase. Firms like Slack, Shopify, and Blue Bottle Coffee have successfully used design sprints to re-tool their core products and services.
But can rapid exercises like design sprints work in government, where teams can spend months — even years — shepherding a new program or service into existence?
Part of Civic Hall Toronto’s mission is to take expertise from the tech sector and apply it to government; one way we do this is by coordinating events for learning and cross-sector networking. On July 26, Code for Canada fellow Christine Lee spoke with Civic Hall Toronto government members about her experience bringing sprints and other design thinking concepts into the public service.
“Working together in a sprint, you can shortcut the endless-debate cycle and compress months of time into a single week.”
An accomplished product manager, Christine showed how design sprints can be a useful tool for government innovators, allowing them to experiment with creative service delivery models under a constrained timeline.
“It’s a huge culture shift for government, but from my perspective, senior management is more receptive to these ideas now,” said Christine.
Over the past six months, Christine and two other Code for Canada fellows have been embedded in the government of Ontario’s Ministry of Training, Colleges and Universities, collaborating with civil servants to help adult learners better access education resources.
As Christine’s presentation at Civic Hall Toronto got underway, many of the civil servants in the room scribbled notes and whispered ideas about how they could integrate design sprints into their own work processes.
So how does it work exactly? Typically, a design sprint lasts just five days, with a prototype completed by Day 4, and a product review by a small group of users on Day 5.
“Working together in a sprint, you can shortcut the endless-debate cycle and compress months of time into a single week,” Christine said.
Day 1: Start at the end
“Day 1 is all about creating a shared understanding with your team, but it’s also about understanding the problem, and selecting what part of the problem you want to focus on,” said Christine.
The team does this through an exercise called “start at the end” which asks members to envision all the challenges they’ll face during the project run, and then write open-ended “how might we..?” questions on sticky notes to address some of these problems.
Day 2: Sketch out, don’t write out
If Day 1 is about problems, then Day 2 is about solutions. Taking a step back and looking at the “how might we..?” questions on the sticky notes, team members then work individually and sketch or draw simple solutions to the problem.
The sketches don’t have to be pretty — a couple of stick people, blocks, and word balloons is more than enough. Once your sketches are complete, they all go into a pile to be reviewed anonymously the next day.
Day 3: Getting the best decisions on the board
Now it’s time to place the sketches up on the board, and review them individually. “It’s not about feasibility, it’s about getting the best decisions on the board,” said Christine.
Teams then work in silence, drawing dots or placing stickers on sketches they think present the best ideas, with the team leader ultimately deciding the final idea the team will run with.
Day 4: Prototyping with the tools you know
When it comes to design sprints, the software tools you have at hand are good enough. “It’s not about perfection, it’s about usability, you’re trying to make it as real possible, while still producing a product that’s quick and dirty,” Christine said.
“It’s not about perfection, it’s about usability.”
That means working with easy-to-use software like Powerpoint, Keynote or Google Slides to mock-up a prototype, and leaning on organizational software like Trello and RoadMunk to keep you on track.
Day 5: Get your idea in front of users quickly
Now’s your opportunity to let your target audience see your work. After corralling five users to look at your prototype, one team member facilitates a one-on-one interview with the user, asking questions about what they see, and get them to think aloud while playing with the product. With real user-testing data in your hands, it’s time to ask if your idea stands up to scrutiny.
Do users see your prototype as a solution to their problem? If users don’t respond to your idea, that’s alright too. In the end, you come away with valuable feedback about your assumptions, and you don’t spend months or years developing a program that users don’t respond to.
Making it work for government
As Christine wrapped up her presentation, some of the civil servants had questions about how to integrate design sprints into their ongoing programs.
“The characteristics of this stuff is what we use already, we did this as a gut approach before, but it’s cool to see how it all fits together,” said one of the attendees. “It would be great to use this process for a specific project, and see how it goes.”
But there was also questions on how it would mesh with the lengthy procurement processes common in the public sector. In Silicon Valley, there could be dozens of releases in the course of a development cycle. In government, a single product release could be years in the making.
“The fact that it needs to go to a governing body, and a dull series of cycles could make these sprints prohibitive. Often times, they just want to hear about it once, and then not hear about it for another three years,” said one attendee.
Christine says integrating design sprints takes time and practice, but she emphasizes the importance of setting clear expectations when using design sprints to build new government programs. She suggests re-framing the process as a way to mitigate risk and prevent future problems with program rollout.
“Failure can be interpreted the wrong way in government. You have to frame sprints and user testing as an intentional process, framing everything as a hypothesis,” she said.
Introducing design thinking into government won’t happen overnight, but the willingness of Civic Hall Toronto members to discuss and debate the merits of sprints is already a small victory for government innovation.
