15 July 2019Comments are off for this post.

Client’s story: How we adapted the Design Sprint process to create meaningful EdTech

In our previous articles, we introduced you to the Design Sprint concept and explained all of the phases of this process. Today, we would like to share with you something unique - how the Design Sprint process at Setapp looks like from our client's perspective. Milena Piasecka, EdTech Product Manager at Learn Teach Explore, describes how important the Design Sprint was to create their great EdTech app - Shapes 3D Geometry. 

This article was originally posted on medium.com by Milena Piasecka


When the objective is to create meaningful Educational Technology, it takes two to tango: Educators and technology experts. EdTech products have the power to support teachers in explaining complex issues and shaping students' minds  - providing that they use the right technology and good teaching methods to solve real educational problems.

Shapes 3D Geometry is a series of applications for K-12 classrooms that:

  1. Inspire students to investigate and understand solids on their own and
  2. Help teachers explain abstract 3D geometric problems by creating exciting lessons.

Our main goal is to create 'AHA' moments that make math lessons meaningful and engaging. With Shapes, students develop important skills like critical thinking and creativity while exploring 3D geometric problems. We also help teachers create the 'WOW' effect when students discover solids using 3D visualization and Augmented Reality.

Shapes 3D Geometry apps help students:


Co-creation with teachers

The main goal of the sprint was to design a solution that helps students understand abstract 3D geometric problems. The solution could be an app or a series of apps used by students in K12 classrooms, or at home. We had already gained positive feedback from teachers using our first app called Shapes 3D Geometry Learning. It does a pretty good job when it comes to teaching elementary concepts such as nets and properties of 3D shapes. Based on the feedback from teachers and our own passion for math, we then wanted to create a tool that would support the understanding of spatial geometry from the very first moments it is introduced at school until EdTech is no longer needed to tackle abstract geometric problems.

The main challenge, however, was to fully engage teachers in the co-creation process, meaning that the teachers would not only have to explain the problems students have with 3D geometry, but also to design a solution with a team of technology experts and product designers, as well as giving meaningful feedback on the early prototypes. As the main goal was to design a solution for a real problem that exists in math classrooms, having a teacher on board was essential.

We didn't have a teacher expert in our main design team, so we invited Olimpia Dębicka who we later called our "combo" educator, as she teaches maths, physics, and computer science at elementary and middle schools. She also gives private tuition for high school math students. Therefore we knew that, if there were any misconceptions in the understanding of 3D geometry ,  Olimpia would know this and would be able to tackle it in the most creative and multidisciplinary way. She was our math mentor during the design sprint.

Apart from Olimpia, the design sprint team also included:

  • Ten more math teachers from Elementary, Middle and High schools that provided crucial input to the sprint and its outcome.
  • The whole Learn | Teach | Explore team: Marcin (Marketing), Ann (Administration), Mike (Technology R&D) and myself (Product Management).
  • Two experts from Setapp - our technology partner: Janusz (Development) and Rafał (Design)

The composition of the sprint team was intended to focus the whole process on the right problem to solve. Meaningful involvement of teachers is the most difficult part of both a design sprint and the co-creation process needed to develop great EdTech products.

Organization and adapting the sprint process

Another challenge was having everybody in the same place for five days in a row. I wanted to follow the process of the classic Design Sprint by GV. It turned out, however, to be impossible as teachers are very busy people (especially at the end of a semester). Therefore we worked only managed come together in the same place for the first three days, to keep the design process short and effective.

design sprint

A general overview of Design Sprint Process. Picture source: https://www.charitydigitalnews.co.uk/wp-content/uploads/2017/08/Google-Sprint.jpg


For the same reason, we decided to keep the prototyping in-house. We have the right competencies and technology to develop quick solutions for educational problems, so it proved to be the most efficient way.

I had to carry out almost all the interviews with the teachers either before or after the sprint, as it was impossible to gather all the teachers in the same place on the same day. However, It didn't influence the total time spent on sprint design (in hours) and the results from the interviews very much followed the traditional process. It was the only way to go.

The Sprint phases

Day 1

Day one was all about the interviews with teachers and choosing the right problem to solve.

We knew from many earlier discussions with math teachers that students struggle with different abstract issues in 3D Geometry. I wanted to approach these problems with a better understanding of:

  • The difficulties that students have when learning 3D geometry and
  • teachers' difficulties when explaining 3D geometry in a classroom.

As it was impossible to schedule all the interviews with teachers for the same day (teachers have very tight timetables), I started with my own investigation and scheduled meetings with the math teachers that I recorded for the benefit of the design sprint team.

We started day 1 with the statement of the main problem area and goal of the sprint. Then we analyzed the interviews. After each one, we discussed what we had discovered. We also had an online meeting with a math teacher so that the whole team could watch and ask questions.

Then we summarized all we had learned from the math teachers by listing and grouping all the major problems with learning & teaching spatial geometry in K12 classrooms. In the end, it was obvious that the main problem was limited spatial reasoning and the inability to draw 3D shapes in 2D (on paper or board). It poses difficulties in understanding many geometric tasks and the nature of solids.


Day 2

The second day was to be the most crucial day of the whole sprint when we were supposed to state the main target of the sprint.

We reviewed the current approach to teaching 3D geometry in schools: the chronology, methods, and tools for subsequent lessons. Olimpia guided us through the challenges of the 3D geometry curriculum from K1 to K12.


We researched and grouped the major challenges of 3D geometry education in schools. Then we summarised our observations by stating the "How might we…" questions. Among them were a few candidates to become the single and most relevant sprint challenge, but unfortunately, we failed to choose one that day (we were just too tired and we ran out of time). This remained along with the big task which we agreed to approach with fresh minds the next day.

Day 3

The main goal of the day was to choose the sprint target and design the solution that would answer the big "How might we…" question in the most effective way.

We knew that whatever we created that day - it had to be game-changing and meaningful, but at the same time intuitive and easy to use in a classroom. Everybody needed to stay focused and open-minded. That's why Olimpia organized creative geometry activities that required us to build and explore 3D shapes.

Everybody had some time to rethink the "How might we…" questions stated the previous day. We approached them with new energy and agreed on the one big challenge to work on: "How might we help students understand and explore 3D shapes by drawing the important elements like diagonals or cross-sections inside them?".

Then we researched the risks and opportunities to be met when designing solutions in terms of competition, classroom & technology limitations, pedagogy models, etc. This served as an inspiration for the creative phase in which each of the team members sketched their rough ideas.

We used different techniques like 'Crazy 8s' or 3D modeling with different materials and tools brought by Olimpia - our 'combo' math teacher - just to exercise our brain cells and become even more aware of the challenges students meet in math classrooms.


It was the most creative day of the sprint. Together we sketched dozens of possible solutions turning them from ideas to the complete inspired design we all agreed should be turned into a prototype. We chose the best idea for prototyping. This day was a success.

Day 4

Now we needed a prototype to validate our design. Mike, our CTO, prepared the prototype according to the storyboard we had sketched the previous day and his own experience with Shapes 3D Geometry Learning our first app from the Shapes series. He was able to make a fully interactive prototype based on the first Shapes app that was made with Unity. The ability to use the same models of 3D Shapes gave us an advantage in the prototyping and validation phase, where teachers were able to use it in a way that was very similar to the target user experience. Mike's ability to quickly adjust the prototype helped us to iterate quickly when the teachers gave their feedback on its basic features: drawing lines, 2D figures and cross-sections in various solids.

Day 5–8

We wanted to confront the designed solution with the needs of teachers to create real value for math classrooms. The prototype was too rough to be used with students at school, so we relied mostly on the opinions of the math teachers, who were our experts in this co-creation process. We also validated the prototype with a few youngsters from the 5th and 8th grades during private lessons with the tutor - Olimpia, our teacher-mentor. We wondered: will the prototype of the new Shapes app solve their problems?

The interviews were carried out during the following few days, and recorded in the same way as before starting the sprint. Once again, the teachers' timetables made it impossible to meet everybody on the same day.

The teachers were surprised about how much we had achieved within just four days. The prototype might not have been as 'beautiful' as they would expect the final app to be (based on the high-level design of Shapes 3D Geometry Learning which some of them knew) but the interactions, and the opportunities it provided in terms of drawing and exploring 3D Shapes, were the answer to the problem of limited spatial reasoning and the inability to draw 3D shapes in 2D. They pointed out what they felt was still missing and what was important to meet the needs of the students in terms of both math methodology and pedagogical strategies.

The interviews with the math teachers proved that we had chosen the right problem to solve and we had chosen the right direction when searching for a solution. Now, we need to work on the scope of the product and the intended use within the classroom. The interviews with the children reassured us that we still had a long way ahead of us in terms of product design.


The most tangible outcome was a prototype which we used to get meaningful feedback from teachers and as functional guidelines for the later design of the app. It helped us also to iterate different design ideas before starting the development phase, which is very cost-effective. With only a few iterations and a low budget, we designed a prototype with the main functionality of Shapes 3D Geometry Drawing.

The main intangible outcome was that we learned how to work with the teachers: both inside and outside the classroom. Now we know how to create a dialogue with the true professionals of education; he teachers and schools who know the very challenges of the existing practices.

For the next 2 months, we worked diligently and alongside teachers with the aim of releasing a Minimum Viable Product that we could test with students at elementary and middle schools. The results were amazing and pretty much the same as teachers expected in the co-creation process. Now, after 9 months of continuous improvement and countless iterations, we can say that the design sprint gave us the solid foundations for the core features of Shapes 3D Geometry Drawing and the right direction to follow when it comes to the needs of our target groups. And , most of all , the  design sprint taught us how to co-design with teachers and students to create relevant and engaging digital technology that raises educational standards in 3D geometry.


Author: Milena Piasecka – manager and entrepreneur. For many years, she’s been working on digital projects in the fields of education, culture and the analysis of threats on the internet. Milena has experience with running projects with R&D components and creating video games: as a producer, a game-designer and a programmer. As a manager, she completed over 12 educational projects financed by the European Union. Additionally, she teaches children programming by using Scratch and Blockly language and tools/games such as Minecraft, mBot, CodeCombat, Lightbot, CoderDojo materials, Code.org and many more.

Crystallise your product vision
With Design Sprint get an interactive prototype in one week

18 March 2019Comments are off for this post.

How bad UX can kill your educational app. What you can do to avoid it?

UX, UX and UX. If you’re in the business of creating digital products then you probably stumble upon this term at least once a day. Yes, it’s a staple when building high-quality user-centric products (not just digital). We all know that.

  • But what could go wrong if you screw up UX whilst developing an educational product?
  • What can you do to improve the User Experience of your Edtech app?
  • And how important is the User Experience in Edtech?

What could go wrong if you screw up UX?

Let me be upfront with you. It may well kill your app. You see, unlike in Fintech and other industries, in Edtech $$$ isn’t the most critical metric for success. It won’t win you over investors by itself, and for sure it won’t bring any value to your users.

The key to success in Edtech is the ‘pedagogy’ of your product. How engaging it is and whether kids and teachers are still using it one year down the line?

Basically, before you even implement ‘tech’ in education you need to ask yourself one simple question.

Will it bring any additional value to your users?

If your users can solve a problem with pen & paper then is it really necessary to build an app for it? Will it give something additional to the users?

Btw, with Design Sprint you can create an interactive, hi-fidelity prototype of a product tested on real users.

Real cases of failed UX

Saila Juuti, head of UX at Kokoa Standard has vast experience working on UX projects with clients from around the world. Kokoa provides world-renowned certification for Edtech companies around the world. Get yours here

Kokoa Standard

Kokoa Standard's Marika Kukkasniemi testing Ovobots robot for certification


Over the years she has come across many examples of lacklustre UX. Let’s look at some of them:

1. The system doesn’t save the teacher’s time - lack of automation

One Edtech trend is open platforms, where the teacher can create assignments for their students - such as open-ended tasks, multiple choice tests and so on. The purpose of these tests is to automate some of the teacher’s work.

A common error in these kinds of systems is the lack of feedback for students. The teacher may be able to set which of the three answer options is correct, and the software can easily create grades based on that, but there are no fields for explaining why one answer is correct and another is not. In the worst case, the system doesn’t even say which of the answers was correct.

A system which only provides points still requires the teacher to go through the questions with all the students - a time which they could use to give more personal support to those students, who actually need it more.

2. The system doesn’t scale to all of its target users

Edtech products often try to cater to a large target group. What works for a 10-year-old doesn’t necessarily work for 14-year-olds. The graphical representation, language used, complexity and so on should be optimized for the most reasonable target group. It’s quite rare that the same system will work for 6-12-year-old kids.

3. Failing is not fun - feedback is key

In systems which provide challenges or problems to solve, failing a challenge should be a point of learning. When a student fails, the system should provide helps to move forward and create positive excitement for trying again. This requires that the challenge level is optimal for the student and the feedback is helpful. In case it’s not, the previously mentioned scaling problem may exist as well.

What can you do to improve the User Experience of your Edtech app?

I asked again Saila from Kokoa and Paulina Tervo from Lyfta about some practical tips on streamlining UX in Edtech.

First up Saila. Below she shares her three tips for good UX in Edtech:

1. Tell your user clearly, which problem they are solving

The best motivation to use an app for learning is if you know what you are gaining from using it. For Edtech creators, this means keeping the learning goals clear. The teachers may want to know, how the content of your solution is linking different curriculum goals, but also the learners will be more motivated if they are provided clear descriptions of what they are about to learn.

2. Design for the classroom, not just for individuals

If your target group is schools, remember that the learning environment probably involves 20 kids all trying your solution at the same time. Make the launching process as quick and easy as possible, keep the navigation path simple and support searches and prompting of the content that the user has recently viewed. Designs relying heavily on sound may also be cumbersome in a classroom.

3. The details matter

Many school solutions fall into the category of “just good enough” UX. What sets the really good solutions apart from the rest is the amount of polish and effort put to finalizing the app. Consistent aesthetics, well written and informatic system messages, smooth transitions and non-intrusive help will make the user feel good about using your solutions. Game developers need to keep the users immersed in the world they have created, so take a look at how this final level of polish is done by them.

Over to Paulina now...

Paulina Tervo is the Co-CEO and Product Director at the award-winning company Lyfta. They help teachers tackle complex topics and measure attitude change in the classroom through stunning premium quality films, VR and AR technology and pedagogy based on Finland's new Phenomenon-based learning curriculum.

lyfta app

Storytelling is key to Lyfta's success.


Paulina told me the key to their success is down to three key factors:

  1. Storytelling - Lyfta’s founders have a background in filmmaking and that’s what helps them to connect emotionally with their customers. It also helps them to tell the story of their product better to their customers.
  2. Gamification & Exploration - Their app is playful and filled with real-life experiences at the same time. Children can explore and interact with different places around the world, interact with different objects, take a peek into people’s home, etc. The real-life content is presented in a playful and explorative way, which makes them quite unique in the Edtech world.
  3. Co-creation with teachers - Another important reason why Lyfta has nailed UX is by involving teachers in the product development process. This helps them understand what needs the teachers have, what technology they are currently using and whether they have any experience in using digital products. On top of that, every teacher is given onboarding on how to use their product.

And now to the final question.

How important is User Experience when creating Educational products?

You should already know that by now. UX plays a critical role when creating educational products. Learner's goal's and how easy the technology is for the teachers to implement are two critical factors for an Edtech product to succeed. Get those two right from the beginning and you'll have a product which is scalable and loveable. On the other hand, if you're off the track from the beginning, chances are your product will struggle with user engagement and retention in the long run.

Don't let UX screw up your app
Use Design Sprint to create a hi-fidelity prototype in 1 week - tested on real users!

26 February 2019Comments are off for this post.

How to save money & reduce risks with Design Sprint

Before we begin we need to clarify the naming issue. You can find many different names of the same thing circulating all over the internet - Design Sprint, Product Discovery Workshops, Service Design Workshops, Product Design Sprint, Innovative Workshops, Google Sprint etc.

We decided to stick to the original name - Design Sprint. If you’re more familiar with a different name - don’t worry, we’re talking about the same thing!

In 2010 Jake Knapp, a Design Partner at Google Ventures, created a time-constrained process that uses design thinking with the aim of reducing the risk when bringing a new product, service or a feature to the market. In those 9 quick years, Design Sprints have taken the world by storm.

At Setapp, we are always trying to use the latest innovations - be it the new technologies or up-to-date processes. We’re constantly looking for ways to be better at what we do. Conducting high-quality Design Sprints is no different. But it’s not a ‘copy & paste’ process for us - while we’re familiar with the original ideas of Jake Knapp, we have taken them and made them our own.

Our Design Sprints are based on Design Sprint 2.0 - a new and improved version of the original idea. Design Sprint 2.0 idea was developed by AJ&Smart to wrap the whole process up in 4 intensive days of creativity and cooperation.

What is a Design Sprint?

So what exactly is a Design Sprint? It’s essentially a 4-day intensive process to develop a working prototype, get feedback from users, build a plan for next steps and understand the full potential of a project.

The whole process is split into two parts. During the first half, we work with a client at our HQ. After that, our designers get back to their rooms to deliver a working prototype, tested on real users. Our clients can then relax and wait for the results of our work.


Design Sprint Peter

Who takes part in the Design Sprint?

You might ask yourself - who exactly takes part in a Design Sprint? From our side you can usually expect a UX Designer, Software Developer and Scrum Master. Keep in mind though that this composition is flexible. We adjust it to the specific needs of every single client.

From the client’s side, we expect at least three people. It’s up to the client to choose the people best fitted for their project. We recommend picking people most engaged in it, as they will be the source of information for our experts. Usually, CCOs (Chief customer officer), CTOs, Product Owners or Sales Managers are good picks.

It’s also very important to keep in mind that there’s no Setapp Team and Clients’ Team during the Design Sprint. We are one team and we work together towards the common goal. To help us all achieve that, there’s also one additional (yet extremely important) person in the team from our side - the facilitator. He guides everyone through the process, keeps everything in line and makes the whole thing smooth, effective and enjoyable.


Design Sprint Group

Who should be interested in Design Sprints?

You might be asking yourself - is a Design Sprint for me? Can it resolve my concerns and problems? Does it fit the needs of my project?

Design Sprints are not created to solve all kinds of problems. If your issues are relatively basic, there are other ways to validate them - Design Sprints might be excessive. The same goes with the risks involved with the project. If they’re low and your project is fairly safe to deliver - don’t bother with a Design Sprint.

In general - if you’re very confident that your proposed solutions will be successful and everything is set, then you can spend your time on something different than a Design Sprint. But we know that a lot of your problems are not low risk, simple issues and it’s increasingly harder to be confident in your solutions with no working, tested prototypes.

There are tons of reasons to run a Design Sprint on your project. It’s impossible to include them all here, but we can highlight the ones that are most common:

  • You need a prototype of a project to get funding.
    We are aware that getting funding is a major issue for a lot of startups. Design Sprints are a perfect tool to achieve that - there are not a lot of things that help to sell your project better than a working, tested prototype.
  • You don't want to waste months to start a project.
    As Shirley Temple once said: "Time is money. Wasted time means wasted money means trouble". Not a lot of entrepreneurs can wait for months to see the fruits of their labor. Design Sprints allow us to deliver results after just one week of hard work.
  • You get stuck with some kind of barrier and don't know what to do next.
    We’ve seen it many times when great projects were stopped by one issue because the team didn’t know how to overcome it. What’s even worse - we’ve seen teams ignoring the most burning issues because it was the easiest thing to do. Design Sprints can help you overcome even the hardest and most challenging issues you face.
  • You want to reduce risks by creating a working prototype.
    There are so many risks facing every project - financial, technical, external etc. Having a tested working prototype significantly lowers all kinds of risks and boosts your project efficiency.
  • You have a big project but want to check part of it before going full steam ahead.
    Huge projects are rarely delivered all at once. It’s way too risky, it makes no sense financially and it’s really complicated. That’s why it’s important to test and deliver the most important parts of the project separately. That’s when a Design Sprint comes in handy. It’s much easier to deliver the rest of your idea, when you know that the core of it is tested.
  • Your team seems to be out of creative solutions.
    We know that a traditional, lengthy development process is not the perfect environment for creativity. That’s why Design Sprints are so great - because of their condensed program, people involved in them don’t get tired and bored with a process. It’s rare to see so many great ideas in such a short span of time. That’s what we call a culture of innovation.


Design Sprint Wall

What is the outcome of a Design Sprint?

The outcome of our Design Sprint is an interactive prototype, verified by real users and with a coherent recommendation of what should be your next steps. A Design Sprint's outcome is definitely not some kind of paper prototype or blueprint. You get an interactive prototype that feels and looks like a real product.

You also get a clear vision of what your next steps can look like. It all depends on your project, but if you’re ready for development, you can easily move on from a Design Sprint into an Agile Sprint. That’s when we start coding, engineering and designing to build a final product (or MVP).

What is the most important outcome of the Design Sprint is a validation of your idea. Validation, combined with a tested, working prototype, can give you the confidence that your project is set for success.


Design Sprint Desk


A Design Sprint is a great way to kick off a project. It can truly change the client’s perspective, it boosts creativity in a way that normal development can’t and it significantly reduces risks. Obviously, it’s not a solution for everyone. But if your problems are complex, broad, difficult and they’re critical to the success of your project - we can’t recommend Design Sprints enough!

Also check our next article where we discuss in details the whole process of Design Sprints! You will learn how every single day of Design Sprint unfolds and what are the values of each stage.

Crystallise your product vision
With Design Sprint get an interactive prototype in one week

28 August 2018Comments are off for this post.

What can you expect during a Design Sprint? A brief look into the 4 phases

In the previous article on Design Sprint, we introduced you to the framework and its benefits. Now we want to take you through all the Design Sprint phases so that you can get a quick idea of how the process looks, what can you expect during those days, and how it aims to increase your team’s confidence with the problem that you are trying to solve.

Let’s dive in!

UPDATE: The previous version of this article was based on a classic 5-day version of the Design Sprint. It was updated to match the latest 4-days version that we currently offer at Setapp!

The 4 Design Sprint Phases

Design Sprint Process

Monday - Phase 1: Map & Sketch

This is the first day that you and your team will get together to create a path for the whole week by setting a target and uniting everyone under a shared umbrella. It’s important that during this day everyone from the Sprint team is present.

During this phase, you’ll explore the business from all angles and achieve a common understanding of the business, the customer and the problem. This requires you to invite the right people (who can be part of the Sprint team or not) to come and share the business goals, technology capabilities, challenges, and user needs. You’ll focus on exposing the team’s or business’s assumptions and knowledge gaps that exist.

You’ll also talk about what success looks like for the company and what it means for this sprint. From there your team will make plans to fill the riskiest knowledge gaps and work on how you can validate the riskiest assumptions. On day one, you should be able to pick one target to focus on for the rest of the week - the one problem that you can solve and will help you achieve your long-term goal.


Photo by Daria Nepriakhina


These are some of the activities or tools you can use to help you decide on a target for the sprint:

  • Set a long-term goal - to kick off the sprint. 
  • List sprint questions - to rephrase assumptions and obstacles into questions.
  • A simple user journey mapping - to help you pinpoint opportunities and challenges.
  • The ‘How-might-we’ note-taking method and voting - to force the team to look for opportunities and challenges.
  • Lightning talks - to give team members and external experts a voice and a chance to share the knowledge they have built up.
  • Empathy building exercises - to get into the user’s mindset.
  • The five ‘whys’ exercise - to get to the deep root of every problem.

After a half-day of understanding and choosing a target, it’s time to think about the solutions for your sprint. Those will be the fuel for the following days of the sprint!

The next step for the team is to explore as many solutions as possible. This is an important part, because many insights, different perspectives, and approaches will come out from each individual team member.

First, the sprint team meets to warm-up and ‘remix’ existing ideas - in many cases, there’s no need to reinvent the wheel, many innovative ideas are built on existing ones. Then, the team should decide what problems they should focus on:

  • is there a specific gap in the user journey map that the entire team should work on? Or
  • are there too many critical points that the team should cover?

In that case, the team should divide among themselves the pieces of the map that they want to tackle. Next, the team should sketch some solutions and you will need... lots of paper!


by FirmBee


The Sketch phase doesn’t involve any kind of brainstorming sessions, everyone works individually generating competing ideas on paper.  And nope, you don’t have to be a good drawer!

These are some of the activities or tools you can use to help you decide on a target for the sprint:

  • Lightning Demos - to give a short demo of an existing product.
  • Boot up note taking - to collect your thoughts and write down your ideas.
  • The crazy 8s exercise - to choose your 8 strongest ideas and sketch 8 variations.

Tuesday - Phase 2: Decide & Storyboard

On this day, you’ll decide which sketches have the best chance to solve your problem, and then you’ll decide which one(s) will be prototyped. This is done individually first, and then, in a team. The day looks something like this:

  1. Evaluate solutions
  2. Critique all at once
  3. Make a decision all at once
  4. Plan your Prototype

You may start to think that it could be difficult to vote honestly (e.g. people feeling pressured by team leaders) or that it may take too long to reach a consensus. But fear not because there are a variety of tools and methods that help teams to reach a unified plan. Moreover, democracy or camaraderie has not always a place in your sprint. The Decider will give the final ‘Supervotes’, which will be the foundation for your prototype.

Now that you have your winning solution(s), it’s time for the team to put the pieces together and make a plan. You’ll use the Storyboard method - where you imagine your finished prototype and can spot challenges and points of confusions before the ‘real’ thing is built. This will be your step-by-step plan for the next day.


Photo was taken from ‘Storyboarding, 2.0!’ by Tim Hoeffer.


These are some of the activities or tools you can use to help you choose the best solution to focus on:

  • The Sticky decision process - to express everyone’s opinions without lengthy debates.
  • Silent critique - to have a more unbiased and individual critique period.
  • Group critique - after the silent critique, to review and open the discussion of the results.
  • Storyboarding - give a space to dive into the interactions of the ideas.
  • Assumptions Board exercise - to help the team to identify the key questions that your Sprint will help you answer.
  • Decision Matrix - to help the team evaluate ideas

Not sure if Design Sprints are for you? Then read our previous blog post to learn about the benefits and outcomes you’ll get when running this 4-day framework.

Wednesday - Phase 3: Prototype

This is your “fake it till you make it" moment. You’ll take the storyboard that you finished on Tuesday and transform it into a working prototype.

And when I say a ‘working prototype’ I mean a working and realistic-looking facade! There’s no need to have a full-working backend and have every single part of your flow built. You should only build something that looks real enough that will get you an authentic response from your testers.


Photo by Jason Wong


These are some of the activities or tools you can use to help you build that ‘fake’ prototype:

  • Divide and Conquer - to assign tasks to each team member that fit their skills.
  • Storyboarding - to have a clear plan of what needs to be built.
  • Prototyping tools - to make it as real as possible.


Thursday- Phase 4: Test & Validate

This phase is what makes the entire Sprint worthwhile. On Thursday you will test your working prototype with real users and you’ll validate or invalidate your hypothesis. It is recommended to test it with at least 5 users.

During the test phase, your team will interview and observe how users react and interact with your prototype. It’s important that the whole team is present and sees the real-time reactions and feedback of the users. This will allow every team member to capture learnings, insights, and a first-hand experience on how users use your product


Photo by Kobu Agency


During this phase, you could involve your UX designer (if you have one) or someone to lead a usability study. Additionally, you should talk with your technical experts and/or leadership stakeholders to give you feedback on your user tests. There’s no way to stress this enough: you will learn so much on day 4. At the end of the day, you will know how much your team still have to go and you’ll know exactly what do next.

These are some of the activities or tools you can use to have a successful testing and validation day:

  • Usability Test - to take critical questions and answer them in your hypothesis.
  • Stakeholder review - to get leadership feedback.
  • Technical review - to make sure you can build your solutions.
  • Sprint Retrospective - to review and summarize the week’s results. 
  • Sprint Planning - to plan what comes next and ensure actionable plans.


Outcomes at the end of the Sprint

In a nutshell, you will get a goldmine of insights, you will (in)validate your riskiest assumptions and (hopefully) you will have a clear idea of where to go and what to do next with your product!

Don’t be over excited though. You will not get something even close to an MVP. Remember that MVPs require much more input, work and time than a 4-day process. However, you can consider the Design Sprint a success if at the end you:

  • Learned things you didn't know about your business, product, and users
  • Know where solutions are working and where they are lacking
  • Get a tangible direction on how to propel your solution to the next level

Generally, after a Desing Sprint, some teams keep working on the test results and on how to improve the prototype (something like version 2.0). If it’s not clear what you should do next, you can run a follow-up Sprint to review the Sprint questions and think about new solutions. The learning process could be slow, but what you’ll learn is invaluable.


So what's next?

If at the end of the Design Sprint you’re confident and ready when it comes to the solutions that you have validated, then you can move to Agile Sprints: a tech-driven version of DS, where you bring coding, engineering and design to the table to build a real product (or MVP).

For companies and product teams, Design Sprints can be a fantastic way to save tons of money and time on development and design. Agile Sprints offers the same benefits to teams: to adapt quickly to changes, iterate on ideas, identify problems or opportunities faster, test pieces of the software quicker, among others. For instance, here at Setapp, we have our own version of Design Sprints that precede Agile Sprints and we have seen the value, certainty, and direction that it brings to our clients before starting any coding commitments. But that’s another story to tell 😉

PS: don’t forget to read part one of our Design Sprint series (if you haven’t already). You’ll learn about what the Design Sprint is, how it became popular in the product development arena, and the benefits you can get once you run one in your company!

Crystallise your product vision
With Design Sprint get an interactive prototype in one week

7 August 2018Comments are off for this post.

Test and validate your product within 5 days using Design Sprints

Imagine that you’ve just had an epiphany and found the solution to an unanswered problem. “This makes a great business idea. I need to build it!”. Wouldn’t you want to fast-forward to the future and see your finished product and how it interacts with its users? The Design Sprint will give you that superpower.

With this framework, you don’t even have to make any costly commitments. To explain it more thoroughly, I will go through it step-by-step. Firstly, I want to give you an idea of:

  • how the DS came to be
  • what it is
  • what are the benefits of implementing it
  • why it should matter to you

In the next articles, I will address the process (day-by-day), the activities that help unleash a team’s creativity, and lastly, what our process at Setapp looks like. So if you like the idea of cutting to the chase, to end useless debate cycles and compress months of time into a single week, then keep reading!

And btw, if you want to learn how to use Design Sprints to jumpstart your product, let me know and we can have a chat.

The birth of the Design Sprint

‘Efficiency’ and ‘quick results’ became part of our daily vocabulary as businesses and technology started to move faster. Many teams realized that they needed to abandon the traditional non-software inspired waterfall process if they wanted to keep up with new tech and emerging products. As a result, businesses shifted to iterative development methodologies like Scrum to implement measurable quick iterative cycles of development - also called ‘sprints’.

Then around 2010 in Google, Jake Snapp, created the first version of Design Sprints when he was looking for a quicker process to design and launch products rapidly. His framework soon became the ‘de facto’ means of testing & building products throughout Google’s teams which enabled them to launch products in weeks - not months or years!

In 2012, Jake and his colleagues started running the Design Sprints with the portfolio startups of Google Ventures to help them make daring, data-driven, and user-focused decisions. By 2016, their legendary Sprint book came out, and companies like Uber, Slack, Airbnb, Lego, and Medium have used DSs to improve their products and make their businesses more profitable.

So what is a Design Sprint*?

*People often refer to it using different names: Product Discovery Workshops, Service Design Workshops, Product Design Sprint, Innovative Workshops, Google Sprint, and others. For the sake of this article, I’ll refer to it as Design Sprints - it’s original name.

“A Design Sprint is a five-phase framework that helps teams to answer critical business questions through rapid prototyping and user testing”

Based on Design Thinking** methodologies and (Agile) Sprints, the primary goal of a Design Sprint is to reduce the risk of bringing a new product or a new feature of an existing product to the market by building & testing a prototype in only 5 days (Monday to Friday).

** Note that Design Thinking and Design sprints are two different things, while DT is the foundation, philosophy, and a toolkit for innovation, Design Sprints are a specific step-by-step system for producing and testing new products or ideas.

During those 5 days, the Sprint team will go through various phases such as:

  • understanding
  • ideating
  • deciding
  • prototyping
  • testing


design sprint 5 days

I will go through this process and phases in detail in my next article.

Who can participate?

The Design Sprint framework is for big companies, startups, individual teams or anyone that needs to generate new (innovative) ideas. It will replace the traditional brainstorming meetings with an idea-generation machine consisting of a multidisciplinary team.

The Sprint team should consist of 7 or fewer members and people from different disciplines is invited. Be it a marketing or customer service representative, Head of Software Development, CEO, and designers… all experts can participate in the 5-day Sprint sessions. This way, the team of experts - and the decision-maker - can solve problems together more smartly and effectively.

design sprint

Why run a Design Sprint?

If at this moment you - as an entrepreneur, Product Manager, CEO, or Customer Service Leader, etc. - have….

  • An idea for a product or service
  • A problem that you can’t find a viable solution for
  • An MVP that needs it’s solutions to be validated
  • A product that doesn’t engage users
  • A product that requires new features to keep up with competitors

Then Design Sprints are perfect for tackling any of those! Of course, there are many different reasons for teams to run a Design Sprint. It’s important to note that based on their intentions and goals the methods used in the Sprint should be personalized to each case and team. You will get more information on this in my next articles.

Do you share these challenges? Book a call and discover how design sprint can help you achieve your goals

Here are some of the benefits of running a Design Sprint:

1. You save tons of time.

Remember it’s 5 days, and you’ll get the results of the equivalent of 5 months worth of meetings, emails exchanges, and consultations. The smooth collaboration between members of different disciplines and with different skill sets can (and will) spark creativity. As a result, in a very short time frame you will:

  • get real solutions to problems
  • to speed up product discovery
  • help the team to gain crucial knowledge and learnings

2. You save money.

More often than not, many teams build a product that will have to be re-built months later. With DSs, anyone can spot opportunities and risks in those 5 days that will save the team from horror nights. The faster you know what solutions or problems you need and can solve, the quicker you’ll create your prototypes.

3. You take user-centered decisions.

You’ll be working with people from different disciplines and a facilitator, who will oblige everyone to work with respect, empathy, and openness. The team's structure will make everyone to be aware of the customer’s needs, motivations, problems, and expectations at all times. Also, the tools and activities are built around the end-customer, and therefore, during those 5 days the team will try to listen, trust and develop meaningful relationships with them.

4. You get deliverables.

At the end of the Sprint you will not get estimations, speculations or RFPs, but real user-validated prototypes. Moreover, you’ll be part of the whole process: ideation, sketching, prototyping, and testing!

Design Sprints are built in a way where the creativity of every team member will be unleashed.  It doesn't matter if you are not good with sketching, coding, or with numbers. Every team member’s skills will be used to its best and in an effective way. Remember that it’s only a prototype!

Key Takeaways

Design Sprints are not the answer to all your product development problems. You also don’t want to be running Sprints for every single idea, doubt or new feature you want to have. That’s not the point.

You want to use DS when you have encountered an obstacle or/and a complex problem that it’s a critical business opportunity or challenge.  For example, launching your product to a new market, targeting a new customer segment or introducing a feature that will fundamentally change the whole UX of your product.

Also, I want to stress again some of the reasons why Design Sprints would be an excellent addition to your product development efforts. You will:

  • Solve the most complex problems
  • Make your product/feature user-centered
  • Increase your team’s speed and effectiveness to take critical decisions
  • Find the potential risks and opportunities of a product/feature fast
  • Reduce bureaucracy
  • Effectively gather and collaborate within departments
  • Test an idea and prototype quick

In my next article, I am going to go through each day of the design sprint to show you how it all works. Stay tuned!

At Setapp, we have our version of Design Sprints. Our team has mostly used it to help our clients to design and kickstart new products or features. We have seen the value, certainty and excellent results that it brings to our clients.

If you want to find out how you can run a design sprint in your company, send us an email and we'll be happy to tell you more.


Book a Design Sprint


Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998


POL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998

ISR: 220 Hertzel Street, 7630003 Israel


Setapp Sp. z o.o.
VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616



PL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998

ISR: 220 Hertzel Street, 7630003 Israel


Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616



Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998


Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616



Setapp Sp. z o.o.
VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616



POL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998

ISR: 220 Hertzel Street, 7630003 Israel


Setapp Sp. z o.o.
VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616



PL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998

ISR: 220 Hertzel Street, 7630003 Israel


Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616



Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998


Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616


Clutch award badge
Instagram Icon

©2020 Setapp. All rights reserved.