Design Sprints weren’t designed as a way to improve existing products, but to be the first week in the life of the product. And it is structured that way: expert interviews are relatively open-ended, sketches start from a blank slate, and there is no place for user feedback, analytics, or feature requests to feature. (Unless of course, you count on the experts to talk about these in the interviews.)
At Remake Labs, however, we are sometimes called upon to help bring an existing product to the next level. Perhaps a startup got funded based on initial traction but is struggling with retention. Or perhaps onboarding and educating users were done in a non-scalable, individualized way and now an automated and scalable in-app tutorial and onboarding solution must be put in place. More often than not – the initial version of the product was in the right neighborhood in terms of needs and functionality, but considerable user feedback and analytics produce new learnings that indicate that a significant redesign, refocusing, or re-alignment is necessary.
This is especially common when working with post-funding startups, or in collaboration with early-stage investors as we do. Startups rarely get funded pre-product, which means they usually have some product and some users, which they need to turn into a GREAT product with LOTS of happy users to justify the next round. The numbers don’t lie: to show continuous Week over Week growth, you need retention. To show retention, you need users to want to use the product.
The process of elevating an existing product to the next level is complex, challenging, and depends on the successful melding together multiple forms of expertise, and multiple sources of information. In short – it seems perfect for a Design Sprint-type intensive workshop. Just perhaps not exactly the classic format.
(I should mention here that if there is a very clear central challenge for the re-design, such as in many of the cases described in the Sprint book – a classic Sprint could be perfect. In many cases, however, the redesign challenge is broader than that.)
Here’s how we adapted the Sprint to make it an Elevation Sprint:
1. A Standard Design Sprint, an Iteration Sprint, or an Elevation Sprint?
Even for existing products, we sometimes do a standard Design Sprint. This happens when either the challenge is very clear and distinct from the rest of the product, or when the product needs such a deep refactoring, that the existing flows are irrelevant.
Another option to consider is an Iteration Sprint, first proposed by AJ&Smart in Berlin and widely adopted. This is a 4-day sprint that comes right after a normal sprint and focuses on iterating on a prototype based on the feedback from the first sprint, then re-testing with users. We like the Iteration Sprint model because it works beautifully right after a first Design Sprint, where the feedback and lessons from the first sprint are still fresh and clear in everyone’s mind.
An Elevation Sprint is different: it’s meant for products that have been out there for a while, been used by real users and produced various forms of real feedback in significant quantity, and do not require a significant pivot or complete rethinking. For those cases, a much more robust analysis has to take place.
2. Collect and Analyze Usage Data
If the goal is to produce a significant upgrade of the product design, then the weeks before the Elevation Sprint are critical. As soon as the Elevation Sprint is agreed on, we like to install and start collecting data in multiple forms, including Quantitative Analytics (such as Mixpanel and Google Analytics), and Qualitative Analytics (such as FullStory, and UXCam). We then assign a UX Researcher the task of analyzing this behavioral data and compile significant notes and insights. We use the tools to identify: Drop-off points, points of frustration, points of confusion, as well as low engagements and conversions across the board. We especially pay attention to patterns, to identify the most commonly recurring issues.
3. Conduct User Interviews
Before the Elevation Sprint, we like to conduct at least 10 interviews with existing users about their experience with the existing product. We call this our 10-in-2. If there is more than 1 constituency, we may schedule 2 sets of 10, one with each constituency. Just like with the analytics efforts – we compile this into detailed notes and pay especially close attention to recurring themes.
4. Go Over Feature Requests
Companies with real products often have a support portal like Zendesk, a chat support tool like Intercom or Tidio, a support inbox, or a feature request forum. Our User Researchers will go through these resources as well, trying to extract patterns, and consolidate with the other notes taken. Individual feature requests might not mean too much, but recurring ones do, especially when viewed in concert with user interviews and behavioral analytics.
5. Convert All Feedback to HMWs
Finally – we take all the notes we collected from the previous steps, and convert them to the same kind of HMWs we use during the normal sprint’s expert interviews. Unlike in the Expert Interviews, though, we include the source.
So for instance, we might write:
HMW
Avoid people getting frustrated until they find where to change their privacy settings?
Source: FullStory Recurring Issue
For an in-person sprint, we actually write these outs on Post-It notes! In a remote session, we enter it into our white-boarding tool, Miro.
6. Bring the Pre-written HMW Stack Into the Sprint
On Monday, we start the Elevation Sprint in the same way as a normal sprint — with expert interviews, and with the whole team writing “How Might We”s. This is important so that the sprint team feels like they have a chance to have their say and inject their priorities. It also gets them used to reading How Might We notes.
Once all the internal experts have been interviewed and the notes are sorted on the wall, we introduce the pre-prepared stack of HMWs. We like to have the sprint team members fully absorbing these HMWs, and this is how we do it: We do several rounds around the table and give each team member 5 HMWs, which they must read out loud, and then hang up alongside the Expert Interviews HMWs.
We then do the standard consolidation and sorting exercise and vote on all the HMWs, pre-written and interview-generated ones, side by side.
7. Lightning Demos: Assign Someone to Present Current Product
On Tuesday, we start as usual with the Lightning Demos. Except that in an Elevation Sprint, we make sure to start with a demo of the relevant area of the existing product, to keep it fresh in everyone’s mind. I usually assign giving this the demo to the person who knows the existing product best. This serves as a very useful contrast when we look at the other demos, helping us to identify the gaps more clearly.
8. Storyboarding & Prototype: Use Existing Screens as Needed.
One benefit of an Elevation Sprint is that you can use the framework of the existing product to stitch together the prototype. Therefore, to the extent that they are good enough to be used — we bring screenshots from the actual product as a way to enhance the user test. This can often result in prototypes that are richer and feel more realistic.
9. User Testing: Bring a Couple of Existing Users
Even when testing a change that is mostly focused on onboarding new users, we think it’s best to bring in a couple of real existing users to the user test, to get the perspectives of those who already know and like the product. This is in line with our general policy of seeking edge cases. So while the focus is usually on new users, 1 or 2 existing ones will generate different insights!
—
We hope you found this post useful! We’re often get asked whether to run a Design Sprint on an existing product that needs to level up. We say yes!
But make use of smart upfront research to make the most out of your time together.
