We tried a 3-hour remote design sprint
And this is what we learnt from it
One balmy Friday afternoon in May, the design team at LazyPay decided to sit down and try a quick-and-dirty, remote design sprint.
A remote design sprint, you ask? What’s that?
Well, a usual design sprint is a 5-day process where the team gets together to validate ideas, solve problems, build prototypes, and test it out with users.
Sprints are well-suited for ideating on new products, or for tackling open-ended problem statements where there’s a lot of room for exploration.
Inspired by Shopify’s 4-hour design sprint, and short on time ourselves, we decided to try out the exercise in 3 hours, with one small stipulation — we do it all remotely.
Why 3 hours? Well, we didn’t want to keep anyone past 7pm on a Friday (just when you’re getting into the TGIF mood🍹).
The objective
While designing a new financial product for our users, we had found ourselves stuck in a rut in the solution space. That’s why this sprint was set up — to ideate and explore out-of-the-box ideas with the team. Essentially, we wanted to:
- Collectively deep dive into the problem space
- Generate a wide variety of ideas
- Gather feedback from the group, and eventually vote on the ideas that made the most sense
Our platform of choice for remote collaboration: FigJam.
Ready, set.. sprint!
Context setting (30 mins)
Since all of us were from the same team, we skipped the intros and dived into the problem space.
By the end of the 30-minute slot, we ended up asking (and answering) a lot of questions. After sufficient discussion, we make sure everyone understood what they had to do during the next part of the sprint.
Diverge: Individual sketching (1 hour)
Video off, sketching on! We muted our mics and started to put down our ideas into wireframes. Some of us felt adventurous and even snapped a quick photo of ourselves in action.
A few chose paper, while others felt more comfortable drawing on Figma. Whatever the medium, we wanted flows and screens that could express an idea even if they weren’t necessarily pretty or fully formed.
At first, it was a little hard for some of us to get into the groove, but eventually everyone was ready with their sketches by the end of the hour.
Converge: Gathering feedback (1 hour)
This was where each individual presented their ideas and gathered feedback from the group. Everyone brought their sketches onto FigJam, and walked us through their pitch.
We were surprised at the range of proposals being presented. Most were grounded and practical, but it was also fun to get a few out-of-the-box ideas — one of them even sounded like something out of a dare-devil reality show.
Voting (15 mins)
Finally, it was time to vote. We listed down the major themes and concepts from each idea presented, and every member got one vote.
This part of the exercise helped us narrow it down to a few actionable items that could be taken forward by the designer in charge.
Results
Since we were short on time, we left out the prototyping and testing phases of the design sprint. Instead, we left the meeting with a solid list of ideas that could be further iterated on, translated into a functioning prototype, and then presented to other stakeholders for review.
We also found that doing it remotely didn’t pose that much of a problem — we were able to collaborate smoothly for the sprint. The only thing that was difficult to recreate was the practice of group sketching/white-boarding, hence we left that exercise out.
What we learnt
While doing this experiment, we learnt a lot on how we could further improve the process and make the 3-hour sprint much more efficient and productive.
📝 Set clear expectations
When we started out, we asked everyone to come back with wireframes and flows to express their idea. Later, we realised some of us felt a bit intimidated by the idea of creating proper flows (especially the non-designers) and even conscious of whether our wireframes looked good enough.
Going forward, we plan to ask participants to express ideas in any form they’re comfortable with, so they can think in all directions without feeling judged.
🌳 Start small, then scale up
Our first try was with a closed group, and only involved some members of the design team, since we were just experimenting.
Next time, we’ll involve people from different functions in the organisation, like product managers, developers, marketing folks, and business teams.
⭕️ Limit the scope of the problem
Even after limiting the scope to two defined problem statements, participants still felt the scope was too wide to compress into a 1 hour sketching window.
In future, we’ll try to narrow down the scope even further, and add more specific constraints to the problem statement.
Thanks for reading! Follow us for more sneak peeks into how our team works, and the way we design — LazyPay Design Team
