What is the Design Sprint 2.0
The Design Sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. The Design Sprint works for rapidly solving significant challenges, creating new products, or improving existing ones. The process was developed by Jake Knapp, John Zeratsky, and Braden Kowitz at Google Ventures.
Design Sprint 2.0 is an updated 4-day process, developed at AJ&Smart. They took the original Design Sprint principles and optimised the original process so that instead of 5 days, it takes 4.
What is the problem that our product is going to solve?
We did some user research and competitive analysis to understand the real users of Duolingo and their needs and their problems. Also, to understand who the competitors of Duolingo are.
Our main questions?
1. What is the opinion of the users who are using the app daily?
One of the users had an interesting opinion, he said: Duolingo is useful in the sense that it does an adequate job of teaching you the "how's" of a language, but not the "why's."
2. What about users who live in places where their access to the internet and payment options are limited?
In countries like Iran, Sudan, Cuba, and Syria, internet access is unreliable, making the ability to use the app offline important. International sanctions on these countries make it difficult or impossible for citizens to use credit cards, Paypal, or online banking to purchase from an app store.
3. How might we make it possible for these users to access premium features in a way that positively contributes to the usability of the app?
Together with three friends of mine who live in Iran, I decided to redesign Duolingo to meet these needs. Our goal is to create the possibility for users who lack consistent internet access and international payment options to use the premium account functions in a way that contributes to overall usability. They can download the courses when they have access to the internet and study their chosen language when- and wherever they want.
We decided to run a Design Sprint 2.0 for our project and let it be tested by real users. We had to run the design sprint remotely.
Day 1 — Define the challenge and produce solutions:
The goal of the first day is to specify exactly what challenges we're facing and produce several solutions.
Expert interviews and HMW questions
We started with the expert interviews. Since we are users of the solution that we were going to design, we decided to focus on our own needs and problems. As experts, people who are in the field and understand the problem, we invited our 2 team members. We used the Nielsen Norman Group guide to conduct the interviews in the right way. While the experts talked, the other member of the team recorded the "How Might We…" (HMW) Questions. The goal of this exercise is to write down all the insights and problems that experts share. After the categorisation and voting, we narrowed down to 7 most essential HMW questions. Among them:
HMW encourage our users to teach each other?
HMW create a trustworthy space for users who are learning from other users?
HMW encourage feedback sharing culture?
HMW create a feature in which people can share their language skills?
HMW control the answers?
HMW make it clear for the users that they can share their language skills not only with the chat feature in the app?
HMW keep users curious about using the app for the next two years?
Long-term goal
After brainstorming and voting, The 2-year goal we specified as:
Redesign Duolingo as a free language learning web app. The app is free-resource, and we want to create a possibility for all users to learn from each other and share their language skills and stay curious about the conversation that they have with each other. The key idea is about learning from each other.
To measure the goal:
Create a feature that gives users the possibility to share their questions and receive correct and trustworthy answers.This feature we are calling "Question Hub." In this feature, any user with advanced language skills, as evidenced by their Duolingo profile, can become a teacher. By answering five questions per week from other users in less than 24 hours, the "teacher" will be able to use a premium account for free.
Sprint questions
Sprint questions are like HMW questions, but they are more specific and designed to help identify the obstacles that might prevent us from reaching our 2-year goal.
Our Sprint questions were:
1. Can we remove the emotional blockers of the users to trust the answers that they are receiving?
2. Can we make the feedback sharing simpler so that users can share it on the spot?
3. Can we develop an interaction model that would allow gathering feedback from 10% of the team members(group of students who are studying the same language) daily?
4. How can we convince users to get involved in the process, answering the other user's questions? What is the benefit of spending time and energy to solve other users problems?
Lightning Demos
We did the Lightning Demos. The goal of this exercise is to generate a pool of ideas that the team will later use to produce their solutions. Since we all know that almost any new idea is just a new combination of a few existing ideas.
Map
We drew the map to help us visualise the flow of the user and have a full picture of how they interact. We split it into several essential steps: having an interaction, deciding to share the feedback (where the user solves a significant psychological barrier), preparing and sharing (or receiving the feedback).
As the target area, we selected the feedback sharing process itself so that we'll focus on producing the tool during the following days. We assumed that the cultural and psychological barriers are already solved. Otherwise, we'd need a whole new Sprint to address it.
4-part Sketching
The first day ends with generating the solutions. It's done in 4 steps. The first three of them — Note-taking, Doodling, and Crazy 8s — are warm-up exercises; they are designed to flex the visual communication muscles of the team. The Sketching was done successful, and the team members came up with decent concepts. Each of the concepts consisted of the 3 main steps, had a catchy title and self-explanatory text. It's essential to keep the concepts anonymous so that the team members are not biased the next day when they vote.
Day 2 — Vote for the solutions and create a storyboard
The goal of the second day is to select the solution the team will test and fill in all the necessary details with the Storyboard.
Solution presentation
We started with the Art Gallery and Heat Map Voting. Each team member received red dots, walked around the room, and placed the dots next to the ideas or features (s)he liked the most. In the end, we had many red areas.
Next, the Facilitator presented the concept to the whole team. The idea is that it is not the author of the concept who presents the idea, to make the process anonymous, and also to make sure that all the team members understood the concept.
A good approach is at the end of each concept presentation to ask, "Did anyone place a dot at this concept for an idea or feature I didn't mention?". Indeed, a few times, it appeared that the team members noticed some ideas that the Facilitator missed. Such an approach brings all the team members on the same page.
Voting
During the Straw Poll voting (synchronous voting) the team members placed their bets for the best concept. All 4 team members placed bets on a single concept. The decider later picked this concept, as well.
The key idea of this simple and well-thought concept was: Users who have chosen to use the free version of the app can work as teachers, which means they will answer 5 questions of the other users in the Question Hub feature. Prompted by notifications, they have to answer the questions in less than 24 hours Also, the app would suggest each user share the feedback and answers that they received with a group member( Users who are studying the same language and are on the same level or higher), so they can evaluate the answers and discuss it.
Final Vote
User Test Flow
During the User Test Flow exercise, each team member wrote the 6 steps that the app users need to perform from the entry point until reaching their goal of sharing the feedback. We presented and voted for the best User Test Flow. This step is designed to make the next step more straightforward and faster.
Storyboard
The most important task of the day was to fill in the Storyboard. The idea of the Storyboard is to sketch out an entire journey through our product with enough detail, so everybody is aligned on what goes into prototype. After the Storyboard, there should be no open questions about the concept, so that during the next day, the team can focus on prototyping, and not discussing again. No brand new ideas should be added at this point (which is hard). At the same time, we should avoid unnecessary efforts and re-use as many materials as possible.
We placed the user steps into the 7 cells and started drawing the concept screens. We decided not to re-use our concepts but to re-draw them to update a few steps. We spent 3 hours on the Storyboard, brainstormed different solutions and approaches. So, in the end, designed 4 screens (instead of the expected 7). However, some screens were straightforward.
Day 3 — Prototype
The goal of this day is to build a prototype that can validate our solution.
Paper prototype
The paper prototype is the most straightforward possible approach to test almost any app. We split the work between all the team members, and within 1 hour, the paper prototype was ready. We tested it 2 times between the design sprint team members. This quick testing gave a feeling of confidence before the next day.
While testing, we recorded a list of improvements for the paper prototype and places where the users were confused. We put these improvements on sticky notes and placed them on the respective parts of the Storyboard. After the dot voting round, we selected the 4 most important ones and improved the Storyboard based on the suggestions.
Digital prototype
Since we already had the detailed Storyboard, the paper prototype, and 3 designers in the team, it took us only about 1 hour to create a digital prototype in InVision, working simultaneously.
Recruit and schedule user tests
During the day, one of our designers was working on scheduling the user interviews, preparing the interview script. We decided to invite 5 users to participate in remote user testing via Skype.
Clickable prototypes:
Day 4 — Test the prototype with users
The goal of the 4th day is to conduct user testing of the prototype, collect feedback, and decide on the next steps for the product.
Interviews
We arrived at 9 AM to make the final tests and preparation before the interviews. We drew a big table on the whiteboard with the name of all interviewers and a list of features that we wanted to receive the feedback. The first interview was scheduled at 11 AM. Afterward, we took 2 hours for fixes/improvements in case of any issues with our approach or the prototype.
The first interview indeed helped us understand and get used to the process better and set up proper video recording. As for the interview process itself, we tweaked it a bit to our needs. Instead of the notetaker taking notes immediately and recording the pros/cons during the interview, the whole team took notes and recorded essential points. Then after the interview, we collected our notes together to create the combined stickers of pros and cons. On the orange stickers, we wrote points to improve; on the green, what users liked; on the purple, general comments and insights. It gave the team the ability to make sure all the ideas were mentioned and that the team is on the same page.
Day 5 — After the Design Sprint
The next week after the Design Sprint, we grouped the user feedback into categories/standard features. Then we took the dots and voted for the most significant changes to implement.
We ended up with 4 features to implement. We drew an Impact/Effort scale and placed the cards on the scale depending on how hard they are to implement and how much impact they bring to the app.
These are the features that we'll focus on in the next update for this app. We decided to place this app on hold and validate several more ideas, then get back to the concept in a few months before moving on to development.