Design Sprint Phases

Case Study: Three-week Design Sprint for a Remote Team

The idea of conducting the design sprint usually starts with understanding of the need to go deeper into the main challenge. It is a perfect instrument to quickly validate any ideas and perhaps even give a new direction to the product.

Nowadays, we tend to go more online and conduct any team activities remotely. Sometimes it hits the team spirit, but design sprint is one of those activities that can pull everyone together and boost their collaboration.

The following article will reflect the case study of conducting the design sprint in the product company. We found the design sprint workshops to be a great tool not only for collecting any insights and designing the potential solution but also as a method to pal up with different team.

Just to remind you, the design sprint consists of a couple of phases. We dot not build and launch any product, we rather focus on exploring our users needs, designing and testing prototypes.

You may wonder why this article title states “Three-week Design Sprint” as a the classical Design Sprint lasts 5 full work days. We designed it in a different way since we did everything remotely. Our team had 3 weeks for the sprint that consisted of research and discovery phases, prototyping and validation phases. Our sprint included daily stand-ups, workshops and presentations to the stakeholders.

Design sprint starts not on the first day but a couple of days or even weeks before. I think you’ve understood what I’m talking about. Yes, it is a Planning phase.

So let’s stop a bit on the Planning phase.

Get Galya Hromova’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

I’ve seen some sprints starting without proper planning (for ex: lack of time for planning, not weekly goals, etc.), so I’ve created the checklist on things that should be planned ahead of time. Some items can be done and re-done during the sprint, since we’re working in an Agile environment, but I still suggest being prepared.

Planning Checklist

1. Define the overall goal.
   I like to have this step more related to the research question. For example our research question was: “How might we improve doctor’s experience outside the virtual visit with the patients?” We used the “How might we” approach. You may read more about it here. During each phase of the design sprint, try to keep in mind this question and remind the team about it if something does not go in the planned direction.
2. Narrow down the goals for each week.
   Every week had a presentation for the stakeholders showing the work that was done. It is important also to understand those minor goals. So for example, if we talk about the first week of the sprint, dedicated to research and discovery, we had a couple of goals: build strong communication within participants, conduct interviews, and synthesize findings into VPC (value proposition canvas). As you may notice, we had 2 different goals, one related to the team and the second related to the sprint goal itself. I can suggest defining high-level goals, but you may modify them after each week since you cannot predict the atmosphere in the team and how they will complete all tasks.
3. Recruit a group of participants.
   For sure, most participants will be folks from the design team, but try to involve Product Managers, Business Analysts, and even Developers at least for some part-time activities. We understood that for each phase of the design sprint we need 1 expert who will be leading each phase and at least 2 “proactive” core team folks who will help build any design artefacts. So in total, I would suggest having no less than 7 people but no more than 12. What is more, some participants can follow the whole sprint. Still some can be invited optionally and participate only in a couple of workshops. I’d recommend asking the Core Team to block their agenda and focus more on the design sprint. Recruit participants at least 1 month before, so they can plan their work and vacations properly.
4. Build the schedule.
   Try to build the schedule as detailed as possible, but keep in mind that you’re working in an Agile environment. Have the 3-week schedule designed, afterwords notify the participants. Set the recurring events with a proper agenda, so everyone will know what to expect during the session. Also, ask the team to block their calendar for some “offline” work that they will be asked to do.
5. Choose activities.
   During our sprint, we spend a considerable amount of time on research. In case you’re doing any moderated interviews, schedule them beforehand. You may even use some voucher gift cards as compensation for the respondents’ time. Set all templates in Miro for the ice breaking, retrospectives, and other activities.
6. Know the tools.
   Since we’re doing a remote collaboration, our participants need to understand how to use the applications. We use Confluence or Notion for documenting any final information and Miro for collaboration purposes. You may ask participants to review those tools beforehand or even schedule a meeting to onboard them and show how those tools can be used. There are a lot of different helpful features in Miro, such as timer, video chat, voting, etc.
7. Notify the stakeholders (decision-makers).
   Make sure the stakeholders are aligned with your goal and schedule. What is more, try to present a summary of every week sprint outcomes to them, so they can review what was done and guide you through the sprint.
8. Video calls communication.
   We’ve noticed that people who have their cameras turned on tend to be open and engaged. So kindly ask to turn the cameras on, it is not a must but it can be great to see people with whom you’ll work side by side.
9. Prepare the final template presentation.
   Try to design the layout and have some key items listed in your final presentation. It is also great to add the items that you’re planning to cover during the sprint there.
10. Last but not least: be flexible!
    Some participants may not attend planned activities or it may take them more time than expected. What is more, new creative ideas may appear during the sprint. For example, someone will suggest any activity that will fit our research question. Be patient, open to new ideas, and try to update the timeline accordingly. You need to keep in mind some risks beforehand, so you will be prepared and will not feel upset.

Let’s move to the next step of actual items that we’ve covered during the Design Sprint.

Week 1:

• We started our first stand-up with some ice-breaking activities. As it was mentioned above, we used Miro as our collaboration tool. I can say there are tons of different templates that you may use from the Miro community.
• What is more, the first day was also dedicated to additional activities. Our facilitator shared the schedule for the sprint, defined goals and introduced main experts from the UX and UI team. The Product management team listed problem statements.
• During this week, we’ve created the script for the interview based on the research question.
• We interviewed 12 different respondents that matched our personas and synthesized findings using an affinity diagram. We also sorted all quotes from respondents into 4 categories: jobs, pains, gains, quality parameters and built a VPC.
• On Friday, at the end of our meeting we conducted the Retrospective, the reflection exercise and asked all participants to answer a few questions:
  - What important information have we discovered this week?
  - What was good?
  - What can be improved?

Everything was documented in Miro, and we did this retrospective exercise every week, which helped us understand two key items: “Are we getting better week by week?” and “What can be done differently during the next sprint?”.

Week 2:

• Once we gathered and synthesized all data, we asked the team to review a VPC, and based on it, we conducted the Brain writing exercise, which is an effective tool for rapid brainstorming. We determined that we needed to build the dashboard for our doctors. Our problem statement was “How might we improve the current dashboard for all doctors’ types?” This exercise was done during one of the collaboration sessions (since it covered the main need for the outside the visit experience).
• Following the research, we decided to focus on taxonomy, so we did the unmoderated open card sorting with both respondents from moderated interviews and some respondents found in the usertesting.com panel. We had 40 cards, and we’ve taken key items from the current application and combined them with the most mentioned from the interviews respondents.
• A couple of team members were also focused on listing down simple Jobs stories followed with use cases.
• We prepared the inspiration board of any solutions which we’ve found on the market with both features ideas and UI layouts. Basically, we asked participants to prepare the mood board and to sketch any ideas. Some participants also presented paper sketches and explained their ideas.
• Once we reviewed the inspiration board, we had a 1 hour workshop where everyone were able to sketch their ideas. Some of the participants used simple paper sketches, other more professional instruments such as Sketch and Figma applications. Participants also voted for the best solution.

Week 3:

• At the beginning of the first week, we asked UX designers to build high-level prototypes. We just had time to design the main dashboard, so once it was ready, we’ve built the test plan in usertesting.com and launched our prototype test.
• Once the usability test was completed we synthesized findings from our test. The good thing about usertesting.com is that it gives you fast feedback. Just one hint: if you want to use it in the future, focus on target users and screening questions. The more specific screening questions you will set, the best relevant audience you will get.
• What is more, UX designers made updates to our prototype and UI designers started the UI phase. UI designers used a list of features, user’s feedback, and mood board to build the hi-fi mockups. We asked them to create key screens that were presented to the stakeholders together with all artefacts from previous weeks.

As the conclusion, we summarised all findings into the PowerPoint presentation and shared it with the stakeholders. We tried to focus both on the research and “lessons learnt” from the sprint.

Plan of the presentation was the following:

• Into (goal)
• Summary of each week activities and outcomes
• Information about the participants
• Research discoveries
• Lo-fi prototypes & fi-hi mockups of main screens
• Lessons learnt (information from weekly retrospective)

References:

• You may use other methods in your design practice, a great design kit of all HCD methods.
• There is a book about the design sprint that I would recommend to read.
• You may refer to NN group, they have tons of valid and useful information about remote workshops.