Abstract

A challenge for all organizations is to establish and encourage the business’s continuous development, and its products and services. To create an innovative environment where co-workers, customers, and other people’s insights can be collected, engagement and transparency are needed. Polestar wanted to create a business and service design process that supported courage, learning, and fast development. The objective of this thesis is to evaluate and analyze the Design Sprint process and implement it into Polestar’s way of working. A Design Sprint is a four-day process for answering critical business questions through design, prototyping, and testing ideas on users. By working together in a team and in a structured way, you can eliminate endless discussions and meetings and compress months of work into a period of 4 days. A prototype was created in Miro, an online collaborative whiteboard tool, that worked as a step-by-step guide for running a Design Sprints. The prototype was tested by running two separate Design Sprints on two different projects. The sprints were done remotely, and both sprints resulted in prototypes that we tested on test users. The Design Sprint process proved to be a highly effective process for developing a prototype to test on real users. The Design process was well-received by Polestar and the employees that were involved in the testing of Design Sprints.

Swedish: En utmaning f¨oralla organisationer ¨aratt etablera och uppmuntra f¨oretagetskontinuerliga utveckling och dess produkter och tj¨anster.F¨oratt skapa en innovativ milj¨od¨armedarbetare, kunder och andra m¨anniskors insikter kan samlas, kr¨avsengagemang och ¨oppenhet. Polestar ville skapa processer f¨oraff¨ars- och servicedesign som st¨oddemod, l¨arandeoch snabb utveckling. Syftet med denna avhandling ¨aratt utv¨arderaoch analysera Design Sprint-processen och implementera den i Polestars arbetss¨att.Design Sprint ¨aren fyra dagars process f¨oratt svara p˚akritiska aff¨arsfr˚agorgenom design, prototyper och testa id´eerp˚a anv¨andare.Genom att arbeta tillsammans i ett team och p˚aett strukturerat s¨att kan du eliminera o¨andligadiskussioner och m¨otenoch komprimera m˚anaderav arbete till en period av fyra dagar. En prototyp skapades i Miro, ett kollaborativt whiteboard-verktyg, som fungerade som en steg-f¨or-steg-guidef¨oratt k¨oraDesign Sprints. Prototypen testades genom att k¨oratv˚aseparata Design Sprints p˚a tv˚aolika projekt. Sprinterna gjordes remote och b˚adasprintarna resulterade i prototyper som vi testade p˚atestanv¨andare. Design Sprint-processen visade sig vara en mycket effektiv process f¨oratt utveckla en prototyp f¨oratt testa p˚ariktiga anv¨andare.Design Sprint-processen mottogs v¨alav Polestar och de anst¨alldasom deltog i testningen av Design Sprints.

1 Contents

1 Introduction 5 1.1 Objective ...... 5 1.2 Goal ...... 5 1.3 Polestar ...... 6

2 Theoretical framework 7 2.1 Design Sprint ...... 7 2.2 What is a Design Sprint? ...... 8 2.2.1 Monday ...... 8 2.2.2 Tuesday ...... 9 2.2.3 Wednesday ...... 9 2.2.4 Thursday ...... 9 2.2.5 Friday ...... 9 2.3 Design Thinking ...... 9 2.3.1 Empathize ...... 10 2.3.2 Define ...... 10 2.3.3 Ideate ...... 10 2.3.4 Prototype ...... 11 2.3.5 Test ...... 11 2.4 The problem with Design Thinking ...... 11 2.5 Design Thinking vs Design Sprint ...... 12 2.6 When Design Sprints does not work ...... 12 2.7 Design Sprint 2.0 ...... 15 2.8 Where have Design Sprints been implemented? ...... 15 2.8.1 The approach on scaling Design Sprints in big organisations 15 2.8.2 Lego ...... 16 2.9 Remote Design Sprints ...... 17

3 Method 18 3.1 Understanding ...... 18 3.1.1 literature study ...... 19 3.1.2 Interview of employees ...... 19 3.2 Designing ...... 19 3.2.1 Miro ...... 20 3.2.2 Low-fidelity ...... 20 3.2.3 Mid-fidelity ...... 20 3.2.4 Mid-fidelity test ...... 20

2 3.2.5 High-fidelity ...... 21 3.3 Testing ...... 21 3.4 Evaluation ...... 21

4 Final Prototype 22 4.1 Preparations ...... 23 4.1.1 Prepare this ...... 23 4.1.2 Miro basics & Learn this ...... 25 4.1.3 Facilitator learn this ...... 26 4.2 Day1 ...... 27 4.2.1 Expert interviews ...... 27 4.2.2 Map ...... 29 4.2.3 Long Term Goals ...... 30 4.2.4 Sprint Questions ...... 31 4.2.5 Lightning Demos ...... 32 4.2.6 Doodling ...... 33 4.2.7 Crazy 8s ...... 34 4.2.8 Solution Sketch ...... 35 4.3 Day2 ...... 38 4.3.1 Heat Map Vote ...... 38 4.3.2 Solution Presentation ...... 39 4.3.3 Synchronised Voting ...... 40 4.3.4 User Test Flow ...... 41 4.3.5 Storyboarding ...... 42 4.4 Day3 ...... 43 4.4.1 Prototyping ...... 43 4.5 Day4 ...... 44 4.5.1 Testing ...... 44

5 Design choices 46 5.1 Understanding the users ...... 46 5.2 Problem framing ...... 46 5.3 Remote Design Sprints ...... 47 5.4 Miro ...... 47 5.5 Facilitator ...... 47

6 Results 48 6.1 Understanding ...... 48 6.1.1 Literature study ...... 48 6.1.2 Interview of employees ...... 49 6.2 Designing ...... 49 6.2.1 Low-fidelity ...... 50 6.2.2 Mid-fidelity ...... 52 6.2.3 Mid-fidelity test ...... 52 6.2.4 High-fidelity ...... 53 6.3 Testing ...... 53 6.3.1 First iteration ...... 53 6.3.2 Second iteration ...... 54

3 6.4 Interviews of Design Sprint participants ...... 54 6.4.1 Previous experiences with Design Sprints ...... 55 6.4.2 Learning process ...... 55 6.4.3 Understanding ...... 55 6.4.4 Suitable for Polestar? ...... 55 6.4.5 Voting process ...... 55 6.4.6 Users tests ...... 55 6.4.7 Improvements ...... 56 6.4.8 Result of the sprints ...... 56 6.4.9 General experience ...... 56

7 Discussion 57 7.1 Result ...... 57 7.2 Way of working ...... 58 7.3 Efficiency ...... 58 7.4 Usability ...... 58 7.5 Problems & further work ...... 59

8 Conclusion 60

9 Acknowledgements 61 9.1 Polestar ...... 61 9.2 Ume˚aUniversity ...... 61

4 Chapter 1

Introduction

A challenge for all organizations is to establish and encourage the business’s continuous development, and it is products and services [1]. To create an innovative environment where co-workers, customers, and other people’s insights can be collected, engagement and transparency are needed. Other organizations have managed this successfully in different manors by developing different kinds of processes [2, 3]. Polestar would like to create a business and service design process that supports courage, learning, and fast development. A new design process is needed that covers both the cultural aspects of the company, as well as the way of working. Polestar has shown interest in the Design Sprint process and would like to investigate if this design process would be suitable for the organization. A Design Sprint is a time-constrained, five-phase process, were a team can answer critical business questions through design, prototyping, and testing ideas with customers, in a short period of time [4]. This thesis aims to understand the Design Sprint method and how it could be implemented into Polestar’s workings by evaluating and analyzing the different methods and tools used to run a Design Sprint. This process will work as a guide on how to establish and execute a design process (design, build, and test) in a four-day time frame.

1.1 Objective

The objective is to evaluate and analyze the Design Sprint process and implement it into Polestar’s way of working.

1.2 Goal

The goal is to create a tailor-made Design Sprint process that meets Polestar’s organization’s requirements and needs.

5 1.3 Polestar

Polestar is an electric performance car brand that originates from the STCC Polestar racing team, which later became Polestar Performance AB when the company was acquired by Volvo Cars in July 2015[5]. The racing team changed the name to Cyan Racing, and Polestar Performance became an automotive company focusing on electric performance cars [6, 5]. The company is owned by Volvo Car Group and Zhejiang Geely Holding, and enjoys specific technological and engineering synergies with Volvo Cars and benefits from significant economies of scale; as a result.[7] The headquarters is located in Gothenburg, Sweden, with production taking place in Chengdu, China [6].

Polestar, as an electric car performance brand, focuses on delivering refined performance and cutting-edge technology. Their mission is to bring driving pleasure into a new era by offering electric performance cars that are designed and engineered without compromise [8]. In 2017, Polestar introduced their first car, a hybrid sports car with 600hp, the Polestar 1 [9]. Polestar launched their second car in 2019, the Polestar 2, with the slogan “Goodbye Normal“. A fully electric, five-door fastback with 400hp. The Polestar 2 is the first car in the world to have an infotainment system powered by Android, with the Google Assistant, Google Maps, and Google Play Store built-in.[10]

6 Chapter 2

Theoretical framework

This section will present the theoretical framework that was created by doing a literature study to understand the Design Sprint method, how it works, where it has been implemented, how it has evolved, and when not to Design Sprints. The understanding of this information was crucial in order to understand how to create and design a Design Sprint for Polestar’s way of working.

2.1 Design Sprint

Jake Knapp, a former Google employee, was experienced in running brainstorming workshops when working at Google. Obsessed in improving team processes, Knapp one day received the question “How do you know brainstorming works?“. Knapp did not have a good answer to the question, and when analyzing the outcomes of brainstorming, he discovered more and more flaws as the process was challenging to measure [11].

My best work happened when I had a big challenge and not quite enough time. - Jake Knapp, Sprint [11]

Knapp later realized that the most efficient work from his side was when he was part of projects with a limited time frame. For example, he visited Serge Lachapelle and Mikael Drugge, two Google employees in Stockholm, to develop a video meeting software that could run in a web browser. Knapp was visiting for a few days, so they worked as fast as they could, and they had a working prototype by the end of the visit. That prototype was tested among google employees, and a couple of months later, the whole company was using the software. The prototype was later launched as Google Hangouts [11]. Knapp analyzed this development concept. The short time frame forced the team to focus. There was no time to overthink details. The team, the engineers, the product manager, and the designer were together in one room, solving their problems and answering the others’ questions. This way of working was to be called “Design Sprint“ [11].

7 2.2 What is a Design Sprint?

The term Design Sprint is a time-constrained, five-phase process aimed at reducing the risk of developing new products, services, or features to be released to the market. Jake Knapp developed the Design Sprint together with Google Ventures (GV) [11]. GV, a venture capital firm created by Google to invest in promising startups, was interested in running Design Sprints with the startups in GV’s portfolio. The Design Sprint was tested and improved after a couple of iterations. Together with Braden Kowitz, John Zeratsky, and Michael Margolis, Knapp developed a framework to work as a guide in how to work with Design Sprints.

The book Sprint was released in 2016 and described the process of developing the Design Sprint. It mentions different cases and projects where the Design Sprint has been successful but also mentions some cases where the Design Sprint failed to deliver [11]. The book works as a guide for people that are new to the concept of the Design Sprint.

The book provides the reader with step-by-step instructions on what to do under a five-day period, Monday - Friday. Every step has a timestamp for the reader to know how long a particular exercise should take to be as effective as possible. The figure below shows the outline of the different days.

Figure 2.1: The Design Sprint week (Based on [11]).

2.2.1 Monday

Monday is all about finding the end goal of what the group is trying to achieve during this five-day period. Monday starts with agreeing on a goal. Next, a map is created to visualize how to get to the goal. By the afternoon, the experts will join to give their thoughts. Finally, a target is picked, an ambitious but manageable piece of the problem solvable in a period of one-week [11].

8 2.2.2 Tuesday

During Tuesday the team will come up with solutions. The day starts with inspiration, reviewing existing solutions to improve. Next, each team member will sketch their solutions following a four-step process to empathize critical thinking over beautiful sketches (everyone can sketch). These sketches will be the foundation for the next day’s decision making [11].

2.2.3 Wednesday

In the morning, the team will review all the different solutions to find the best solution for achieving the long-term goal by voting on all the different solutions. In the afternoon, the team will take the winning solutions and create a storyboard: a step-by-step plan for the prototype [11].

2.2.4 Thursday

The storyboard is done, and during the Thursday, the team will have a “fake it“ philosophy to create a realistic prototype. The prototype will be used to test the solutions during the next day’s user testing [11].

2.2.5 Friday

By the end of the week, the team has stated a goal, created and decided on different solutions, and built a prototype to present the ideas. This, by its self, would make for a fantastic productive week. On Friday, the prototype is tested. Customers are interviewed, and the team learns by watching the customers interacting with the prototype. If the prototype worked, the team knows the solution is worthy of further development. If the solution did not work, the team now knows what to change and probably saved a lot of time by not taking this solution into further development [11].

2.3 Design Thinking

Since the 1960s, Design Thinking has developed as a creative way to solve complex problems [12]. The term Design Thinking refers to the cognitive, strategic, and practical processes that are used when developing design concepts such as new products, buildings, machines, etc. [13, 14]. The idea of Design Thinking as a particular approach for creatively solving problems came about in the development of creativity techniques during the 1950s and new design methods during the 1960s. John E. Arnold in “Creative Engineering“ (1959) and L. Bruce Archer

9 in “Systematic Method for Designers“ (1965) was among the first authors to write about Design Thinking [15, 16].

Figure 2.2: The five phases of Design Thinking (Based on [17]).

Design Thinking is a framework in the essence that the whole concept refers to a way of thinking when solving problems. Shifting the problem solving from business reasons to problem-solving regarding the real users needs, finding what their problems are, and finding solutions for those [18].

The visual representation of Design Thinking is often illustrated in five different steps, as seen in figure 2.3.

2.3.1 Empathize

The first part of Design Thinking is the Empathizing phase, which immediately sets this model apart from other business models. Many of the other models try to understand the user needs and wants, but few do this from a rational point of view [19]. This phase is all about developing a sense of empathy for the people you are designing for. This is important to get a deeper understanding of the user in terms of how the user behaves, feel, think, and what they want, when interacting with the product in a real-world setting [20].

2.3.2 Define

In the define stage, you gather all your insights from the Empathize stage. The gathered information is then analyzed in order to define the core problem and goal from a human-perspective [20].

2.3.3 Ideate

This third stage is all about trying to generate as many ideas as possible that tries to solve the problem. With the two first stages done, the designers have a solid

10 understanding of the problem and can now start to “think outside the box“ in order to create innovative solutions to the problem [20].

2.3.4 Prototype

The designers will create a number of inexpensive prototypes from the ideas generated in the Ideate phase. This is done to test how the generated ideas are performing in the last phase, the testing [20].

2.3.5 Test

The designers or evaluators will test the prototypes generated in the previous phase. This may be the final phase of the Design Thinking model, but since this is an iterative model, the results of the testing are usually used to redefine one or a few of the solutions. The designers can go back to the different phases to reiterate and improve their solutions [20].

2.4 The problem with Design Thinking

With Design Thinking, we have these five different phases, as mentioned above, and within these different phases, there is a lot of flexibility. The different phases contain a large number of different tools, methods, templates that you can use to solve different problems. Design Thinking, however, does not give you a concrete step by step process on how to tackle a big problem. There is nothing guiding you in how to do the ideation or how to empathize with the user, for example. Design Thinking can be explained as a fundamental framework and a mindset in how to think when solving big problems. Design Thinking provides a huge toolbox of things that you can learn and use, but you, as the problem solver, have to figure out how to use all these different tools. This means that when a problem comes around you have to choose what tool and templates to work with in order to solve your problem and also in what order to use them to achieve your goals [18]

IDEO, a large design consultancy, was founded in 1991 by David Kelley. With IDEO, Kelley popularized the term Design Thinking [18]. IDEO mentions that “Design Thinking is not a cookbook“ [21], meaning that Design Thinking is not a step by step process that you can follow. Design Thinking is a set of tools and methods that you can learn and then use to solve your problems.

Many companies and organizations have acquired Design Thinking into their way of working. There are a large number of consultancies that help other companies to implement Design Thinking into their business. The consultancies teach the companies different methods and tools that are used within Design Thinking, and they have workshops and brainstorm sessions. The problem is when the consultancies leave. The companies and organizations that are now taught in

11 how to work after this new Design Thinking methodology often have a hard time keeping the Design Thinking spirit alive. The employees that are taught do not pass it on to the new employees, so it eventually dies out [22]. Design Thinking, as a concept, is being sold as a practical set of tools for innovation, but it is not. Jonathan Courtney, from AJ&Smart, describes the situation:

Design Thinking is like going to a cooking theory course. You learn how cheese and pasta work together. You learn how to cut onions. But once you get out and you are working in a team, you are kinda like, okay, how do we actually make the Spaghetti Bolognese? - Jonathan Courtney [22]

2.5 Design Thinking vs Design Sprint

If Design Thinking is described as a cooking theory class, the Design Sprint can be described as the recipe. The Design Sprint takes different tools and methods from Design Thinking and turns it to a step by step guide in how to solve a problem. Design Sprint is not so different from Design Thinking in general as it uses the “toolset“ that Design Thinking provides. But the big difference, and maybe the biggest reason why it has become so successful, is the structure, the guidance in how to execute every step in the process. Design Thinking is not useless just because it lacks structure. Design Thinking gives a very good baseline, but it needs a structure. Some way of how to use and execute it and that is where the Design Sprint can be used to add that needed structure [23].

2.6 When Design Sprints does not work

Justin Zalewski, director of product design at Studio Science, mentions in one of his articles [24], that they often get asked if Design Sprint can make a better result compared to traditional methods. In a lot of cases, that is true, and the problem is perfect for running a Design Sprint. It is of the right size, and the outcome of the sprint can be prototyped quickly and validated through user testing. In other cases, the Design Sprint is not the method to use [24].

Zalewski mentions three different scenarios where the Design Sprint fails to perform:

Lack of information to effectively inform the solution: The first day of the sprint is meant for collecting as much information about the users as possible together with the stakeholders and the experts within the field. This is done to understand the requirements of the user and is, in most cases, enough to act as the foundation to design upon. But there are cases where the stakeholders and even the experts do not possess the understanding of the user to that extent that

12 they know how to form the right requirements. Zalewski stresses that in order to perform a sprint, the following questions most be possible to answer [24]:

• The overall vision of the product.

• Needs and feedback from the costumers.

• How the product works from a technical perspective.

• Previous attempts in solving this problem, and what was learned from them.

The stakeholders should not have any difficulties giving background around the following questions. There are circumstances where needs and feedback are difficult to understand from a stakeholder point of view. To be able to design a good product, you need to understand your users; you need to learn about them. What are their needs? What motivates them? What are they trying to accomplish? To learn about your users, you need to talk to them, spend time with them, and get to know them from a personal point of view rather from a demographical point of view [24].

You need to learn about your users before you conduct a Design Sprint - Justin Zalewski [24]

When the problem is not a product design problem: According to Zalewski, the Design Sprint is meant for product design problems. The book Sprint talks about examples regarding e-commerce and a service robot, two very different products, but still under the same category, product design. If the problem is outside of this are, for example, when validating a brand or a service design problem, the Design Sprint is not the right method for that kind of validation. Google Ventures has released a sprint called “The 3-hour brand sprint“, which is designed to help you get started with your brand [24]. Google Ventures specifically mentions that this sprint is just to get you started and does not replace a good branding agency [25].

When a good enough prototype can not be produced in one day: The regular sprint gives you one day to create a prototype. One day is in a lot of cases enough to create great prototypes that give the impression of a real product and gives valuable results when testing. There are some cases where one day just is not enough time to create a prototype that is real enough to test. It is possible to add days for prototyping, but this has to be planned for. If not planned for, you can end up with a prototype that just is not enough to give them valuable feedback that you are looking for. [24]

An article by Designit [26], a global design firm, written by Asger Østerbæk, talks about some common misconceptions about the Design Sprint. Østerbæk means that the Design Sprint is overrated in the sense that it gives people the impression that any problem is solvable when locking yourself in a meeting room

13 for five days to make a Design Sprint. Østerbæk further describes how the general expression of the Design Sprint is that it will solve most design problems, even problems of high complexity or problems that involve a high level of strategy. For example: “How do we create a new core business using our existing products?” or “Design a new product for millennials that can save our future revenue”. Østerbæk stresses that the Design Sprint will fall short in these cases. It is simply not possible to create a new business or service in just five days. Not if you want a finished product by the end of day five. Østerbæk mentions that if you want to design a product or a service on a business strategy level, you need a different approach [26].

Do your homework: Your homework is to understand and learn about your users, and it relates directly to the paragraph above, Lack of information to effectively inform the solution, that Zalewski talks about. It is very hard to understand your users and their needs during a five-day sprint if you do not have any earlier experience of the user group [26][24].

It is not a sprint; it is a marathon: One common misconception about the Design Sprint is that people think that after five days of hard work, they will have a finished product ready to be implemented and used. This is not the case at all. The Design Sprint will illustrate a tested flow or a design that is part of a solution. The majority of the work comes after the sprint is made when trying to optimizing and perfecting the outcome that was produced from the sprint. The testing that is done during the fifth and final day is also completely unnecessary if you do not plan further development of the product based on the users feedback gathered during the test [26].

Not everyone is a designer: Design is a craft just as carpeting, or music, is a craft. It takes time, a lot of time, and experience to become a good designer. Design is a craft used to create great solutions, but it does not mean that everyone can not have good ideas. A good idea needs a team of skilled designers to be executed to create value and meaning for the user. The Design Sprint approach to gathering a lot of different people in a sprint, analysts, business strategists, and a sprint facilitator, may not produce great design but rather a good idea [26].

You do not become a designer overnight because you have attended a course in Design Thinking — just like you do not become a concert pianist by buying a book of music. - Asger Østerbæk [26]

John Vetan mentions in his article that the focus of the sprint may be too much towards the actual sprint and too little towards the rewards of the sprint. Vetan talks about how it is easy to focus on how to run the sprint, sorting the logistics, get people booked, which leads to the reward of having a user-tested prototype by the end of the sprint. Vetan further questions if that reward is as meaningful for the organization as it is to the sprint team. He describes this as the “Design Sprint Bubble“. The sprint has to have a connected business goal and customer needs. Sprints should not be made just to do a sprint [27].

14 Most of the companies trying to implement Design Sprints already have functional workflows and processes in place. Design Sprints should aim to complement and enhance these and also remove existing barriers and constraints, all while creating value for the business and ultimately the customer. - John Vetan [27]

2.7 Design Sprint 2.0

Since the release of the book Sprint in 2016, the Design Sprint has made it into a number of different companies and organizations. The sprint has changed quite a lot since the original release, as the model has been iterated and improved throughout the years. Companies and organizations have tailored the original sprint to be as good of a fit as possible for their way of working. At the beginning of 2018, Aj&Smart released what they call the Design Sprint 2.0, describing it as the most up to date model of the sprint that provides improved efficiency. So how is it different from the original sprint [28]?

Four days, instead of five. After having done more than 200 sprints, Aj&Smart made the systems of the sprint more effective and more efficient, which means that some of the exercises in the sprint have been shortened [28].

You only need the full team the first two days. Originally, the full team had to be present during all of the five days of the sprint, which requires much commitment. However, since it, for many reasons, is difficult to hold several people to focus on just one thing during five days, this has changed so that the full team is just needed during the first two days of the sprint [28]. The Design Sprint 2.0 uses four days instead of five. This has been achievable trough shortening a lot of the exercises to be able to fit all the exercises with the reduced number of days.

2.8 Where have Design Sprints been implemented?

Since 2016 and the release of the Design Sprint, many companies have implemented the process into their way of working. Google, Slack, Airbnb, and Uber are just some examples of companies that have started working with Design Sprints

2.8.1 The approach on scaling Design Sprints in big organisations

Changing habits in an organization can be difficult if the habit has been ongoing for a long time. Sometimes there needs to be a big change in order to succeed in breaking habits and prevent them from falling back into them.

15 It is hard to break habits in small, unobtrusive ways. If you go soft, you will not have a real impact, and whatever you end up doing will not generate enough traction. - Jonathan Courtney

2.8.2 Lego

LEGO understood that they needed something dramatic to change their working habits, which was influenced in a decade of habits. Their new CEO Niels B. Christiansen, pulled the emergency brake, which resulted in a complete stop of the companies production for two whole months. Eik Brandsg˚ard,who has been with LEGO for the last 13 years, was one of the people responsible for the whole operation. When Brandsg˚ardwas asked if this could not have been done less dramatically, Brandsg˚ardanswered: “It would have been an evolution, when they actually needed a revolution.“ The complete shut down of the production got people’s attention, and for two months, a large number of the internal section of the organization put their daily work aside to learn Design Sprints [29].

Some people in the organization had made Design Sprints before the complete shut down of the production line. However, this was an isolated occasion. To make a change to the whole organization, they needed a programmatic intuitive, which was provided by the complete stop. People were interested in the Design Sprint as they understood it could make progress and results in a short period of time. Brandsg˚ardwas in charge of the involvement of the people, and he mixed people who had had earlier experiences of Design Sprints with people that had no earlier experience. This led to the Design Sprint spreading across the organization with multiple teams running Design Sprints at the same time [29].

After the two months of the complete shutdown, the teams presented their results to the top management. They presented the prototypes and what they had learned along with the processes of the sprints [29].

When Brandsg˚ardwas asked to lead this change, he gathered a group of project managers that would be in charge of the different sprint groups, so-called “sprint- leaders“. He gave them all a copy of the Sprint book to learn about the process. The sprint-leaders were told to take one step at a time, always prepare the next day in the evening, and prepare the next exercise while the group was working with the current exercise [29].

Along with the involvement of people and the sprint teams, there needed to be some function of preparation of all the different sprints. The Sprints needed briefs, booked rooms, and supplies for the team to get started with the work. Brandsg˚ard created the “Control Tower“, a group of five creative directors. Their work was to identify problems that needed solving, and they also were in charge of all the planning concerning the sprints and sprint teams. The sprint teams presented their results to the control tower by the end of each sprint [29].

16 2.9 Remote Design Sprints

With the Design Sprint, being based on a lot of different exercises executed within a structure, it is possible to run these kinds of sprints completely remotely. The members of the sprint team do not need to be together in a psychical room in order to run a sprint. In Jonathan Courtney’s article “From Idea to App Store: A Design Sprint Case Study“ [30], he writes about the process of running a Design Sprint for an app development project completely remotely. Johnathan and his team were based in Berlin, while the company they worked with was based in San Francisco. The whole project spanned over four weeks with a five-day sprint as the starting point [30].

Several different programs can be used in order to make a remote sprint successful. Video chat’s such as Teams1 and Google Hangouts2 can be used for audio and visual interaction between team members. Further on, there are collaborative programs such as real-time board (now called Miro3) allowing to create “How Might We“ notes in a virtual environment. This allows all the participants of the sprint to follow along and add content from their own computer and works just as in the real world but in a virtual space. This software can also be used for creating the map to visualize the flow of the product, and can also be used for decision making by voting on different ideas by placing dots [30].

1Microsoft Teams - https://teamsdemo.office.com/#/0/2 2Google Hangouts - https://hangouts.google.com/ 3Real Time Board/Miro - https://miro.com/blog/features/realtimeboard-is-now-miro/

17 Chapter 3

Method

This chapter is about the understanding, designing, and testing of the new Design process aimed to be implemented into Polestar’s way of working. The method Design Thinking, was chosen because of how the method focuses on problem- solving regarding the real users needs and problems, and how to solve them from a users perspective rather from a business perspective (further explanation is given in section 2.3) [18]. A literature study was done to gain knowledge of what had already been done by other companies and organizations. With the knowledge gained from the study, the work moved on to understanding Polestar as a company by interviewing employees. They were asked about their current work situation, and what they thought could be improved. With the interviews done, the work continued with the design of the prototype. A lo-fi prototype was created in Miro (a collaborative online whiteboard tool). This was done mainly to understand the structure and the flow of the interaction of the prototype. Later a mid-fi, and a high-fi, prototype was created, also in Miro. A dry-run of the mid-fi was done to see what worked and what could be changed before the actual testing of the prototype with real users. The testing was done in two iterations on two different teams with two different projects. The testing resulted in smaller changes to the prototype between the first and second iteration. The result of the testing was gathered by interviewing the participants of the testing.

3.1 Understanding

Implementing a Design Sprint [11] into an organization requires knowledge about the process and what it is capable of. This is vital for the Design Sprint to work as intended since a Design Sprint is not a “one size fits all“ solution [24]. In order to get a better understanding of the Design Sprint process, a literature study was done. This knowledge helped to form the design and structure of the prototype. In order to gain knowledge about the company, interviews of employees were done to understand how their current work situation looked like and what their needs were.

18 3.1.1 literature study

A literature study was done in order to get a better understanding of Design Sprint as a concept. It was important to understand the concept to understand how this would be possible to implement into Polestar’s way of working. The study mainly looked into other peoples experiences with the Design Sprint and tried to answer the following questions:

• How does Design Sprints work?

• Where has it been implemented?.

• How has it evolved?.

• When does Design Sprints not work?.

The information was found mainly through Medium articles, where people have written many of their experiences with the Design Sprint. Information was also found through short videos and books.

3.1.2 Interview of employees

To better understand the Polestar organization, an interview of employees was conducted. Christian Appelt provided a list of employees that he thought would be able to give valuable insights of how the organization functions and operates. Each employee was invited to a 30 minutes session where they were asked about their current work situation and what they thought worked well and what could be improved. This was done to gain a broad understanding of the company and its various departments and employees.

3.2 Designing

The Designing of the prototype was done with a low, mid, and high-fidelity prototype. The goal was to design a framework/guide for how to do Design Sprints. The prototype would be designed in such a way that people with no experience of Design Sprint would be able to use this guide, get the necessary information and education of the process, and then be able to run a sprint. Due to the Covid-19 situation1, the prototype was designed for running Design Sprints remotely.

1Covid-19 - https://en.wikipedia.org/wiki/Coronavirus disease 2019

19 3.2.1 Miro

Miro is an online collaborative whiteboarding platform that enables teams to work together. This platform enables multiple people to work and collaborate on a project at the same time, just as working together on a whiteboard, but virtually. Since Miro is a platform that is integrated and used by Polestar’s employees, this tool made a perfect fit for designing and running Design Sprints.

Figure 3.1: Print screen of Miro

3.2.2 Low-fidelity

The low-fidelity prototype was created to understand what was supposed to be part of the prototype and to understand the structure and flow of the interaction. A new project was created in Miro, and a simple structure was created.

3.2.3 Mid-fidelity

The mid-fidelity prototype was also done in Miro and was a further developed version of the low-fidelity prototype.

3.2.4 Mid-fidelity test

The mid-fidelity prototype was tested by doing a rushed Design Sprint where we sprinted through all the exercises in one day instead of four. This was done to learn what worked and what was needed to be modified before doing the real tests.

20 3.2.5 High-fidelity

With the learnings from the mid-fidelity testing, a high-fidelity prototype was created.

3.3 Testing

The prototype tests were done by running two separate Design Sprint on two different projects with two different groups. Each Design Sprint lasted for four days and resulted in a concept, a prototype, and user tests of the prototype.

3.4 Evaluation

To evaluation of the test was done through interviewing some members of the sprints. The members answered questions about their experiences of the Design Sprints.

21 Chapter 4

Final Prototype

In this section, the details of the prototype and its content will be explained. The walkthrough will be divided into five different categories, Preparations, Day 1, Day 2, Day 3, Day 4. The content of each category will be explained with text and images.

Figure 4.1: Overview of the prototype.

22 4.1 Preparations

This section will show all the parts of the prototype that are linked with the preparations that should be done before doing a sprint.

Figure 4.2: Overview of the preparation section of the prototype.

4.1.1 Prepare this

This part of the prototype included the one page brief of the project. This is needed to educate every participant of the sprint on why we are doing this sprint and what we are trying to solve. This is the first step of the preparations. The second step is to make sure all tasks in the Kanbaan To-Do list are solved. The Kanbaan has tasks such as Find a facilitator, Find the team, Find test users. All these tasks need to be done in order to continue and to start a sprint. When the sprint team is set, you need to schedule and plan every participant’s time to make sure they have the time needed to take part of the sprint. It is essential that all the participants are present the first and the second day of the sprint and they have to be present at all times. They can not exit the sprint and “take a call“ or “join this other meeting“. If they are part of the sprint, they need to be present and focused during all the exercises, and they need to be aware of that before the

23 sprint starts. Therefore the scheduling and planning are of high importance. Step four of the preparations is to create personas to understand whom we are designing this product for.

Figure 4.3: “Prepare this“ artboard.

24 4.1.2 Miro basics & Learn this

This part of the prototype is meant to be a “playground“ for the participants where they can learn about the functionalities of Miro. The playground goes through the vital functionalities that the members of the sprint need to know about to take part in the sprint without technical disruptions. They learn how to copy and paste notes. How to vote with dots and how to upload images. There is a To-do Kanbaan here as well. This to-do list makes sure that all the members have the necessary facilities before the sprint starts, a good pair of headphones, a decent webcam, and other essential things.

Figure 4.4: Artboard where the user learn how Miro works.

25 4.1.3 Facilitator learn this

This part of the prototype is meant to be tips for the facilitator. To facilitate a sprint can be somewhat challenging at times, especially if your team is new to the Design Sprint process. These tips are meant to be some guidance in how to be as good of a facilitator as possible.

Figure 4.5: Facilitator tips.

26 4.2 Day 1

Day 1 is about finding a goal and to create solution sketches. Day 1 starts with Experts interviews experts where the experts on the subject will join to give their thoughts. Next, a map is created to visualize how to get to the goal. Long term goals and sprint questions are the next steps in which the team defines the direction of the sprint and what could go wrong along the way. When the direction is set, the sprint moves on to the Lighting Demos, where the team will do a quick research of the web to find other solutions that could work as inspiration to the sprint. Now follows the creative part of the sprint. The sprint members will do a quick doodling session where they will put down their ideas on a piece of paper. When done, they will continue with Crazy 8’s and eight different iterations of one of their ideas for eight minutes. When finished with the crazy 8’s and a short breather, the team will continue with creating a solution sketch. Every member will create their concept of the ideas they have on how to solve the problem.

Figure 4.6: Overview of all the exercises included in day one.

4.2.1 Expert interviews

The first exercise of the sprint is the Expert Interviews. This is where 2-3 experts on the subject are invited. The facilitator will lead the questioning, and the team members will take HMW “how might we“ notes. If one of the experts says something like “sometimes we have double booked cars“, an HMW note could be written as “How might we ensure there are no double booking of cars?“. At the top of the image, three different boxes can be seen. These boxes represent the “What, Why, How“ for each exercise, basically explaining what to do, why we do it, and how to do it. All exercises have these boxes troughout the prototype to make sure that members of the team can read through the “what, why, how“ before a sprint to educate themself of the process. At the bottom of the image, eight different boxes can be seen. This is the personal workspace of every team member where they can write their HWM notes. These personal workspaces help the members not to get influenced by each other during the exercises. In this case, during this exercise, each member will be instructed by the facilitator to zoom in on their own workspace so that they are unable to see what the other members are writing. These personal workspaces appear in other exercises as well. When all the questions have been asked, and the interview is done, every member will copy their notes to the big artboard. Here they will read through all the HMW’s and categorize them. The categorization is mainly to motivate the members to read through the team member’s notes. When the categorization is done, the members of the sprint will vote on the notes that they think are of the highest importance of

27 the sprint. To the left, in the image, red dots can be seen. These are the dots that the members will drag and place on the notes they think are essential. The decider has four votes, and the other members have two votes each. After the voting, the facilitator will create a voting tree to the right of the artboard to display the notes that got the most votes.

Figure 4.7: Expert Interviews artboard.

28 4.2.2 Map

This exercise is about visualizing every step of the path that the user takes towards the goal. The creation of the map can be somewhat hard to get your head around when you are new to this exercise. Therefore, an example of a completed map is shown under the artboard for the members to take a look at to get a better understanding.

Figure 4.8: Image of example map.

The example shows the map of the user journey when choosing and buying coffee beans from the blue bottle coffee website. There are four main steps along the way.

• Discovery - The user discovers Blue Bottle Coffee by going to the physical store or via a web search or a Facebook ad.

• Learning - The user learns about the company and its products by talking to a barista at the store or by comparing competitors on the web.

• Using - The user uses the company’s website and chooses beans to order and enters order details.

• Goal - The user buys their choice of beans and gets the beans delivered to them.

During the preparations of the sprint, the stakeholder of the project will create a brief of a map. This Map is then copied from the preparations board to this board, and the team will then further develop the Map if necessary. The Map visualizes the flow through the product/service. This is important as it helps the team focus on crucial moments of the user’s journey.

29 Figure 4.9: Map artboard.

4.2.3 Long Term Goals

During this exercise, the members of the team will write down 2-3 long term goals each. These goals are supposed to be a very optimistic view of what the final product could be in two years if everything went excellent and hassle-free. When the members have written their goals, they will vote on what goals they think are the most important. Every member of the sprint gets three votes each, and when the voting is done, the facilitator will select the top 3 goals and read them out loud for the team. These goals will now work as the foundation of the direction of the sprint. The members of the team will be reminded to lock back at the long term goals multiple times during the Design Sprint to focus their ideas and sketches around these goals.

30 Figure 4.10: Long Term Goals artboard.

4.2.4 Sprint Questions

The sprint questions focus on the things that can go wrong with the product/solution. The members are now asked to write 2-3 questions each where they write “can we ...“ to highlight something that they want to try to eliminate from happening. Example: “Can Design Sprints lead to a more efficient way of working?“. The questions are later voted on, and the top 3 questions are selected, and the facilitator reads them out for the team. The members of the team will be reminded to lock back at the sprint questions multiple times during the Design Sprint to focus their ideas and sketches in trying to solve these questions.

31 Figure 4.11: Sprint Questions artboard.

4.2.5 Lightning Demos

The Lighting Demos is about finding relevant examples of how others have approached a similar issue that can be used as inspiration for this sprint. Every member will individually research the web and try to find print screens of other solutions that can be used as inspiration. The members are asked to find 2-3 examples, and when done, they will upload their findings to the artboard of this exercise. Each member will write short notes describing the things that they have found, and the facilitator will then read and explain all the different findings to the team. The facilitator does the presentation of the findings in order to keep the anonymity of the members. During the presentation, one person will take notes describing the big picture of every finding.

32 Figure 4.12: Lightning Demos artboard

4.2.6 Doodling

Doodling, it is time to get creative. This is where each member will grab a pen and a piece of paper and start to sketch some of the ideas they have gotten along the way. This exercise is meant to boost creativity and help the members get a better understanding of their ideas. When the time is up, the members will take pictures of their sketches and upload them to the exercise’s artboard. When all the sketches have been uploaded, each members of the team can take a look at what the others have sketched.

33 Figure 4.13: Doodling artboard.

4.2.7 Crazy 8s

The crazy 8’s. Maybe the most stressful and uncomfortable exercise in the whole Design Sprint process, but there is nothing to worry about. This exercise is just meant to boost your creativity even more! Each member will divide a piece of paper into eight different rectangles, like this: Each member will now take one

Figure 4.14: Image showing how to divided your a4 paper in to eight blocks. of their ideas and create eight different iterations of that idea in eight minutes, meaning that you will only have one minute for each sketch. Very stressful, but this exercise forces you to be creative.

34 Figure 4.15: Crazy 8’s artboard

4.2.8 Solution Sketch

Solution Sketch is the last exercise of the first day. The members will now create their solution to the problem with the help of all the exercises that have been done throughout the day. The mission here is to create a self-explanatory sketch of a concept that the member think could solve the given problem. Before they start sketching, they are asked to look at an example of a solution sketch to get a better understanding of the task. See figure 4.16.

35 Figure 4.16: Solution Sketch example [31].

Each person will take a few pieces of A4 paper and create a surface to sketch on. It can be multiple screens, a full experience, or a simple page. They will give their concept a catchy title since they are anonymous and can not use their names. Notes will be added on the side, with explanations. When done, all the concepts with the notes will be uploaded to the artboard.

36 Figure 4.17: Solution Sketch artboard.

37 4.3 Day 2

It is day two of the sprint, and it is time to review all the concepts and decide what concept to choose for the prototyping. In the morning, the team will review all the different solutions to find the solution that has the best chance of achieving the long term goal. This is done by voting on all the different solutions. In the afternoon, the team will take the winning solution and create a storyboard: a step-by-step plan for the prototype.

Figure 4.18: Overview of all the exercises included in day two.

4.3.1 Heat Map Vote

During the heat map vote, the members will go through all the concepts and vote on the things they like. The facilitator will invite them to place a couple of votes on the things they like. The members can vote on a concept as a whole, but they can also vote on features within a specific concept. This process and why we do a heat map vote is to catch everyone’s attention. If a feature gets a bunch of votes, it will automatically become a focus area drawing attention to people that have yet not seen that feature. The members are also able to write questions on the notes that are placed below each concept. However, there will not be any answered questions here. This exercise is entirely mute, which means no talking or discussions between the members.

38 Figure 4.19: Heat Map Vote artboard.

4.3.2 Solution Presentation

This is where the anonymity is broken for the first time since the start of the sprint. The concepts will be copied with all the votes from the previous exercise’s artboard to this artboard. Each person will have some time to explain their own concept and how they thought when designing this concept. If there were any questions regarding any of the previous exercises’ concepts, they would be answered here. When each person has done their presentation, each member will select one of the concepts that they think should be the one to continue with. Each member will write what concept they have chosen and write down three reasons for choosing the concept. When done, the members will place their notes on the concept they chose.

39 Figure 4.20: Solution Presentation artboard.

4.3.3 Synchronised Voting

All the concepts from the previous exercise will once again be copied into this exercise. Now its time to do the final voting on the concept that the team thinks should make it to the prototyping. All the members of the team will have one vote that is linked to their name. The decider has two votes and will be able to either vote on one concept and a feature from one of the other concepts or vote on two different concepts, which will result in creating two different prototypes. Since the votes that the decider places overrule all the other votes, meaning that if everybody except the decider chooses concept number 2, but the decider chooses concept number 1, the winning solution that makes it to the prototyping will be concept number 1. Therefore all the members, except the decider, will place their

40 votes at the same time. When the votes have been placed, the decider can see what the others have voted for, and then decide what concept to chose. When the decider has placed their votes, we have a concept to prototype!

Figure 4.21: Synchronised Voting artboard.

4.3.4 User Test Flow

This exercise is meant to function as a support for the upcoming exercise storyboarding. Here each member will create a user test flow, each of which is a flow of six action steps. Example: The user clicks an ad and navigates to the website. This exercise is done to make the storyboarding a bit easier. Each member creates their six action steps of how they think the flow of the prototype should look like. When done, all the flows are placed on the artboard, and the members vote on the flow they think fits the prototype best. The decider has two votes, and everyone else has one vote. Everyone will place their votes at the same time except the decider—the decider votes on flow and one specific action step. The votes of the decider will decide which flow to go with.

41 Figure 4.22: User Test flow artboard.

4.3.5 Storyboarding

Storyboarding, this is where the recipe for the prototype is made. The winning user test flows action steps will be placed in the boxes of the storyboard. The team’s mission is now to fill the gaps and to create a logical flow through the prototype. The team will use as much as possible of the already created sketches to create the storyboard. When done, they have created a recipe for how to create the prototype that will be tested on test users.

42 Figure 4.23: Story Boarding artboard.

4.4 Day 3

With the help of the storyboard, we can now start to build the prototype that will be tested on test users.

4.4.1 Prototyping

Prototyping can be done in many ways. Polestar uses Figma 1 as their prototyping tool, and Figma was, therefore, suitable to be used to develop the prototypes for the Design Sprint. When the prototype is done, you can share a link with the test users to give them access to the prototype. The actual prototype is not uploaded to Miro. This step in Miro functions as a guideline.

1Figma - https://www.figma.com/

43 Figure 4.24: Prototyping artboard.

4.5 Day 4

The last day of the Design Sprint and this is where the testing of the prototype is done to see if the concept that was developed is something to continue with or if it has to be reiterated

4.5.1 Testing

During the testing, the facilitator asks questions to the test user. The questions are written on the sides of the artboard. With the help of the questions, the testers are able to create a scenario that they want the user to follow. Another person takes notes of how the user is experiencing the prototype.

44 Figure 4.25: Testing artboard.

45 Chapter 5

Design choices

This chapter will cover the different design choices based on the knowledge gathered during the literature study.

5.1 Understanding the users

In section 2.6, Zalewski talks about the importance of understanding your users before conducting a Design Sprint. In order to meet this requirement, the Preparations section of the prototype was added. In this section, the team has to create personas before running a sprint. The intention of this design choice is to make sure that the team has a discussion about who the users are and what the user wants from the product. In this section, the team also has to book test users for the user testing that is done by the end of the sprint. This further forces the team to think of what the users are and what users to book for the user’s tests.

5.2 Problem framing

A crucial part when running a Design Sprint is to have a good understanding of the problem. This is important not to give false impressions that a Design Sprint could solve any problem in just a couple of days, which Asger Østerbæk mentions in his article (see section 2.6). Justin Zalewski mentions the importance of having as much information as possible before running a sprint (section 2.6). A one-page brief was added to meet these requirements in the preparation section of the prototype.

46 5.3 Remote Design Sprints

Due to the Covid-191 situation, the prototype had to be modified in such a way that it could be used remotely. Section 2.9 in the literature study gave some inspiration in how to manage a Design Sprint remotely and what tools to use. The original plan was to develop a prototype that was supposed to be used in a physical environment, but since this was not possible, the prototype had to be developed in such a way that a Design Sprint could be done remotely.

5.4 Miro

In order to meet the requirements of the way of working of the organization, Miro2 was chosen as the platform for the development of the prototype. This choice was made since this online whiteboard tool already is used by employees within the organization.

5.5 Facilitator

Through the Design Sprint, helpful information was added to the prototype to guide the facilitator as much as possible. Tips and instructions were added to the preparations section of the prototype. Every exercise also has some instructions informing the facilitator what to think about and what to remember.

1Covid-19 - https://en.wikipedia.org/wiki/Coronavirus disease 2019 2Miro - https://miro.com/

47 Chapter 6

Results

This chapter will present the results of the work that has been done.

6.1 Understanding

This section presents the results from the literature study and the interview of the employees from the understanding phase of the project.

6.1.1 Literature study

The literature study gave insights into the Design Sprint process. Section 2.2 explained the Design Sprint process as a whole and gave insights on the original structure of a sprint. Section 2.3 gave insight on Design Thinking and the problems with that process. Design Thinking was lacking in success due to the lack of structure, and when compared to the Design Sprint one could say that Design Thinking could be seen as ingredients and a Design Sprint would then be a recipe, creating a step by step guide in how to use these ingredients (see section 2.3.7). The literature study also gave some valuable insights into when Design Sprints do not work (see section 2.4). This can be summarized in the following categories:

• Lack of information - When the team does not get the information needed to create a valuable concept and prototype

• Lack of understanding - Misconceptions that a Design Sprint can solve any problem in just five days.

• When the problem is not a product design problem - The Design Sprint is not a good process to validate a brand or a service design problem

• When a prototype can not be produced in one day - When the concept is too complex, and prototyping takes more than one day.

48 Further, the literature study gave insights into how the Design Sprint has evolved. The original Design Sprint spanned over a time period of five days. Design Sprint 2.0 is now four days long. This has been made possible by compressing some of the exercises in the sprint (see section 2.5). Section 2.7 gave insights into the possibility of running Design Sprint remotely with the help of collaborative online tools.

6.1.2 Interview of employees

To keep the integrity of the answers, it was important that the interviewees did not know that the project was about implementing Design Sprints. If the interviewees were to ask, “what is this interview about?“, they would be answered that it was about finding new ways of working. The people that were chosen were from various departments from the company. Seven employees were interviewed in total. A summary of the result of the interviews will be listed below.

• Usual workday - It is common to have a fully booked calendar and very much to do. This is mainly due to the company’s current situation of releasing their two first cars to the market.

• Productivity - The majority of the interviewees think that they are most productive when working with others. Meetings with lacking structure and planning are factors that affect productivity negatively.

• Development process - The general development process is considered good. There are instances where projects can lose momentum when the direction of the projects is wrong or have to be reiterated.

• Decision making - Making a decision is usually not so time costly. To get going with a decision can sometimes take a long time and can lead to lost momentum. However, the overall experience of decision making is good.

• Design Sprint - Most of the interviewees did not have any earlier experience with the Design Sprint process. When they were informed of the process and how Design Sprints work, everyone thought it would be an exciting process to test.

6.2 Designing

This section presents the results of the designing of the low, mid, and high-fidelity prototypes.

49 6.2.1 Low-fidelity

This structure was made by dividing the different exercises within the Design Sprint into separate artboards. The logic here was that all the exercises were to be done on separate artboards to mimic the “step by step guide“ that the book Sprint advocates. When all the exercises were integrated into Miro and different artboards, the work continued with trying to figure out the time stamps for every exercise and what exercise to fit into each day of the Design Sprint. The final structure was divided into different flows for each day of the sprint. Explanatory videos from AJ&Smart was added to every exercise to educate the team on how to do every exercise. This was done to get a better understanding of the process since Design Sprints are new for us as well.

50 Figure 6.1: Low-fidelity prototype

The image above is a screenshot of the lo-fi prototype in Miro. All the exercises have been divided into each day of the sprint. Day one, for example, has three exercises, then a lunch break, to continue with four more exercises.

51 6.2.2 Mid-fidelity

When the basic structure was set in the low-fidelity prototype, the work moved on to creating something more worked through and aesthetically pleasing. The goal of the mid-fi was to present all the necessary information in a user-friendly and straightforward way. Since Design Sprint is relatively new and not so well known at this time, there has to be quite a lot of explanation and extensive information before every exercise in order for the participants of the sprint to know what to do and be able to follow along. It is, of course, the facilitator’s job to inform and guide the participants through the sprint, but the participants need the opportunity to be able to educate themselves beforehand by going through the Sprint template, the prototype in this case, before entering a sprint. To achieve this, explanatory boxes were added that explained “What, Why, How“ before every exercise. This made it possible for the participants to read through every exercise to get an understanding of all the steps along the way. The structure was also changed from vertical navigation to horizontal navigation to make it easier to understand what exercise belonged to what day.

Figure 6.2: Mid-fidelity prototype.

6.2.3 Mid-fidelity test

To test the mid-fidelity flow and functionality, we sprinted through all the exercises in the Design Sprint using the mid-fidelity prototype. We chose a topic for the sprint and sprinted trough all the four-day exercises during one day. We got a better understanding of Miro and how to use the platform’s functionalities to create the best environment for the sprint. We also modified some of the “What,

52 Why, How“ boxes to make them user friendly and easy to understand as possible. We realized that we needed to include some kind of section for preparations that describes what has do be done before a sprint. This section would also educate the users on how to use Miro.

6.2.4 High-fidelity

With the learnings from the mid-fidelity test, we modified the prototype and created the High-fidelity prototype. A whole new section was added to the prototype that focused on the preparation part of the sprint. To enter a sprint with too little information is one of the main reasons why Design Sprints fail (see section 2.6). The added section explained what was needed to be done before starting a sprint. It also educates the users on how to use Miro and gives the facilitator some tips on what to do and think about during the sprint (see section 4.1).

Figure 6.3: High-fidelity prototype.

6.3 Testing

The prototype was tested on two different projects with two different teams. We ran two Design Sprints, which resulted in two prototypes. The participants in the sprints were later interviewed on how they experienced the Design Sprint process.

6.3.1 First iteration

This project aimed to find a solution for how to manage all the cars internally at Polestar. The department Commercial Car needed some system to keep track of all the cars and the information around the cars such as bookings, service, transport, and more.

53 6.3.1.1 Project

Project for Commercial Car to find a solution to how to manage all the internal cars of Polestar.

6.3.1.2 Team

The team consisted of 7 people. The roles of the people in the team were:

• two stakeholders.

• one Business analyst.

• one UX designer.

• one System Architect.

• one Manager of the Service design unit.

6.3.1.3 Result/prototype

The sprint resulted in a prototype created in Figma that we tested on test users during the last day of the sprint.

6.3.2 Second iteration

With the learnings of the first sprint, we modified the Sprint prototype slightly. These changes were most about design errors in the prototype, such as un-grouping objects that were not supposed to be grouped in the prototype. Due to the confidentiality of the second sprint project, it will not be further described in this paper.

6.4 Interviews of Design Sprint participants

This section will provide a summary of the answers to the interviews that were done after running the Design Sprints. Six interviews were conducted with people that took part in the testing of the Design Sprints. These interviews were done to validate the process as a whole and to get input on how to modify the process for the better.

54 6.4.1 Previous experiences with Design Sprints

Most of the interviewed participants had previous experiences with different kinds of workshops. Only one of them had done Design Sprints in the past, but not a four-day Design Sprint and not remotely.

6.4.2 Learning process

The majority of the interviewed participants thought the learning process was good. A few of them thought that it was somewhat confusing at times as they did not have enough time to prepare themselves before the sprint started. One person suggested that a short brief, explaining the process as a whole before the sprint started would have helped the learning process.

6.4.3 Understanding

Almost all of the interviewed participants thought that the exercise “Crazy 8’s“ was hard to understand and was also very stressful. Apart from “Crazy 8’s“, the majority of the participants felt like they understood what to do in all the different exercises during the sprint. One of them felt like it was a bit difficult to understand how all the things we did in the sprint would lead to a result.

6.4.4 Suitable for Polestar?

Everyone thought that Design Sprints would be very suitable for Polestar. They mentioned that the organization is very young and is therefore open to trying new things. Some said that the process maybe would have to be modified to fit the employee’s calendars better since it is common for people to have very booked calendars. However, the concept of doing something quickly, having something concrete to test, was seen as very suitable for the organization.

6.4.5 Voting process

All of the interviewed participants thought that the voting process worked well, but would prefer to have some additional time to give more room to process the things they were voting on. The voting felt a bit stressed at times.

6.4.6 Users tests

The user test that was done on the last day of the sprints was thought to be very valuable by all of the interviewed participants. It gave an excellent understanding of the idea that was being tested. What worked and what needed to be modified.

55 6.4.7 Improvements

The mentioned improvements will be listed below.

• Explain an exercise more in detail before doing the exercise.

• Before running a sprint, explain what the expected result of the sprint is.

• Explain every exercise clearly and why we are doing the exercise.

• Be even clearer on why the the different members of the sprint are part of the team.

• More time for voting.

• More time for lightning demos.

• Create a process to summarize the feedback from the users tests.

• Create different sprints for different scenarios.

6.4.8 Result of the sprints

All the interviewed participants were delighted with the outcome of their Design Sprints. Many of them were impressed with how much that could be done in just four days.

6.4.9 General experience

The interviewed participants thought that the Design Sprint process and what it resulted in was excellent. They liked that it was so structured, resulting in very high efficiency. They were impressed with how much progress one could make in such a short period. They were also pleased with having a prototype that could be tested on real users. Some thought this process would help the organization speed up the process of starting new initiatives, forcing the get-go and not standing still. The process would need further improvements to fit the organizations as well as possible, but the overall experience was that this process was something to continue working with.

56 Chapter 7

Discussion

This chapter will discuss the results and experiences of the implementation and running of the Design Sprint.

7.1 Result

The results of the two Design Sprints that were conducted proved to be very pleasing. Both sprints resulted in a prototype that was tested on test users. The prototype of the first sprint made it to further development since the user testing proved that this concept was worth continuing with.

The second sprint was not as easy going as the first sprint. The problem we were trying to solve in this sprint was more complex than in the first sprint. With the higher complexity came more uncertainty of the concept that we developed during the sprint. There was also extensive research done on this project before we did the sprint. One could ask if we covered enough of the research that had been done when running the sprint. The sprint maybe took to many shortcuts and missed valuable knowledge that would have been included if we would not have sprinted. This was the primary concern of this particular sprint, and we saw the importance of having a process for including earlier research into a Design Sprint. This is something that has to be further looked upon in the future. One could also ask if we had a clearly enough vision of the concept when starting the sprint. In section 2.6, it is explained that some sprints do not work due to different circumstances. Not being able to clearly state the vision of the concept is one of them. The complexity of the concept and the extensive research that had been done before the sprint maybe created a vision that was too broad. Maybe we should have divided this problem into sub-problems in order to understand our vision in a more detail. Despite the concerns of the sprint, we ended up with a prototype that gave valuable feedback from user testing. The prototype had some flaws that had to be reworked, but the overall idea of the concept proved to be valid and appreciated by the test users. This is one of the many strengths of this process. We failed fast and learned a lot, but managed to develop a concept that

57 could be reiterated and backed by user feedback. As described in section 2.1, if the solution did not work, the team now knows what to change and probably saved a lot of time by not taking this solution into further development.

7.2 Way of working

The overall impression from the people that were part of testing the Design Sprints is that we should continue working with this. Polestar wants to move fast, and this process is a great tool to make that a reality. There has been some difficulty in moving projects forward. Projects are being started but do not have the efficiency to continue moving in some cases. The Design Sprint forces projects to move somewhere, not always in the right direction, but then we have learned something from user testing and know what to change next. This is further explained in section 2.1.

The use of Miro made it easy to invite people since the platform already is implemented in the organization. And since everything regarding the Design Sprint is done in Miro, everything is documented and easy to access. Miro made it possible to run remote Design Sprints which showed to be very efficient and also proved that sprints does not have to be run in a psychical environment as explained in section 2.9.

7.3 Efficiency

The efficiency of this method is incredible. After the first day of the first sprint, some comments from the participants were: “it feels like we have accomplished more in one day of what usually takes weeks of work“. The structure of the Design Sprint forces you to be productive. It is exhausting, but makes fast progress. This correlates to Knapp’s realization, in section 2.2.5, that his most efficient work from his side is when being was part of projects with a limited time frame.

7.4 Usability

In order for the Design Sprint to succeed in the organization, it has to be easy to learn how to use it. The teams that were part of the testing did not have any earlier experience of Design Sprints, but that did not have any adverse effect on the result. Some users thought that some exercises were difficult to understand, but they understood the process as a whole. This shows that the prototype we created delivered the necessary information and education to be able to participate in a sprint without any earlier experience. This is the advantage with Design Sprints compared to Design thinking as explained in section 2.5. The step by step guide that the Design Sprint process provides is very helpful for people that does not have any earlier experience of Design Thinking methodologies.

58 7.5 Problems & further work

All the great results do not mean that the process is problem-free. As mentioned in section 7.1, there were some concerns that we missed out on important research that had been done before the Design Sprint when moving so fast. In the future, a system in how to include prior research into the sprint without losing the efficiency would have to be implemented. Regarding the testing and the data that is collected, there has to be a system in how to summarise the data. The user tests give much valuable feedback, and this feedback must not end up just in the Miro board of the sprint. The feedback has to be summarised and should follow the continuation of the development of the product. If there is no system for summarizing and processing the data, the continued development could be misleading. A section in the Miro prototype will be added that covers this in the future.

The Design Sprint may be a great solution to many problems, but it is not a “one size fits all solution“. There would have to be different kinds of sprints in the future, depending on what result you are looking for. One example of such a sprint is an even shorter version, a one day sprint, whose goal is to find a direction rather than build a prototype. By doing so, the range of this way of working could be more extensive and lead to improved efficiency within other phases of the workflow.

Future design changes to the prototype will be added to fit the brand of Polestar correctly.

59 Chapter 8

Conclusion

The objective of this thesis was to evaluate and analyze the Design Sprint process and how it could be implemented into Polestar’s way of working. The results of the two completed Design Sprints were very pleasing. The result and prototype of the first sprint achieved excellent feedback from the user testing. The stakeholders of the project approved the solution, and the prototype went on with further development. The second sprint, with a more complex problem, resulted in a prototype that showed some flaws during the user testing. It was clear that the prototype had to be modified, but we did manage to ensure the direction of the project as the concept as a whole was appreciated in the users testing despite the flaws. This lead to the reiteration of the concept and valuable knowledge from the user tests on how to continue with this product. The Design Sprint process has proven to be a very efficient method that can force projects to move foreward. The results of the sprint can vary as proven when comparing the first and the second completed Design Sprints. A result that leads to the reiteration of a concept does not mean failure. The process allows for failing fast and learning quickly. This is an opportunity to modify the concept after just four days of work rather than developing a regular MVP (most valuable product) for weeks or even months to realize that the concept does not work.

Implementing the Design Sprint into Polestar’s way of working was achieved using tools already established within the organization. Miro proved to be an excellent choice for building the structure for the Design Sprints as well as running and facilitating the sprints.

The process is not perfect and can be further modified to fit the way of working of Polestar. The reception of this process has been positive from Polestar’s side, and the work with Design Sprints will continue.

60 Chapter 9

Acknowledgements

9.1 Polestar

I would like to thank Anya Ernest and Christian Appelt for giving me the opportunity to do this project at Polestar. I have received fantastic support when working with the people within the organization, and I am impressed and thankful for the shown interest and involvement in the project. I want to thank the people that cleared their calendars to participate in the testing of the Design Sprints. Thank you, Christian Appelt for being an excellent mentor throughout the project and a special thanks to Fredrik B¨ackson for the help with developing and facilitating the Design Sprints.

9.2 Ume˚aUniversity

I would like to thank Fredrik Ostlund,¨ Petter Poucette, Filip Bark, and Martin Sj¨olund,who helped review this paper. I would like to thank my mentor, Per Kvarnbrink, for his help and great discussions throughout the project.

61 Bibliography

[1] H. Berends, W. Vanhaverbeke, and R. Kirschbaum, “Knowledge management challenges in new business development: Case study observations,” Journal of engineering and technology management, vol. 24, no. 4, pp. 314–328, 2007. 1/27-2020.

[2] S. F. Slater and J. J. Mohr, “Successful development and commercialization of technological innovation: Insights based on strategy type,” Journal of product innovation management, vol. 23, no. 1, pp. 26–33, 2006. 1/27-2020.

[3] J. D. McKeen, “Successful development strategies for business application systems,” MIS quarterly, pp. 47–65, 1983. 1/27-2020.

[4] Google Ventures, “The design sprint.” https://www.gv.com/sprint/. 6/7-2020.

[5] Polestar Engineered, “History.” https://engineered.polestar.com/se/about/history/. 1/27-2020.

[6] Polestar Performance AB, “About us.” https://www.polestar.com/se/about-us. 1/27-2020.

[7] Polestar Performance AB, “invitation-to-the-online-reveal-of-polestar-2.” https://www.polestar.com/press-release/2019/02/14/invitation-to-the- online-reveal-of-polestar-2. 1/27-2020.

[8] Polestar Performance AB, “This is polestar.” https://about.polestar.com/this-is-polestar/. 6/7-2020.

[9] Polestar Performance, “Polestar press.” https://www.polestar.com/global/press/press-release/polestar-1-enters-final- prototype-stage-before-production-start. 6/11-2020.

[10] Polestar Performance AB, “First car with google built in.” https://www.polestar.com/se/firstcarwithgooglebuiltin/. 6/7-2020.

[11] J. Knapp, J. Zeratsky, and B. Kowitz, Sprint: How to solve big problems and test new ideas in just five days. Simon and Schuster, 2016. 1/27-2020.

62 [12] R. Jarl, “Fast track to learning design thinking, lean startup, agile, pretotyping, and design sprint.” https://uxplanet.org/fast-track-%EF%B8%8F-to-learning-design-thinking- lean-startup-agile-pretotyping-and-design-sprint-f4badcd915fb. 5/31-2018.

[13] N. Cross, “Design cognition: Results from protocol and other empirical studies of design activity,” in Design knowing and learning: Cognition in design education, pp. 79–103, Elsevier, 2001. 4/2-2020.

[14] W. Visser, The cognitive artifacts of designing. CRC Press, 2006. 4/2-2020.

[15] J. E. Arnold, “Creativity in engineering,” SAE Transactions, pp. 17–23, 1956. 4/2-2020.

[16] L. B. Archer, Systematic Method for Designers: Technological Innovation: a Methodology. Council of Industrial Deisgn, 1969. 4/2-2020.

[17] W. . Associates, “What is design thinking?.” https://www.watsonassociates.nl/en/design-thinking/. 6/7-2020.

[18] S. Dee, “What is design thinking?.” https://www.youtube.com/watch?v=-hyVVdFobhU&t=312s. 3/3-2020.

[19] J. Ely, “Understanding the basics of design thinking will change your life.” https://medium.com/swlh/heres-how-design-thinking-can-change-your-life- 81873740f2ff. 3/3-2020.

[20] Interaction Design Foundation, “What is design thinking?.” https://www.interaction-design.org/literature/topics/design-thinking. 6/3-2020.

[21] IDEO, “Why design thinking is relevant.” https://www.ideou.com/blogs/inspiration/david-kelley-on-design-thinking. 3/3-2020.

[22] J. Courtney, “Why do design thinking projects fail?.” https://www.youtube.com/watch?v=QSCdU60LZbc. 3/3-2020.

[23] J. Courtney, “Design thinking vs. design sprint - what’s the difference?.” https://youtu.be/uvTTgCUNITI. 3/3-2020.

[24] J. Zalewski, “When a design sprint isn’t the answer.” https://www.invisionapp.com/inside-design/design-sprint-wont-work/. 3/14-2020.

[25] J. Knapp, “The three-hour brand sprint.” https://library.gv.com/the-three- hour-brand-sprint-3ccabf4b768a#.bhzj5jn9y. 3/14-2020.

63 [26] A. Østerbæk, “Why design sprints are overrated.” https://medium.designit.com/why-design-sprints-are-overrated- 3f0afdb0d0ea. 3/14-2020.

[27] J. Vetan, “The design sprint bubble.” https://medium.com/design-sprint- academy/the-design-sprint-bubble-dac51233b4ca. 4/1-2020.

[28] J. Courtney, “Design sprint 2.0 process explained 2018.” https://youtu.be/Z8MOwcqZuuU. 4/1-2020.

[29] J. Courtney, “How lego run design sprints at scale.” https://uxplanet.org/how-lego-run-design-sprints-at-scale-47bf56b785f7. 4/4-2020.

[30] J. Courtney, “From idea to app store: A design sprint case study.” https://uxplanet.org/from-idea-to-appstore-a-design-sprint-case-study- a7781093de8d. 4/4-2020.

[31] JustMad, “Remote design sprint template.” https://miro.com/templates/remote-design-sprint/. 6/29-2020.

64