This in an update to the original blog post "The remote design sprint" originally published 17th August 2020

As a UX design agency, we create solutions for websites, products and service. We want the design process to be clear and involve everyone, and found our solution in remote design sprints.

Why use the design sprint?

Gathering your entire team in one place can be challenging. We may miss important information or insights when we settle for just "those who can make it."

Working remotely and taking a remote-first approach maximises input from the team. It also gives all stakeholders and contributors opportunities for a truly collaborative process.

This article explains how a remote design or discovery sprint can speed up and improve in-person processes.

The Design Sprint 

Running design sprints is an exciting activity, it always fixes problems much quicker than traditional methods. We work to get a solution ready to test and develop in just five days. We will start by breaking down your design problem on day one.

Google Ventures created the Google Design Sprint methodology, a standard instrument for efficiently designing, launching, and testing products. At GrowCreate, we have developed our standardised formats to better align with our client's needs. 

Our UX and sprint design team rapidly progresses from a problem to a tested solution. We use a streamlined process where each day has a clear outcome.

We’ve created a collection of design sprint workshops to better accommodate project needs. Each scales from a single week to a three-week sprint to ensure our clients get what they need. Our design sprints allow us to create a solution framework, a prototype, or any solution to your problem.

A screenshot of an online call on teams with a screenshare of a FigJam document
Our team facilitating an online workshop

Making design sprints remote  

You may be familiar with design workshops. The room is too stuffy and too hot, and the food served during lunches is well-prepared meal deals. Travelling to the distant agency office takes forever and loses you valuable work time.

During lockdown, remote sprints and working was the standard. We saw how much easier remote sprints were than alternatives. So, we ditched the office and switched to 100% remote design sprint process.

A challenge to remote workshops is less focus and productivity from clients. But we have seen that when you have all people in their own space, people are more creative. Focus increases when people are in familiar spaces, and you can get more people to collaborate.

Remote workshops make it easy to create breakout rooms and team works are better quality. Setting up pairs, groups and one-on-one is much easier in a Teams call than in a single meeting room. Time zones are not as important and international members can be a part of the process.

Our favourite tool for workshopping digital products is FigJam. With FigJam, we can give everyone space to fill out ideas. We can edit each other’s notes, limits, and needs on the project, cast votes on different strategies, and have a little fun! 

Remote workshops can be just as fun and even more successful than offline versions. With the right moderation, we deliver more value beyond just the project itself! 

illustrated digram of a 5 day sprint

Our remote consultancy sprints 

Okay, we’ve told you about the design and remote parts, but how do you run a remote design sprint?  

Our senior UX designer with design sprint certifications has run various successful sprints. Using different tools and testing different methods, we have created our unique approach to remote design sprints. 

Getting your design sprint prepped 

We meet with you before we begin the sprint to understand your requirements. We can evaluate the size of the task and the scale of the sprint needed to complete the requested project. We collaborate to understand who is available from you; ideally, you will have at least 3 stakeholders. 1 is an industry expert, and at least 2 additional people will participate as testers later in the process.

Day One: Plan and research 

We first begin with collaborating with the client to ensure the guidelines, outcomes, and delivery are clear. We begin researching and preparing for the second day when we agree on outcomes and know what the week will look like.

We research your competitors to know what they do and how they look. Completing this helps us to understand your industry space and what users may be after. Next, we will focus on your users and audiences by reviewing any existing research and conducting our own research.

With the research done, we are able to create a problem statement. Problems statements are useful and simple insights that summarise the main problem a solution may face.

On day 1, we’ll have: 

  • A Problem Statement along with smaller problem statements. 
  • Agreed outputs and documents for the week. 
  • User Research. 
  • Competitor research documents and write-ups. 

 

This means we have a ton of information for both our team and yours at the start of day 2. 

Day Two: Workshopping and Definition 

On day 2 our design sprint facilitator runs the virtual workshop. With design sprint tools, we have all stakeholders in a virtual call to answer critical business questions. With the client, we validate ideas real time on the call. We put up virtual sticky notes and brainstorm potential solutions.

It can be a bit stressful, but fun games and creative activities help to make it a positive product process. We use the design sprint google activities "How Might We?" and "Crazy Eights" to encourage a more creative experience.

"How Might We" is an ad-libbing exercise, where the workshop talk together on how to fix problems. "Crazy Eights" is an eight-minute activity where each person draws a fix to a problem in a minute for 8 minutes. This means each member having 8 fixes for a problem and can talk through each fix.

We also build a user journey map, to help guide day 3. A user journey map is a diagram that shows the steps and actions a user must take to complete an activity. A good example of a user journey is a checkout process on a website.

Finally, we also complete a whiteboard challenge for the solution. A whiteboard challenge includes the client's goals and needs and lists the priorities. It also lists the blockers; the things that can or are already stopping the solution from doing what you want. Blockers can be physical (amount of staff available) or abstract (like culture or emotions).

We also use this day to work out the measurements of success (or KPIs) and how to reach them. By the close of play, we will have the: 

  • Reviewed and absorbed the information from day 1. 
  • Completed a whiteboard challenge
  • Created a User Journey Map to guide wireframing.
  • A whiteboard challenge of the goals, limitations, blockers, needs, priorities, and measurements of success. 

Day Three: Lo-fi Prototyping 

On Day 3 Clients can get on with their own work, and Growcreate does the design magic. GrowCreate uses its design skills to build lo-fi prototypes based on Tuesday's outcomes.

Lofi prototypes are a type of solution sketch. We design each screen of the solution using squares, circles and lines. We then connect each of these screens together, so the design is interactive. Each button or object you can play with and go from one screen to another.

Taking this approach means that the client and testers can play with the solution and make sure the feel is right. Minimal visuals or aesthetics keeps focus on the experience.

We have a catch-up call with the client to keep them involved and show them what we’ve been doing throughout the day. By the end of Wednesday, we will have: 

  • A working lo-fi prototype of the solution
  • Prototyped pathways to complete user flows 
  • A list of tests and challenges for day four

Day Four: Testing and Refining 

On this day, we move to prototype and test the solution. The clients must set aside time to create the wireframes and see if they align with their expectations and needs.  

We meet with the client and any additional testers to quickly explain the prototypes. Then, they can test the prototype in a condition that matches their expectations.  

We then ask everyone to complete some tests first. After that, we have them do a series of challenges and tasks. Sometimes, we ask people to record their experiences, take notes, or give interview feedback afterward.  

We meet with all the testers and discuss what we found and what to fix. We wind up with a list of things to do before the end of day 5. At the end of Day 4, we'll have the following outputs. 

  • Testing feedback and notes. 
  • Group feedback and notes
  • A synthesized action plan of refinement for improvement. 

Day Five: Prototype Build and Delivery 

The design sprint team are near the finish line, ready to deliver the final outputs. On Day 5 we continue to changes to the design based on day 4 to hand over a full lo-fi prototype.

We have a retrospective on key learnings from the research, present the designs, and discuss how to better support the client. Bigger projects would then move into an extra week of changes to the design. By the end of Day 5, we will have: 

  • A task list of next steps for the project 
  • A Sprint book, which conclude the work completed during the week. 

 

GrowCreate also has an internal retrospective. This is always a great opportunity to see how we can perform better in the future. We want to constantly improve our own service as well.

Summary

The week is complete and a lot of work has is over the line and a solution provided. This method of design sprint is intensive and leads to successful products. Problem-solving for the client even at high level keeps our designers speedy, efficient and innovative.

Adding additional sprints means we can solve any problem step by step and quickly. Using successive design for huge products and solutions also leads to large savings to businesses long-term.

Contact us if you're after quality solutions completed at pace and scale. We'd also recommend reviewing some of our case studies to see how rewarding design sprints are.