Last month, we had our first Limesprint. This guest post from our Product Development team shows you what that process looks like.
Our mission is simple: We want to measurably improve health, well-being and performance in the world. And our product team lives by that idea. We don’t simply design an engaging product — we engage throughout the design process.
The typical model for software and product development looks something like this: Teams start with an idea, build it, launch it and measure its impact in the wild. But this process doesn’t always add value or delight users.
Enter Limesprints (a custom variation of the “design sprint”): an intense five-day exercise that attempts to solve the problems of traditional software development. We take a shortcut straight from ideas to testing so we build the best product possible.
We’re really interested in how people find each other and interact on a social level on our platform. So the goal for this Limesprint was to generate ideas and hypotheses on just that.
So how do we run a Limesprint?
The core of every design sprint is about asking questions and bringing in the right people. This means looping in teammates from marketing, sales, account management, software development, design and more. For this Limesprint, we packed our war room with employees who had expertise in social engagement.
Here’s our process in 5 steps
Leveraging a range of knowledge is the foundation for a good sprint. The members of the sprint team share their expertise in directed discussions and brainstorming. A series of rapid sketching and idea generation exercises fill our war room with post-it notes and hand-drawn storyboards.
After the team reaches a collective understanding of the problem, individuals think through potential solutions using rapid sketching and storyboarding. This gets us out of “design by committee” mode. Everyone contributes and compares original ideas.
The team comes back together to vote on ideas through a heat map: Everyone places dots on the parts of ideas they feel address the problem, giving the design team an informative heat map of the best potential solutions. The heat map informs what the team will prototype and test. The team evaluates ideas against the original “how might we” question. The ideas in this Limesprint answered questions around how people socially engaged on our platform.
Once the design team decides which user flows to test, we build prototypes. The building process is hectic, but our results rely on having something to show users at the end of the sprint.
Finally, we test our built user flows with real users. A design sprint researcher guides users through a series of tasks to assess the validity of our ideas. The rest of the team watches remotely in another room and takes detailed notes. After the last user completes the tasks, the design sprint team identifies trends and patterns. We make sure everyone agrees with the observations so our results remain accurate and reach a collective understand quickly.
Ultimately, each sprint has a different outcome and takeaways. The variability in outcomes is the entire point of a design sprint. It’s not only okay to have varied outcomes — it’s expected.
At the end of a design sprint, we validate (or invalidate) our original hypothesis, and we form new ones. We establish a place for peers to collaborate in the design process and minimize waste by removing over-documentation and including the right people. Above all, we learn something valuable.