15 September 2020Comments are off for this post.

User Personas: Why Are They So Important?

Currently, the market is filled with digital products, including web and mobile applications. Yet somehow, according to statistics, 90% of new startups fail. Some of the main reasons are lack of market need and no interest from users, which may indicate some apps were built upon wrong assumptions of their founders. The top rule when creating a new digital product should be then to understand that you (as a creator) are not your user, and the key to success is to understand your audience, and then meet their needs. User personas are a great tool to achieve that.

What is a user persona?

A user persona (called also “a persona”) is a fictional character based on real data. It represents the key segments of the (potential) users of a product or a service. These users share similar behavior patterns, product requirements, preferences, and goals.

Building personas is an essential step to understand who your users are. It answers the question “Who do we design for?” which affects the whole process of product design and development. The more realistic the personas are, the more market-fit products can be created.

Personas should be based on qualitative and quantitative user research, to properly reflect key characteristics of the audience of the product. It is important to remember that the personas are as good as the research behind them.

If you do not have any data to back up your personas and you base them only on your assumptions and guesses then they are called proto-personas.  It is not recommended to base your decisions only on such models, because they may be created around your own beliefs and background and not those of your users. However, if eventually you choose to create proto-personas, make sure to validate them with user research in the next step.

Why are user personas important?

Long story short, personas usually serve as safeguards against the most common mistake - designing for yourself. They not only help to understand the target audience, but they also consolidate data gathered during user research, and evoke empathy among the team and stakeholders. Getting into your (potential) customers' shoes supports the creation of really useful and valuable products for the target users.

To be more precise, well-done personas help to:


  • Create a market-fit solution

The fact that personas are created as derived characters from user segments decreases generalization, so we can fully focus on the specific needs of specific people.

The understanding of users’ problems and needs, the background of their behavior, and their expectations lead to the creation of useful products that offer exactly the features that users really want to use. At the same time, personas help to avoid wasting time on building features that aren’t useful for the audience.

If the product is already live, creating personas help to uncover gaps and contribute to the constant improvement of product usability.

Personas not only express users’ articulated needs but also may uncover such needs and goals that users may not even be aware of. It  helps to drive innovation and explore new areas of the market.


  • Make design decisions

Personas serve as a design compass. They help to prioritize and focus on the features that are most important for users. Referring to personas shows the best design patterns for specific target groups and prevents designers from being tempted by generalization.

They can also serve as a tool to cut unnecessary discussions about features that will not be used.

Moreover, keeping the focus on real users across the whole design phase helps to keep consistency across the product.


  • Consolidate data gathered during user research

Personas help to aggregate large amounts of data gathered during user research.

As visual representations, they are easy to understand, memorable, and converge all information of the target group into one place. The use of personas eliminates wasting time on going back to raw data from user research and provides instant insight into the audience’s attributes.

Furthermore, when the product is already running and personas are ready, they can be extended by ongoing user research results. Personas that are kept up to date provide a great source of knowledge everyone can refer to.


  • Evoke empathy among the team

User personas are human-like representations of target groups, who have feelings and emotions the team can empathize with. They provide a common understanding of users’ motives and ways of interacting with the product.

Personas can be hung on the office wall or board to keep the team focused on target groups and used during the whole process of development. How? For example, whenever someone in the team needs help making a decision regarding the product, they can refer to personas and ask “Would John use it?” to quickly validate if the feature is relevant enough.


  • Teach external parties about target groups

The personas serve as a digestible way to transmit information about the target groups to other people. They can be exported as PDF or JPG files and sent to outside agencies to provide a clear description and achieve a common understanding of the target audience.


  • Support decisions across the whole company

User personas, as representatives of target groups, are a great tool that supports a decision-making process also outside of the design phase. Referring to user personas might be beneficial for many areas of your business, for example:

    • Sales & business - Knowing a lot about your audience can affect your value proposition and business model. It may make it easier to achieve more shareholder value because personas make the target group and the idea behind them more tangible. Awareness of users’ motives, needs, and frustrations might increase lead generation by better adjustment of the approach to the target group. 
    • Marketing and social media - Marketing materials need to be adjusted to the audience to be effective. Personas are a great tool to use while creating marketing campaigns and materials. 
    • Developers - When they can empathize with users it is easier to make a decision which approach is best to take while programming.
    • Copywriters - Personas may support copywriters by ensuring the content of the product is tailored to the audience.
    • Quality assurance - It may be easier for QA Specialists to test the product when empathizing with users. Test scenarios based on real use cases bring better results. 

Additionally, if the company tends to conduct workshops using role-playing exercises, personas are great, ready-to-use characters to take.


  • Recruit participants for user testing

If the product is already live and running you might want to empower it with complementary user research, such as usability testing. Personas serve as great guidelines to recruit participants for qualitative studies.

Looking for a partner to help you deliver your digital project?
We've created many successfully projects for companies from all over the world

When to create personas?

As early as possible. The key moment is the beginning of a project, during the pre-design phase to ensure that the solution will be adjusted to real user needs.

Defining the target group too late might cause a lot of problems. The biggest one might be a lack of interest from the users’ side, which will end up in a great loss of time and money. Still, better late than never! It may be beneficial even for ongoing projects to keep track of the trends and adjust the features the product offers to current user needs.

It’s important to understand that user personas should never be “finished”. Times change, the same as users’ behavior, expectations, and needs. Personas should be updated with the results of continuous user research to ensure the best possible match to the target group during each stage of the project. 

How many personas do you need?

Actually, the fewer personas you have, the easier it is to design to meet their needs. Your aim is to have one persona representing one target user group. Some companies target their product only to one type of user, and in that case, one persona is enough, but larger ones, especially enterprises, may need more.

So, if you find that your customer group is very diverse and can be divided into different segments, feel free to create more personas. Make sure each one is different, memorable, and easy to distinguish. If they feel too similar they probably should be fuzed into one. Just make sure they share common attributes that overlap each other.

If you end up with more than one persona, you should pick the most important one - an ideal user - and call it a primary persona. The rest should be called secondary (or, in special cases, complementary) personas. They are also important, but not as much as the primary one. It is especially helpful while prioritizing features and justifying the decisions.

You should limit yourself to a maximum of 3-4 personas that represent main user groups. The goal of personas is to focus on the most important audiences, not to meet the needs of everyone attempting to use your product. Remember, you cannot please everyone and if you try, you can end up with a “feature creep” - a too-complicated-to-use product. 

Part 2 is coming!

In the 2nd part of this article, I will focus on explaining how to create a good persona and what it should consist of. I’ll also add a few tips from my own personal experience of creating personas many times before. You will also be able to download our great template that will help you to create a user persona for your own project. Stay tuned - or sign up for our newsletter and we will let you know when 2nd part of this article is available!

I am a placeholder image
Agnieszka Körber
A passionate User Experience Designer and Cognitive Scientist. She's been easing interactions between humans and digital products for the last few years.

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

5 September 2018Comments are off for this post.

The 3 most common misconceptions about design in IT product development

”Well, design in product development will take too much time and money. At the end of the design process, all I’m going to have are a few mockups and still no product. Why should I waste time and money, if I could just start the agile product development process right away?”

If you’ve ever thought about skipping the design phase to save some time, then this article will give you insights that prove the opposite. In the following paragraphs, I am going to tell you how easy it is to fall for some common misconceptions about design, how and why you should push away those thoughts, and last but not least, I am going to tell you why design should be at the forefront of your development process. Let me start with a short story of how I got introduced to the world of design.

We all are designers. Are we not?

7 years ago, when I was building my first CRM I wondered how to approach it best. I had a business and tech background but had no relevant experience in design, which allowed me to approach the design aspect of this project without biases.

That’s how I “invented” user personas and user journeys. I spent 2 weeks interviewing the sales department and other stakeholders. I created mockups that demonstrated step by step real jobs-to-be-done and real activities of sales representatives and their managers. All cool but these tools and knowledge had already been there for years. I could have used them earlier. Why didn’t I?

Around that time, people were caught up in the information pollution, and design had become a buzzword and lost its true meaning. There was a time when to me design was synonymous with a fancy awkward chair. I had zero curiosity about design - I thought that learning more about Design was a waste of time. However, with time, I learned about service design and design thinking, and I found a missing link between idea and execution.

Misconceptions about Design in IT

When design became a “thing”, people started to use the word design (as a noun) more often for describing the end result of designing (verb). Most of them had an opinion about designs (noun) but they were lacking the context and the purpose for which it was designed. They saw a distorted picture of what design really is.

During my years as an entrepreneur, I learned that these are the most common misconceptions about design in product development (from my experience in the IT industry):

1. Design is about making products look beautiful.

Sure it is. People buy with their eyes. But it’s just one part of the truth. Design in this context is about great interactions with the product and the look is just one final layer of product.

Most importantly, it is about translating business, market and tech insights into a usable product that people will buy.

2. The Design Process is unmanageable and chaotic. 

Not true. For example, brainstorming without a clear goal can be unpredictable but for professional designers that’s not the case. Design tools and activities are organized in a well-defined process.

In general, there are 4-5 stages, each with different objectives, inputs, activities, and outcomes. They can vary between different approaches, frameworks and methodologies (Service Design, Design Thinking, Design Sprint, ect.), but generally, the rules or framework are very similar.

3. Design with all those post-its doesn’t look professional.

From a distance, it may look that way. But once you’re fully immersed in the project you’ll see that you are tackling really important questions and critical issues. Businesses want innovation but real innovation doesn’t look like innovation, it looks like an inside joke that nobody gets. “Electric supercar? Yeah, right”. “Phone for $599? Yeah, sure”.

So what’s Design really about?

Let’s keep it simple- design is...

  • about profitability, feasibility, and usability
  • manageable and measurable
  • bout the effects on the users and the business

But let’s go deeper into the topic because I think there’s much more to understand about design and it has nothing to do with beautiful and aesthetic deliverables. Keep reading!

Unknown risks and opportunities

Most products fail because we try to invent the wheel. (Here, wheel = the framework for problem-solving, design and development that design is a big part of) Instead, we can use tools, an approach and a mindset that was defined and tested out over the last few decades.

Without this framework and guides, design in product development (especially in the IT . industry) is blind and based on guessing and invalidated assumptions.

If you would like to learn more about Design Sprints - a known and tested Design Framework - head over to our introduction of this 5-day framework. You'll learn all about the benefits of running a Design Sprint Workshop at your company.

The main benefits of design in product development

Design could be called a mindset rather than an activity or any specific approach, toolbox or methodology. This mindset arranges different tools, processes, and frameworks to solve product development challenges. Here are a few benefits that this mindset can bring to your project:

1) Clear vision: 

It helps to set a clear vision in the presence of a dozen stakeholders with different agendas. Design and collaboration go hand in hand. Design workshops are an opportunity for a team to untangle a problem together by going through a series of exercises designed to get to a specific outcome.

2) Clear roadmap:

It helps to define a clear roadmap in the presence of hundreds of requirements and assumptions. Design is a neat framework that organizes requirements and solves complex business/technology/market problems. When you consider the determinants of a successful product, you can divide them into dozens of categories:

It’s almost impossible to take into consideration all of the dimensions of information without a proper framework!

3) Manageable risk: 

It helps to test assumptions, manage what's known or defined and helps to uncover unknown risks and challengesWhen the product domain is explored it’s much easier to identify key factors that can impact your product. These risks are turned into assumptions and tested.

Also, design reduces risks of exceeding the budget or creating something that nobody wants. I can’t tell you the exact number but from my experience working at several software houses, I have never seen a project over $25k that went well without any design process at all.

In case you're already familiar with the Design Sprint Framework, read our article about what you can expect during a Design Sprint, where you'll get a glimpse at the 5 Design Phases + handy tips to run the workshop yourself.

Key takeaways

Less waste 

Many times design is as underestimated as a backup file. You understand the value of backups once you lose all your precious data. And you will value design once you lose 3+ months of work and still have a useless product that nobody wants to buy. This is no exaggeration 😀

Buyable products

Design is very important because otherwise, you’ll end up building something nobody wants and your product will fail.  Remember that there is a huge gap between what we think people want and what they really want. That’s why design emphasizes on the customer so much and starts with the discovery phase.

Less risky journey

When the product scope is explored, it’s much easier to spot risks that can impact your product. These risks are turned into assumptions and tested. Design reduces risks of exceeding the budget or creating something that nobody wants. From my experience working at several software houses, I have never seen a project over $25k that went well without any design process.

Mindset for growth

As I wrote earlier, design is more of a kind of a mindset so the purpose of this article is not to convince you to use some specific tools or processes but to give you the taste of how this mindset works and how it can help not only your products but your entire business.

I hope this article shed some light on some mistaken notions about design and why design in product development is critical. If you are struggling about how to implement design in your software development process or you simply want to discuss which frameworks would suit your company better, send us a message - we would be happy to help you!

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


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.