6 tips for a productive remote design sprint
How to leverage the advantages of a fully digital design sprint and create an effective team.
As a product designer at de Bijenkorf, design sprints have become a useful tool that allows us to align more efficiently across departments on complex problems so that we could minimise the risk involved in costly development and get customer feedback early. I won’t go into much detail on why to run a sprint or how to run it, for that, you can check out one of these resources:
Over the course of the last year, the sudden transition we had to make from in person to remote design sprints presented us with a few new challenges but also led to some amazing new ways of collaborating. In fact, it works so well, I wouldn’t be surprised if running design sprints remotely becomes our new norm! I won’t go into detail around the challenges but instead the core learnings so that hopefully you can jump over these problems and get off running on your next design sprint.
In short, these are the tips that I will explain further:
- Set up your toolkit
- Make sure you understand the business and customer problem(s) before you start
- Prepare & collect everything in one space
- Create a manageable team size
- Share and get feedback daily
- Make sure to plan some fun too
Set up your toolkit
You simply cannot run a remote design sprint without some great tools thus here’s our list of what worked for us (but don’t be afraid to find something that works well for your team):
- Miro (We gather and work entirely within this space. You could alternatively work with any digital whiteboard or even Figma!)
- Figma (Our design tool where we had everyone designing together no matter their role in the company!)
- Userbit (Used for taking notes and tagging during the interviews so that we could quickly make sense of user interview insights.)
- Lookback (Used for viewing and recording user interviews. Everyone could easily observe without overwhelming the user and allowed us to easily contact the researcher with any further questions.)
- Microsoft Teams (For team interaction but Slack or other video networking services also work well.)
- Kahoot! (We created an icebreaker quiz before the sprint began that helped set the stage for the week working together.)
Make sure you understand the business and customer problem(s) before you start
This is something that I can’t emphasise enough: make sure you know what you are trying to solve BEFORE you start the sprint! If you go in with the goal of discovering the problem, you will end up with days of back and forth debate around what problem is most important to solve. It’s not impossible to get done but it does result in some frustration and chaos. Remember that your goal is to validate an idea with customers. If you have a large team, it’s possible to even break down into groups to tackle each idea separately (see my manageable team size tip for more details).
But what if my customer problem is hard to define? I’ve been in this situation and what ended up working out was the idea to create a comparison user test that allowed customers to experience both the current and new solutions. In this way, we could see if customers actually felt like one design was better than the other with the goal of understanding what problem they felt it solved. While this worked for us at the time, an alternative idea would be to include customer interviews earlier in the sprint as well.
Prepare & collect everything in one space
As I just mentioned, you should have already discovered the problem you are trying to solve before the sprint begins. It’s useful thus to have the data and other insights all collected in the same shared workspace where you will be working. In our case, that’s our design sprint Miro board which starts out from a template looking a bit like this (we modified this 4 day design sprint template already available in Miro so it’s quick to repeat and get rolling):
On this Miro board, we collect all of the insights that we may be able to find before the sprint begins. Relevant insights could include:
- Personas (even an adhoc persona is a great start)
- Customer journey map (especially zooming into the portion where your problem occurs)
- Customer insights (Google analytics, session analysis, survey results, etc)
- Competitor analysis / examples
- Business KPI metrics that you want to improve
I’ll dig into the value of the first 3 and provide some quick set up tips to get you started.
A persona gives a relatable human form to the customer having the problem you are trying to solve. It helps you frame the focus of the design sprint and will help you understand when you are on the right track or veering in the wrong direction. It doesn’t have to be fancy and can be something you quickly put together based on knowledge you already have of your typical customer. Simply highlight their needs and their expected behavior so it’s clear how your solution could best solve their problem.
Here’s a simple ad-hoc persona example we put together with some help from Hubspot’s free persona generator (you can also mock it up using any tool of choice, even directly on your Miro board):
Customer journey map
By placing your problem in the frame of the customer’s journey, you can more easily capture what happens before or after that point of interaction. It helps to give you an idea of where to focus during your design sprint. Some problems could potentially occur at various positions in a customer journey as well which is then interesting to include in your map so that you can decide where to focus after all of your insights are brought together.
It may seem like a huge task to create a journey map, but for design sprints, the key is to keep it simple and focus on what you need. In our case, we’ve used the journey map as a great place to gather any questions we had, customer insights we’ve found, and customer needs. Instead of doing the mapping exercise as a group during the sprint, we could skip forward to mapping our HMW’s on this journey map directly.
Here is a small snapshot of what that looked like for one of our sprints:
When you think back to the original definition of your customer problem, it’s possible that you were led to the problem already through some form of customer insight. This could be drop off rate, or conversion rate, or simply the result of some customer feedback. All of the insights that led you to your problem is relevant to capture and share.
It’s also valuable to try to explore the problem as much as you can before the sprint and highlight anything you can find from the resources you have available. In our case, that usually means exploring Google analytics, session analysis, and survey feedback. But if you have limited means for gathering direct customer insights, it’s also possible to explore industry standards or gain knowledge from experts, such as Nielson Norman or Baymard.
Exploring the problem in advance doesn’t mean that you skip the expert interviews. We’ve found that having a good understanding of the problem in advance helped us to create more triggered questions for our experts and gather more insights into their specific business goals. We would use the time with our experts as a way to learn from their experience in order to get a clear picture of where we have been and where we want to go.
Create a manageable team size
The ideal team size is usually between 5 or 7 people. But as we discovered when we transitioned to remote design sprints, this number could easily grow as it became easy to include entire teams. We’ve managed to have design sprints as large as 15 people! As a facilitator, it can be a daunting task trying to keep everyone on task and engaged with such a large group but it’s not impossible. With just a few tweaks to how you work, it’s possible to have a large team working together efficiently.
Key tips to tackle larger team sizes:
- Break out into groups as often as you can
- Assign a co-facilitator
- Get extra designers (for every 5 people, there should be 1 designer)
Breaking out into groups is important to do any time when you have activities that require team coordination (such as when mapping the HMW’s or when designing the prototype). This is where we had found the customer journey map useful as it helped us naturally create “groups” for each phase of the journey. This isn’t always possible, so it’s important to break down your problem into logical groups with a clear focus.
Here are some possible ideas on how to break out your groups:
- Different points on your customer journey: This is the easiest method and allows you to break out earlier during your sprint already on day 1 when you begin mapping the HMW’s. Each group is responsible for a different position on the journey map. In this way, we were able to create a full solution in just one sprint leveraging the power of 15 people working together.
- Solving the sprint questions: On day 1, you identify the main sprint questions you’d like to solve that week. After you’ve identified these questions, you can then break out in groups focused on separate questions already during the HMW’s mapping and again on prototyping day.
- Focusing on different parts of the solution: Perhaps you’ve made it all the way to prototyping day without being able to find separate focus areas. That’s ok but now it’s important that you break out into groups trying to get the work done. Depending on what you need to deliver, break out the design, user test plan, and any other work into separate working groups.
As a facilitator, make sure to give each group instructions on what they would need to do together during their break out sessions. You and your co-facilitator should share the task of checking in on different groups in order to answer questions or help focus the activities.
Share and get feedback daily
Even though you may already have a large team including most of the important business stakeholders, it’s still especially important to loop others back into the discussion daily. When we ran design sprints in person, we would ask stakeholders to simply stop by throughout the day. This didn’t seem practical for remote design sprints so we set up instead an “end of day” review session where we invited anyone that may have interest in the project.
What made these sessions especially efficient was tracking input directly on our journey maps or designs in order to incorporate into further iterations the next day. This basically was nothing more than including a “questions & comments” section at the bottom of our Miro section for the day. We would start our next day with a few minutes looking over the comments so we were sure to stay focused in the right direction.
Make sure to plan some fun too
This is actually perhaps one of the most important tips to keep in mind. Sitting together for 4–5 days can be exhausting if you don’t introduce some fun moments to look forward to each day. For our design sprints, we like to start with a Kahoot! icebreaker quiz and end each day with a “fun hour” where we would socialise as a team. This keeps us united during the week and able to keep moving forward with full energy throughout. If you have a large team, it’s great if a co-facilitator can also occasionally send out a pop-quiz during the day to keep the team laughing and energised.
While it’s been a year full of unexpected changes, the change to running fully remote design sprints has been one of the most rewarding experiences for me as a facilitator / designer. I’ve enjoyed the challenge of tackling design and coordination with larger diverse groups, leveraging design methodologies and new collaboration tools. I hope this article can give you just a bit more help in preparing for a remote design sprint using the lessons I’ve learned along the way.