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:
- An onboarding flow to gather information and educate new users about this relatively new field.
- Progressive search features to guide users through a recommended selection process.
- Different logins for multiple types of users, and team or organization logins in the future.
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.
Setting up and setting expectations
We had to do things that you might not think about during an in-person sprint:
- Set up virtual sticky notes and boards on Miro, our remote whiteboard of choice.
- Provide clear guidelines (and examples) of the 3-part concept creation. We needed to allow more time for the facilitator to upload concept sketches and edit notes so that they were readable. Tip: For readability, we recommend using a scanning app (such as the Dropbox app or GeniusScan) instead of just taking photos.
- Make sure you over-communicate details of the sprint to the client (or anyone who will be remote) during the preparation period of a remote sprint. You don’t want them to feel left out of the fun.
These are the tools we used throughout the sprint:
- Miro for our virtual workspace
- Zoom for video calls
- A dedicated #sprint channel on Slack for dedicated sprint conversations and communication during non-Zoom call hours
- The Time-Timer, a physical timer to keep us on schedule for all activities
- Invision for prototyping and user tests
- Pens and white legal paper for offline activities
During the sprint: A summary of our experience
Ideation and definition
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.
Offline concept creation
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.
Remote user testing: What we learned
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:
- Users like the straightforward onboarding/data collection process that we had designed. The lightning demos really helped us with this part — to visualize onboarding processes in other industries.
- We were focusing on the design and general flow of onboarding and search, but users got distracted by our lack of or placeholder copy in certain places throughout the prototype. It was a first-hand lesson on why content-led design is so important, especially when testing with real users.
- It became clear that we needed to account for a second Design Sprint in the future focused on the marketing website and clearly defining the value proposition.
- Users needed much more guidance and orientation than we expected around how to conceptualize the process of searching through the catalog. This product offers a new solution in the Healthtech space, and users aren’t familiar with it.
- Users gave us lots of constructive feedback about our “comparison” screen — once you’ve gone through the onboarding, selected the filters, and are comparing your results. We were later able to address this in an iteration sprint and users loved it.
Unexpected benefits of a remote Design Sprint
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.
Lasting sticky notes
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: email@example.com.