Design Sprints for Remote Teams
How to quickly validate business ideas in a remote environment.
If you are a product designer you are probably familiar and maybe have used design sprints in the past. For those who are not familiar with design sprints, it is a process developed by the design team at Google Ventures to quickly design and validate ideas, products, and features using design thinking, collaborative activities, and user testing prototypes.
Design sprints work best when working on-site with your team and stakeholders, so that you are in clear control of the agenda, pacing, and focus. That doesn’t mean that they can‘t be done remotely it just means that it comes with constraints.
I believe the core benefits of design sprints are not in the details of its implementation but rather in its structured approach to problem definition, design, and validation. Those benefits can be achieved in a remote setting — it just requires an understanding of the restrictions and some good planning.
We now have a range of tools to make collaboration across remote teams easier and more enjoyable, so let’s take advantage of them!
Below I’ll describe the different stages of my remote design sprints process. The duration for each stage will depend on the needs of the project and your resources. You shouldn’t take this as a strict recipe, but rather as flexible set of recommendations and practices that you can adapt to your needs.
This step is all about understanding the context of the project and interpreting its requirements. The goal is to uncover key information and frame the right problem — and solution.
Ask a lot of open-ended questions about the goals of the project, the user problem, the assumptions, the direct and indirect competitors, and the market and its challenges. As the facilitator, it’s important to listen and encourage open-ended discussion. Use the five whys technique to identify the root cause of an assumption or problem.
Mural is a great tool that work as a digital whiteboard. You can use it to run exercises like card-sorting or mapping the user journey, which will help deliver great value and insights at this stage.
Now that you have a greater understanding of the project and its needs, use both group and individual sketching sessions to come up with as many different approaches as possible. You are in “create” mode, not in “edit” mode, so don’t kill any ideas here. Focus on low fidelity designs, wireframes, wire-flows, and flowcharts.
💬 Present and Discuss
Now it’s time to present the design work. Justify the designs based on the insights you learn in “Understand.” Ask questions about and be open to feedback. If none of the designs work as intended, go back to “Design”.
Now that you have mapped the scope of the prototype you want to test, you need to build it. Tools like Invision, Marvel, Keynote, or even HTML/CSS can help you with this. Since this is a rather technical stage, it can be done async and without involving the client.
📝 Test & Learn
By now you should have a digital prototype ready to be tested, both internally with the team and with a selected group of users (ideally those being existing or potential customers).
For remote user testing, clearly define the expectations of the tests and the intended tasks for the user to perform. Invite them to “think out-loud” at every step of the test. There are plenty of tools that allows you to record your screen and your mic — I’d recommend QuickTime. If you don’t have a selected group of users to test the prototype with, you can use tools like usertesting.com.
Study the results of your test, do a synthesis of all the data you collected, and try to document both qualitative and quantitative results. Identify common patterns and shared concerns.
📆 Define Next Steps
Your sprint is now almost over. You have identified a problem, crafted a solution, and tested it with users. You can now use those insights to define your next steps. This could be another sprint, tackling another aspect of the product or going forward with a more high-fidelity version of this prototype. Whatever the next step is, the client and you should be confident that the solution you arrived at has saved time and resources while delivering important insights about the nature of the users, the problem, and the market.
Now that you are familiar with the overall process of a remote design sprint let’s talk about particular tips and best practices to make sure they go as smooth as possible.
Start by building trust
It’s important to create an atmosphere where everyone feels comfortable sharing ideas and collaborating, without being defensive about their own ideas.
I would also recommend working to develop trust between you and the stakeholders before you start the design sprint. A simple and straightforward way to build trust is by delivering value to the client as early as possible.
Set clear expectations
Design sprint are usually a new concept for clients, so it’s your responsibility to teach them about the process, roles, expectations, and deliverables. You will be the one leading the sprint, moving through the agenda, and keeping the conversation focused and productive.
You should share a digital copy of the design sprint agenda with them with clear instructions and tips for each stage.
Do your homework
Proper research is key. The team needs data and information to understand the scope of the problem they’re trying to solve. The more research you do prior to a design sprint, the more prepared you are going to be.
Embrace the asynchronous
There are activities that don’t require all the team and stakeholders to be present and that can be done async — research being the most obvious one.
As we saw above during the “Design” phase, you can run both group and individual sketching sessions, the latter being async-friendly. When discussing design, you can also do group and individual critiques. Offering individual feedback will yield a range of ideas, since people won’t be pressured to conform to groupthink and can be also be done asynchronous.
Be conscious of time zones
A remote team doesn’t have to be in different timezones but they usually are. The more time zones you have to plan around, the harder it will get to find a schedule that works for everybody. Be aware of your team’s situation and needs and plan accordingly. WorldTimeBuddy is a simple yet useful tool to find and schedule meetings when working in different timezones.
I hope this will help you run more effective remote design sprints. I’m currently working on documenting my process, including instructions, best practices and tips, in a Trello board. If you would want to get notified when I launch it be sure to follow me on Medium or Twitter.
If you have any other tips or ideas on how to improve remote design sprints, lets hear it in the comments.