We used a remote design sprint to kick off product development for a healthtech client’s new search catalog, which will allow researchers to find the best tools for their studies.
We were gearing up for 6+ months of product design and development with our client. Before touching code, we wanted to test the design of the new product’s onboarding and search filtering process. A Design Sprint fit our needs perfectly because it would allow us to ideate, prototype, and test the core area of the new product before investing resources in additional features.
This healthtech startup wants to give researchers and companies the ability to search their massive database and order reports of their information. The reports and search results will save customers hundreds of hours and thousands of dollars of their own time and budget.
Our client currently puts together the reports manually. They comb through the database and curate custom reports for each of their customers, but they plan to automate this process with their new product.
We wanted to create and test the platform’s design before spending time and money on development.
Some of the requirements for features (to consider either in this sprint or in future sprints) included:
The only problem? We would have loved to have our team of 7 members across different areas (design, project management, development, writing, etc) in the same place for all four days of a Design Sprint, with lots of coffee and sticky notes. But we were spread out across North and South America, and wouldn’t be able to get together for a whole week to sprint it out.
So we adapted the process and customized our own remote Design Sprint.
Our side of the team included a facilitator, two UX/UI designers, a project manager/writer, and a front/back end developer. On the client side, the founder/CEO and engineering lead participated in the entire sprint.
For those of us who hadn’t worked with this healthtech client before, this experience doubled as an intensive onboarding to the project.
Both for logistical reasons and attention spans (having a 6-hour call is very different from being in the same room with people for 6 hours), we divided the 4-day sprint into 6 shorter days.
We split the typical Monday of the Design Sprint 2.0 into 2 days, and then Tuesday’s art gallery/user flows/storyboard into 2 days as well. Prototyping and user testing days stayed as written, with just a short check-in call on prototyping days to let the designers work for the rest of the time.
Beyond adapting the schedule, we had to adapt our tools and our expectations for a remote setting.
The week before is key in any Design Sprint, but we found it especially important when we knew we wouldn’t be sitting in the same room as our team members. For example, it’s much harder to enforce the no technology rule when you can’t see whether someone’s checking their phone, and when you all have to be online during the calls anyway.
Instead, we tried to communicate suggestions for disconnecting ahead of time: turn off notifications, no email checking, phones off during the sprint calls.
We had to do things that you might not think about during an in-person sprint:
These are the tools we used throughout the sprint:
Our challenge was big and amorphous, and the day 1 exercises really helped us zoom in and define a specific goal to tackle during the sprint week. It forced us to limit the features that we would be able to touch on during the week.
Remote note: When you’re typing, it’s easier to write way more How Might We (HMW) questions and 2-year goals than in an in-person setting, where you’re scribbling on sticky notes. You might need more time for HMWs and 2-year goals to be able to review and cut out repetition. It’s way too easy to type a long, detailed 2-year goal, so make sure you narrow it down as much as possible to keep you focused during the Sprint.
Remote note: Screen sharing worked well for sharing lightning demos. Pasting screenshots directly onto the Miro board was also helpful for reference later in the Sprint.
We chose to stay in Zoom for the note taking, sketching, and crazy eights. Then, we took the 3-part concept sketching offline, but sent over time limits and instructions for each Sprinter to follow on their own.
Since we weren’t in the same room together (and we couldn’t look over everyone’s shoulders as they sketched), it was especially important to reiterate the time limit, and explain how the first three exercises help get you ready for concept sketching.
Remote note: Send a calendar invite for the roughly 45 minutes of offline time for sketching, so that Sprinters block it off in their calendar. We found that even though we weren’t sketching concepts during a call, it was hard to squeeze in time for sketching during day 2 if we didn’t plan for it.
Scheduling 4 hours of user interviews was a challenge when we were separated by 4 time zones. To add to the challenge, the type of user we were recruiting for interviews was a busy, expensive, high-level academic researcher, doctor or pharmaceutical researcher donating their time. We had to adjust based on their schedules.
Remote note: Since this first sprint, we’ve found it works better to split user interviews into 2 days to accommodate time zones and busy schedules.
Here’s what we learned from testing our prototype:
Although we significantly adapted the original GV Design Sprint format to work for our remote team, there were some unique benefits that might not come with a typical sprint.
While you don’t get the same exhilarating focus that comes with an all-day sprint in the same physical space, splitting up the days allowed our client to be available for 100% of the sprint activities. If we were doing 4 days of all-day intensives, they might not have been able to make it work around their busy schedules of investor meetings and other commitments.
Instead of a wall full of stickies, we still have the Miro board easily accessible, full of ideas and possibilities that we look back on constantly when working through a new design. Even months later, we still go back to the board to see the feedback and insights that came from that first Sprint.
For all but 2 members of our team, this was our first introduction to the product, and it was an amazing onboarding experience. We were able to get intimately familiar with the company and their product in a single week, instead of slowly getting used to it over weeks for research and meetings. It saved us time, and saved the client time trying to get us up to speed on their product.
Though skeptical at first, our healthtech client was convinced, and not only bought into the Design Sprint process, but suggested that we stay in the design phase and complete a few more Sprints before touching a line of code.
Since that first remote Design Sprint, we’ve completed a second remote Design Sprint to test a separate prototype for the platform’s secondary audience. We’ve carried out two iteration sprints to refine the prototypes based on feedback from those first user tests.
This week, the client is launching their MVP, and development has been a fairly straightforward process, thanks to all of the early testing we did during the Design Sprints.
Want to learn more about how we run remote design sprints at Indicius? Get in touch: firstname.lastname@example.org.
How we Used a Remote Design Sprint to Kick off Product Development for a Healthtech Startup was originally published in Indicius on Medium, where people are continuing the conversation by highlighting and responding to this story.