Design sprints on health

Editor’s note: The health team works closely with the Ministry of Health and Long-Term Care to make it easier for people to find, use and understand health information and services.

Hello, my name is Nujhat, and I support the experience design chapter at the Ontario Digital Service, on a team who is empowered to work in an agile way to make it easier for people to find, use and understand health information and services.

We use an agile framework in our work, which essentially means bringing a product focus to problems and designing based on user needs. This approach is common in tech companies and across the private sector. It helps to break down bigger work into smaller pieces, and enables us to test our assumptions in real-time through a series of ‘sprints’ that we run over several weeks.

How we work

Continuous improvement is core to adopting an agile approach. The team’s workflow is sketched out with pencil, and we get our erasers out if we think of a better way to deliver a superior product or result. Lately, we’ve been experimenting with a modified version of Google Ventures’ Design Sprint method as a way to test and refine our designs before agile development begins.

This method isn’t necessarily how you should do agile in government; it’s how you can do agile in government. Teams may wish to iterate on this structure and approach, based on your unique organizational needs.

Two-week design sprints

A design sprint is a short process to design and test a prototype with users.

Every sprint focuses on a specific section of the product. Sometimes, we work on a brand new idea; sometimes we like to take a step back and refine existing work, based on what we’ve learned. In both cases, we zero-in on a specific area of the product, and delve deeper to better understand our users’ needs.

Our schedule is pretty flexible, and we change it up, based on each project’s needs.

An User Experience (UX) Designer leads these sessions, but people from product management, content, tech and health subject-matter experts from our partner ministry participate to ensure that we get input from different perspectives.

This is an important element of the design process because the user’s experience, through information or a service, and content design that supports that experience, ought to be considered at the start of any project. Good content cannot be an afterthought. It’s integral to helping users navigate information and complete tasks online.

Sprint structure and process

Image: Snapshot of two-week design sprint schedule

Week 1: Topic selection, sketching and prototyping

This week, all of our activities are geared towards getting a prototype ready for user testing.

Monday: Topic selection

• We meet first thing in the morning to decide on the focus of our sprint. In the past, we’ve focused on how to best plot locations on an interactive map, how to lay out content-heavy information, and how to include filters on a search feature.
• Everyone on the team researches inspirational materials for the area that we’re focusing on. We ask ourselves questions like: “who else is doing this well?”, “what does their solution look like?”, “what’s applicable to our work?”.
• We then collect examples of these solutions for discussion.

Image: Health team during design sprint

Tuesday: Initial sketching and recruit test users

• We meet to identify the ideal participants we’d like to test with, and formally launch recruitment. This requires you to have your broader testing pool lined up in advance.
• In the afternoon, we regroup for a working session where we: review everyone’s inspirational materials, sketch initial ideas for the prototype based on the group’s findings and discussions, design as many lightweight prototype options as we can in the time we’ve got (this could range from 4–8 concepts per person; keep in mind we’re talking “napkin sketch” level of refinement here) and vote to choose the team’s favourite concepts.

Wednesday: Sketching refinement

• We spend the morning refining the sketches from the day before and continue voting on our favourite ideas.
• We review and analyze the most popular sketches to find similarities.
• The outcome from our working session is more detailed sketches that our user experience designer will use as the foundation for the prototype.
• We start contacting potential participants for user testing.

Thursday: Prototype building

• The user experience designer builds a simple front-end prototype, based on the sketches from Wednesday’s session (we use Figma for this step).
• The user experience designer creates or modifies our user testing script, depending on the focus of the design sprint.

Friday: Prototype review

• The user experience designer completes the prototype before the end of the day.
• The team reviews the prototype as a group to ensure it’s ready for testing.

Week 2: User testing, prototype refinements and retrospective

This week, all of our activities are geared towards understanding user needs, validating (or finding contradictions to) our assumptions and refining the prototype through testing.

Monday: User test planning

• We develop a quick testing plan so we’re all clear on our focus for the week ahead.
• We draft the testing schedule and user experience interns distribute invites to the entire team, including our partners at the ministry and anyone at the Ontario Digital Service who’s interested in watching the sessions.

Tuesday and Wednesday: User testing

• The user experience designer leads the testing sessions (either in-person or remotely). We aim to test with 5–10 users for each sprint.
• Each session lasts one hour, where the user is asked to interact with our prototype and give feedback. Sometimes, we provide sample tasks for users to complete, and sometimes we’re just interested in seeing how they navigate the product on their own.
• We all watch the user testing sessions and take detailed notes that we compile for reference.

Thursday: Testing review and refinements

• We analyze the team’s notes to find common themes in what our participants described during the testing sessions.
• We review what we learned during user testing as a team.
• The user experience designer shares design recommendations.
• We make refinements to the prototype based on all of the above.

Findings from a brainstorming session

Friday: Retrospectives

• We meet with senior leadership at the Ministry of Health and Long-Term care to brief them on what we heard from users, and chat about how the prototype should evolve as a result.
• The product manager leads a retrospective, where our team shares what we did well, and we we could have done better during the sprint.

Sprints are a continuous cycle

We repeat this two-week process until we have a fully fleshed out prototype that yields consistently positive feedback from users.

This approach isn’t the only way to do design sprints. It is a method that works for our teams, based on trial, error and iteration.

Get in touch

We wanted to share a little about how we do things, in the hopes that anyone who is interested in adopting similar practices can use this as a place to start.

We’re also curious to learn from other teams doing design sprints.

What do you do differently? What worked well for you? What did you learn from times when things didn’t go as planned? Please let us know in the comments section below this post, or reach out to me.