Validating Our Idea With Google Design Sprint 2.0
When you have an idea for an app but you are not sure how valid it is, how to estimate it quickly and with low costs?
We had an idea for an app, but weren’t sure how to approach it. We had looked at competitors and wanted to do it differently and better. The idea wasn’t something very revolutionary so we needed to be sure our soon-to-be users and service providers actually need it.
We had heard about Google Design Sprint and thought we should give it a go: validate our idea and come out with a prototype to test on real users before starting to create the real app.
This article is about how we did it — I suppose it goes a bit differently every time.
Google Design Sprint 2.0 (GDS)
GDS is a four day sprint with different roles, a lot of discussions and research. Every day has a specific focus and outcome.
It is crucial to include every role you have in your group. Every person with a different role and background has a distinctive perspective on how things should work. Roles can vary depending on who you are working with — product manager, product owner, developer, analyst, tester, designer, UX person, sales person, you name it — just one role you really can’t be without is someone who can make a clickable prototype that is used to present on the fourth day to real users.
Google Design Sprint is usually done from Monday to Thursday, but we needed to pause our everyday work and find a time that suited everyone, so we went with from Saturday to Tuesday.
Our team consisted of a product manager, developer, marketing person, two business managers and a designer.
First day — Saturday
Usually design sprint needs some preliminary analysis to figure out who are your personas (users who would use your app) and create some user flows, but we didn’t have time to do it beforehand. We had only done some discussions about our idea, talked about it with some of our acquaintances that worked in that field and thought about business model. Only thing we did for this design sprint was buying stickers with different colours. 👏
So we started off with gathering ideas. We mapped out all possible scenarios and user groups. We didn’t limit ourselves with anything, every idea was a possibility. We tried to think about every feature or flow our app should do. For advanced user or one time visitor, didn’t matter. For the scope of MVP or very far fetched and complicated features, didn’t matter. We just wanted to get it all out there — no limits.
To be sure we have thought about our idea from every angle, we had a MethodKit for Startups to help us. This kit is a set of cards that have keywords on and we tried to answer them or find a solution. This helped to pay attention to the possible danger zones, legal limitations or even how the marketing should be and how the user should even find us.
After all these discussions and research, everyone took some time to think it through and we started drawing our ideas as they should look in the app.
First day ended with a lot of drawings of different flows. Everyone tried to visualize how they saw the user flows or some specific features. However, it was not obligatory to draw all the possible views of the app, just the few one had in their mind.
Second day — Sunday
We had gathered again the next morning and began the day with drawing new ideas everyone had come up with while being away and fixed all the drawings to our glass wall. Usually the next step would be for everyone to look at other ideas and mark the most liked features with dots or stars, but we just looked at drawings to understand what others had thought of.
Next step was for us to start deciding what we should keep and what not. Especially for our prototype and for MVP. We started cutting parts of drawings out and gluing them together with duct tape to make user flows. This took most of the day, as new ideas came and erupted with ease. Nevertheless, at the end of the day we managed to agree on the main user flows.
After our flows were ready, we had to prepare texts that would be used in the prototype. This is always a challenge, especially as we decided to not use English and use our native Estonian language instead.
Second day resulted with one mayor flow ready for prototyping in the third day.
Third day — Monday
The activities of the third day didn’t insist on the whole group being together in one place. Everyone took some up tasks to deal with separately or in a small group. Like figuring out the payment system, making more market research or as for our designer, she started prototyping our user flows into Figma.
Everyone who had some friends or acquaintances who they could talk to and show our prototype, set up meetings for user testing.
We also needed to create a questionnaire for user testing, but we didn’t know how much of the prototype will be ready at the end of the day. Luckily Figma is a collaboration tool and we could see almost live how much is done from the shared link. But it was hard to create it and we pretty much abandoned it. Our designer finished at 8pm in the evening, we had enough views to show the next day.
Fourth day — Tuesday
In the morning we did some updates to prototype and after lunch everyone went their own way to their meetings they had set up the day before. We didn’t have a questionnaire to ask the same questions but everyone did it themselves.
At the end of the day we should have got together to discuss the feedback and make conclusions, but we did it the next day.
We are going forward with our idea, we got a lot of great feedback and knowledge about what users want. Next step is to put together the scope of MVP.
mAll-in-all we highly recommend this approach to validate and confirm whatever idea you have. This 4-day event not only puts your idea to the test, but also strengthens the relations between your teammates. It is guaranteed that you will learn something new about someone or something. Timewise it is definitely a sprint, as its name claims to be, but actionwise more of a marathon.
Edited by Mare Hunt, Marilin Moor & Kaur Esnar