Design sprint for the next big pivot
Design sprints can work in many contexts such as redesigning a web experience to validating a range of solutions in defined problem areas. For our design sprint with Tamseng, the start-up behind a mobile app called Study Helper, we needed to further define the large problem area around studying to find where the next big product opportunities lie. It was also important that these opportunities lie in between what users want and what Tamseng needed to develop its business model.
To explore and find this sweet-spot, our goal was to build confidence around one or two directions that could be the next big direction for Tamseng (or at least get us closer to it) in a one-week design sprint.
A bit of background about the Study Helper app before we get into the design sprint principles and process. Study Helper works by cutting off your mobile device’s vital lifelines, data and notifications while you study with a timer function. Sounds like a horrible idea for most people, but for students in hyper-competitive regions in Asian countries such as Korea, China and India, it’s been an oasis for self-discipline. Over 700k students have been using it to help them focus, avoid distractions, and keep track of their studies.
Tamseng needed to figure out how they could scale from simple utility app to a service and platform with long term value.
As much as their app needs to help students avoid their phones while they study, the company still wanted to figure out ways for students engage with the app outside of study times in helpful ways. They’ve started to expand into new features such as social study groups and personal metrics — but they’ve been struggling to find the next big feature that will boost engagement amidst many copycat products and apps. Additionally, their investors have been asking the looming question familiar to many startups — “How are you guys going to monetize and build a sustainable business?”
Human-centered design for a better bet.
So the big idea for this next big feature (which your users will naturally love and which will make you tons of money) might just come to you as a stroke of genius in the shower…right??
Great ideas can indeed come from anywhere.
But how much value will it actually add for your users? That’s an assumption and a risk — even if the idea feels amazing and intuitive to you and your team.
It’s sort of like throwing darts. That great idea you had in the supermarket line could really hit bullseye in one shot. Or not. It might not have been the right solution or even the right problem (wrong dart-board). Why only give yourself one shot without practicing multiple times?
In order to get more shots at the bullseye, so to speak, we use a human-centered design process to prototype, test and explore ideas in front of real people. In our case with Tamseng, we were practicing a super-condensed version called the Design Sprint.
Each design sprint or prototyping cycle roughly consists of these stages:
Understand + Define → Sketch + Decide → Prototype + Prep → Test +Learn
Some lessons and principles emerged from our sprint with Tamseng — and we think they could also be useful for your next design sprint.
1. Take time to define the scope of the problem clearly.
The Tamseng team already had three different possible solutions/concepts as to what they thought could be the next big feature. One was around using pop star idols that teens and students love, and two others were around improving their ‘group study’ feature. They all sounded like good ideas, but we wanted to dig deeper and find out why and how they might engage users.
After talking about the background assumptions behind these concepts in terms of user needs and business goals, we asked them (nicely):
“Are you really sure?”
At first, they seemed pretty confident. As we dug deeper into their target customers’ needs, we weren’t really sure in what ways their existing ideas would effectively address them. They also weren’t sure if these concepts were truly the best possible options.
To figure this out, we went through some exercises in organizing everything we knew about our target user needs. These needs were clustered into key problem areas and then turned into “How might we…?” questions. These questions ultimately gave us specific focus and framing for the scope for our design challenge.
2. Explore, vote and review with your team in multiple cycles.
Once we had a bunch of concepts generated around the key problem areas we defined on Day 1, we started to vote and converge on some of them. We used blue dots for ideas that improve current features and red ones for ideas that were brand new features. This was helpful to the team in contextualizing where the current product offering lies and where other new concepts can lead us toward.
After voting, we reviewed ways to develop the concepts further and what things we’d need to consider. We then broke out of the group to work on them individually and then came back together again to explore, vote and review.
This is the bread-and-butter of the collaborative design process. During our sprint, we had dedicated days, and even hours, for generating ideas (diverging) and narrowing down/focusing to develop them (converging).
These cycles of divergence and convergence — of the group as well as concepts — helped create a highly productive and energetic rhythm for the project. These cycles also ultimately led to richer and more developed sets of solutions.
3. Sketch, design and prototype at the right fidelity to optimize learnings and progress.
The fidelity of our ideas progressed throughout the sprint. During our very first brainstorm around key problem areas, we used one idea per post-it. We then moved to half-sheets to have more room to think through moments in the experience and how they might look on a mobile interface. Only then did we move to another round where we created black and white wireframes in Sketch on our laptops. Between each round, we built in room for reviews with the entire team.
The most helpful part of this gradual increase in fidelity when developing ideas was that it helped move things with the entire team (many non-designers) at a comfortable pace with room for a lot of feedback and learnings during reviews.
If we had moved quickly to computer-generated UI designs early on in the process, it would have been easy for feedback to focus on the wrong details. Our goal was to find the right feature and big direction for Tamseng, so sketches allowed us to think big-picture. Additionally, when we put black and white wireframes in front of users, it focused the conversations around features and use-cases — rather than things like how much people love/hate a particular color/style or legibility of icons.
4. Be open to surprises and failures when testing with users.
Our first session on Thursday was with a recently turned college student which went pretty smoothly. As we walked through each concept, we were able to learn about her detailed study habits and how it related to some of the details in our concept wireframes.
At the end of all the interviews, we asked the participants to choose the top three concepts that they would find most useful as a user and reasons as to why.
In every user session we’ve ever done, there is always at least one thing that surprises us.
One of these surprises that quickly became apparent was around the idea around pop-star idols that everyone was excited about early on: it didn’t resonate across all our users. Ironically, another concept around social support that the team didn’t care much for resonated most positively across all five of our participants. We recruited across a range of different behavioral and demographic student types, so we knew that this concept might be the big pivotal feature we were looking for. Additionally, we were able to get feedback from users about their intent to pay for features around this concept and even how much.
After finishing all the interviews, we gathered the notes from each of the sessions and started to find patterns and common themes from the explanations people gave around each concept. Some of the insights pointed to a larger need, like how people managed their studying goals and schedules on a daily and weekly basis. Most importantly, we were able to synthesize the feedback into headlines that captured how this social support experience would be helpful to our users.
5. Empower non-designers on your team to contribute to the design.
When we were breaking off from the group to work on ideas individually, we always tried to divide the work among all the team members. One of the most important reasons we did this was that we just didn’t have a lot of time and needed all hands on deck! One of the members from Tamseng was a patent attorney and not a designer, but he was open to making wireframes. After a quick 5-minute tutorial, he was the first patent attorney we’ve ever met who learned to wireframe with Sketch! Consequently, he actually ended up producing a lot of wireframes which was really helpful in understanding details that we had not talked about. Though we didn’t use all the wireframes he worked on for the user sessions, it was great to have everyone feel a sense of ownership and be able to improve various important details of the concepts.
6. Always have a ‘nagging mom’ idea somewhere.
During one of our brainstorms, someone threw out an idea of a ‘nagging mom’ who would send push notifications to students to remind them to study. This got everyone laughing. But we also started to talk about how an authority figure could help motivate students, not only via nagging, but through regimented programs with strict rules and time schedules (like fitness trainers and army boot camp officers). After this discussion, a whole new series of ideas were generated by the team. The lesson from this is that funny and silly ideas are not only great in brightening the mood of the team — but can also build momentum toward better solutions.
These were 6 lessons and principles that we drew from our experience running design sprints with startups such as Tamseng.
What are some lessons from your design sprints?
How have you used design sprints to help your product or business leap into the next big phase?
——
Written by Junu Yang with lots of help from David Lee & Christina Tran.
A project collaboration by Daylight and Tamseng.
