Here's what you'll learn in the webinar:
Want to generate and validate product or service ideas in just one week to create innovative and efficient solutions? In our webinar, UX expert Olaf Helmig shows you how this works with the Design Sprint method. The webinar will answer the following questions, among others:
What is a Design Sprint?
What does a Design Sprint look like?
How do I optimally prepare for the Design Sprint?
How do I conduct a Design Sprint?
What are the results of a Design Sprint?
Watch online now (German only):
Jetzt Webinarfolien downloaden:
Transcript of the webinar: Design Sprint
Angela Meyer: Welcome to today's diva-e webinar on the topic of Design Sprints. And today you'll learn from our UX expert Olaf Helmig, among other things, what a Design Sprint is, how he carries out the method and what the results are. And now we'll start with a short round of introductions. My name is Angela Meyer, I work in the marketing team and I'm your moderator today. Olaf, let me turn the floor over to you and please introduce yourself.
Olaf Helmig: Thank you very much Angela. Wonderful. Hello to the group. I'm Olaf and I'm 40 years old. Very briefly about me: I studied graphic design and multimedia design around the turn of the 2000s, I was born in East Westphalia, which is around the corner from Bielefeld. Perhaps the highlight is that I lived and worked in Asia for eleven years, ten of them in China and one year in Bangkok. And I've been developing digital solutions for 17 years now.
So welcome again to today's topic, Design Sprints. Briefly about the agenda: I'm going to take a very quick turn, where did it come from, who invented it, how did it come about maybe and then get right into the agenda itself. Briefly tell something about each individual topic, methodology, each individual game. Bring in again a few experience treasures. And then, of course, at the end I'm looking forward to your questions. Very briefly on the topic of what a Design Sprint actually is.
What is a Design Sprint?
A Design Sprint is ultimately an innovation method. It is more or less a best-of. It is an optimal mix of Lean UX, partly from Design Thinking, from business strategy, from innovation research, behavioral research, and so on. So there's a lot of potential in a design sprint. We have the word design, which has more of an artistic bent, and the word sprint, which comes more from agile product development. The bottom line is that it's a time-limited framework.
Both together is really how can you create an idea in a short time, bring it into life and really also test it to see, are we on the right track or not. Who developed it? Back in the day between 2008 / 2012, by Jake Knapp, John Zeratsky and Braden Kowitz, they were at Google Ventures at the time. And they developed stuff for Gmail for the Inbox back then, or just also for Google Search, among other things.
And the whole thing just came into being, because they needed a structured approach to really get from A to B, to really pick up the developers, the project people, as well as the designers, so that you really have a goal in mind. And Sprint already existed, so they put the word Design in front of it. That's how the Design Sprint came into being. Here again is the link to, let's say, the original. The original Design Sprint, so as we've seen it here, it says "Solve big problems and test new ideas in just five days." So that was the marketing claim. And the whole thing looked like this.
Design Sprint planning and process
Day number one, it was really about understanding the problem, where the shoe pinches.
Day number two, then to really start sketching out the first ideas, which are then born
day three, and then just deciding on one of those ideas to expand on.
Day number four, to then prototype the whole thing and finally and finally test that with testers on Friday, which is the end of the Design Sprint week.
At the end of that week, the result is really, O.K., we figured out a lot of things.
Are we on the right track, yes or no? It really provides first quick results to just say, well, that was all cheese now, we can forget about that completely or we are really on a hot track now, we found out a lot of things and then we move on. That's also a good transition. Let's go right into the design sprint agenda.
One thing up front, I'm sure many of you on the call today are already familiar with Design Sprints, the methodology, may have already looked into it, may have even facilitated a workshop or two themselves. What I have often seen is that many of these design sprints, i.e., just according to the motto five days, we get an idea right, four days, we get a tested idea with users, the problem really lies at the beginning. You need a so-called kickoff workshop, which is usually at least two weeks before the actual design sprint.
With the decision maker at the same table
This workshop is really about sitting at the table with the customer, i.e., decision-makers on the customer side, to really define the framework of this Design Sprint. That means that on this day, which is about three to six hours, we really sit together. It's about unpacking everything. Where is the shoe pinching? What are the business goals? Which target group, i.e. which target group segment, are we talking about? We really define all these things together. We also prioritize them in order to have something really solid.
Of course, the actual sprint team can be set up from this date, i.e. who do we actually need in this design sprint and of course that we also recruit the users who should later test this prototype. I deliberately say that this has to happen at least two weeks before the actual Design Sprint week, so that we really have enough time internally to prepare for it. We all know that not everyone always has the time and resources to attend such meetings, to really come to the table. It's really difficult to get all the decision-makers around the same table. And through a so-called kickoff workshop, we have narrowed down this problem, I would say. Everybody can take time for it and create time for it, so that you really have the important people at one table. Now, if there is no, let's say, high management, C-level decision maker can be there, there is of course always the product owner or the project manager depending as a deputy, who of course then has to make decisions as a decision maker. And that is very important. I emphasize that again and again. For every design sprint, there must always be someone on the customer side who can really make decisions, because without this, we really can't develop a product, we can't make a decision.
The testers at the end would then contribute less to the actual strategic development of the problem or the product. Actually in the design sprint day number one, that would usually be a Monday morning. You meet as a team. You get together. What do we need for that? A room where we can all find each other, which is booked exclusively for this Design Sprint team for at least one week, so that you can just leave your materials. Materials, we have post-its, we have pens, we have smaller dots just for voting, food, drink, everything that just goes with it to create a good atmosphere. There have to be enough lights et cetera. So at the beginning, day number one, it's really about getting to know each other and understanding each other, whether it's getting to know each other a little bit more in the team, but actually we really focus here on the framework, on the so-called design challenge that we set in the kickoff.
The Design Challenges
Likewise, which target group or which segment of your customers are we addressing with this? Where are the needs? Where are the problems? We always start with a so-called ice breaker. This means that we sit around a table in a normal and relaxed way, look at each other and then the moderator usually starts an open dialog with the decision maker. Tell them what your product is, what it can do, what problem it solves, what added value it provides. And simply by this open dialogue, the other participants start to move into this world. That usually takes a good quarter of an hour, I always say.
Design sprints, also very, very important, I may have just forgotten this in the materials, we need a timer, of course, so somehow a stopwatch, because most of these activities are all so-called time-boxed. If we say 20 minutes, then it should be completed within 20 minutes. And that's of course how it is in the beginning we first introduce all the rules of the game, then we get into this open dialogue. And at the end we go into the first so-called expert interview, these so-called how-can-we questions. Here, everything really revolves around defining the long-term goals of this product or service and, of course, the obstacles, that is, defining long-term goals optimistically, very idealistically. That is, O.K., where do they see their product or service in 18 months, in 24 months, if they really had infinite resources available, if everything is going great and is really ideal? What is the main goal? Each participant is asked to write down individually on a post-it within five minutes, O.K., I could imagine that as a goal, I could imagine that as a goal.
At the end of these five minutes, each participant stands up and places their post-its on the wall. And then it goes into the so-called dot voting. That means you simply have your little dots, which you can stick on these post-its. First it's the team's turn, and at the end of this round it's the decision-maker's turn.
The decision-maker always has a different color for his dots so that he can be clearly identified. And I'll put it this way, the advantage for the decision maker is that the decision maker always has a veto. The decision maker can completely oppose his own team or he can of course say, well, this is exactly the goal that we support from the business level and where it should really go. We have already defined the long-term goal for number one. We then turn the game around again, five minutes, now think pessimistically and realistically, what are the hurdles, obstacles to achieving this goal. And everyone writes down, let's say, three to five problems or hurdles, obstacles on a Post-it. Same game, we put the post-its on the wall. Then the dot voting round comes again. Everybody has, O.K., this is a problem, which I think is good or where I'm behind, where I know this is going to come. And we end up seeing a pattern before.
What's important here is the higher the number of dots on the post-its, the higher this issue is prioritized. Through this, at the end of these first two rounds, we have then defined the long-term goal very idealistically, very optimistically, and on the other side really top 3 hurdles, obstacles, problems that can stand in our way, also defined. That's where we really get into this world, how do we get from today to a successful product.
Map-The-Map
The next step in the day a so-called Map-The-Map or simply The Map. The bottom line is imagine this is a Super Top Level Customer Journey. This should also be relatively quick, so a maximum of 20 minutes. You imagine on the whole left side comes a column with the actors, that is, from our target group. Maybe there are different segments. But maybe there is only one actor. They just define there, O.k., that's maybe as an example "Björn", Björn is just looking for a new leasing vehicle. That is, he would be on the left side as an actor. On the far right side, we define the target.
Target definition, an example
What is the goal? He wants to lease a leasing vehicle now. And in the middle goes about discover, find, use. That is, discover is mostly the same thing in green via social media, via email campaigns, via Google. Very simple, you just put it down what pops into your head. Finding is exactly the same. I search for a leasing portal via Google. I find it. I click on a link, I'm on the actual website. Step three would be use it. Okay, so what am I doing? I'm searching for cars. I'm comparing cars. I'm picking a car, then really getting there, I picked a car. I put in the configuration. I have requested an offer. Now I can lease the car. Very, very simple. You should really lose very little time on it. It's all super top level.
And at the end of the day you should lose certain extra time on it, that's the so-called four-part sketch. Each of the participants just take a close look in the room at the individual things that are already on the wall, write down some notes, start making some initial scribbles. Now in this idea of calling this leasing portal, let's say, into the world, let's say, well, this is a digital product.
Layout & Prototype
We're already starting to make first scribbles for a layout for example. Crazy 8 is also wonderful. Some of you may already know it. You simply take a sheet of paper, a DIN A4 sheet, and fold it four times so that you have eight rectangles to sketch an action route, a click route, a user flow from A to B down. Everyone does those individually on their own, of course. As a rule, I always say that it should be a 30-, 45-minute unit, so that at the end of day number one, everyone can really focus on the long-term goal, visualize the problems that arise, and then really create a first prototype concept. This is then laid side down so that everyone, so no one can peek, so that you can then go home.
On day number one, of course, I usually send the participants home with a homework assignment. Do I say, "Well, please look around the world. Is there an alternative product that already exists that has solved this issue?" Pick one thing. It can be industry-unrelated, whatever. It's just a matter of everybody giving it some more thought, putting in another half hour at home looking for something so that we can really launch on day number two, Tuesday morning, when we all come back into the room with all the concepts still covered up on the tables.
The so-called ice breaker number two here would be product demos. That is, from the homework assignment, hopefully each participant has a product that is an alternative to the actual problem we're dealing with and just presents those. Imagine it's Tuesday morning, you have a coffee, you have a roll, a croissant, I don't know, you're sitting at the table and you can let yourself be inspired a little bit. That's what it's all about. You see other products that have solved the same problem, how did they do it? Just to say, well, that's the highlight, that's the lowlight.
And day two is all about conceptualizing and deciding. That's really what it's all about. That means that we start here after the product demo, which should last about half an hour, it's really about each participant revealing their concept from Monday, hanging it on the wall and briefly saying something about it. This is really relatively quick according to the motto Heat Map Votes, Speed Criticism and Super Vote. What does that mean? After we have hung our concept on the wall, briefly O.k., that's so, explained the Big Picture, after we have all been in turn, it's really about here that everyone uses his points to vote not sparingly, but completely wild. So you should kind of really place all the million points you have somewhere here.
Everybody knows a heat map. That is, practically you just see the click behavior of people, where are simply agglomerations. And here it's similar. Each participant places not just one, but at least five to ten points on some aspect of a concept, be it a functionality, be it a layout, whatever. And at the end of that, which should also run or take between five to ten minutes, you really see a pattern. That's a functionality or the layout, most people like that, that could really help us on this problem. Then it goes into a very quick round of criticism, where you simply say again, yes, no, yes, no, so really very briefly has a brainstorm quasi, does it really fit so to the defined long-term goals or also do we really get over the hurdles that we have defined. And the so-called super vote, that's where the decision maker is asked, of course. And then he chooses one thing. He says, OK, this is really a concept or a functionality, I'm fully behind it. And when I say one, of course it's not just a dot vote from the decision-maker, but he can simply pull together two or three things, so that you can see that we said at the beginning that a Design Sprint is an optimal mix, and here it's really like that. So we just mix, O.K., what are the individual elements, where we are behind it to say, well, this is really going in the right direction.
User Test Flow
The User Test Flow, one of my favorites, a super activity. Each participant has six little post-its to map out an action route, a user flow. In other words, where do I start and what is the goal? If we take up this leasing offer again, that would be, okay, the user is on the page and he first searches for his car. Then comes somehow compare, configure et cetera pp, talk again with the customer service somehow. And at the end, of course, the user says, OK, I really want to lease a vehicle. That would be the goal. And within these six post-its you tell the story. That's also a 20-, 25-minute unit. After that, everyone really puts it on the wall among themselves.
Then we see that action line one was from Thomas, action line two was from Kristina, etcetera, etcetera. Of course, everyone who has created an action route presents it to the team, every step of the way. Everyone listens to it. And in the end, it's really up to the decision maker. And here it is that he has to decide on an action route. Of course, he has a second point, a dot-voting thing, where he can adopt a post-it from another action line, because he says, well, I think that's so good, it has to go in there. Again, user test flow, that's all from an eagle perspective. So this is really all macro.
But this is super necessary to just really fire up the last even the biggest portion of day two. This is what's called storyboarding. Based on this action track, we then start to depict, let's say, six to eight layouts or how do you say, steps. We do that together. That is, we have a slightly larger A3 sheet where we start really sketching out the layout together. All the things that we've already found, where we agree that it's going to get us to the goal, we really let them flow in here, so that at the end of the day-. So this storyboarding alone is always about two to three hours, not really longer but not really shorter either, because it's really about getting the most or as detailed as possible so that on day three, when it comes to the actual prototyping, the developer doesn't just stand there and say, OK, now I see everything, but there's something missing.
Of course, in the best case, you always have a developer with you in the design sprint, so that such gaps can't occur at all. On day three, the customer is out again for the time being. So here's really diva internally, where we sit down with our designers and developers in what's called pair design or pair programming, to just bring the imagined, created prototype from storyboarding into life. How high, how low the fidelity should be, that's of course all determined beforehand, so saying that it just really has to be super visual or super technical, that just the behavior of this prototype has to be somehow very close to the final product already, that's taken and determined from the kickoff workshop and at the beginning of this design sprint week.
On day number three, we're really diva-e among ourselves to just bring things to life, which then of course form the basis for day number four.
Usability Test
On day number four, we recruited users that we set in the kickoff workshop. They're then there. And here, of course, we usually invite the customer again, so at least the PO, the decision maker. He simply comes in, because it's super important to just watch and listen to how people use their product. That simply has so much value. You can quickly get into a dialog like that. And of course we moderate it. Of course, we conduct this usability test, including the interview with the individual participants. I'd say it's a good size, especially because design sprints are so compact, so there are always eight to ten people testing. You can somehow pull this off in the morning. Then, after the lunch break, you have time internally, I'd say, to evaluate the things we've found a bit more, to simply create an initial test report and then simply say, well, what have we found, what haven't we found.
And that would really be the end, I would say, the review at the end of this Design Sprint week. Whether you can somehow pull it off on day four, on Thursday, or whether you have to go back into Friday, of course, depends on how many resources you really have and how exhausted you actually are.
End of the Design Sprint
And at the end of the Design Sprint week, it's simply a matter of presenting the test report and then making recommendations for strategic further development. It may also be, because it is of course also a very agile method, that what we wrote down as an assumption, hypothesis at the beginning as a challenge, that it was complete cheese, that the product just doesn't make sense. That can also be the case, of course.
But as a rule it is really like this, and this is also from experience, conditioned on the basis or the project framework from the kickoff workshop to the end of the first design sprint week, it is actually like this that we can really confirm many hypotheses and get this validation and that we then say, now it really starts, we need more resources, we need a larger team, that one really enters into this agile product development. And of course, when we look back, all the important stakeholders are there again, so at least the decision-maker on the customer side, but generally, of course, a few more people. If it's really a customer-focused product, then of course those from customer support will also be involved. As you've already heard here, design sprints are short, crisp, and packed with life.
There are so many things that come out of them that you should keep in mind and that you can prioritize in a design sprint backlog. But it's important that there is this kickoff to simply narrow things down, because without that, it doesn't work at first. And that's from experience, I've seen it too often that such design sprints really can't keep up with the four or five days of tested prototypes, simply because it was too far apart. That would be my presentation for the Design Sprint. And then I'll try to close this here and just give it back to Angela.
Angela Meyer: Thank you Olaf for your insights on the Design Sprint method. We will now start with the Q&A session. And you're welcome to ask your questions now via the question box. And in the meantime I would also like to start a short survey to the participants to know if you are already using this Design Sprint method in your company or if you are just getting to know the method. I'm going to show you the survey now. And now I would like to wait here for a moment to see what comes in. And you have the time to ask questions and Olaf will be happy to answer them. It looks like most of you are already using the Design Sprint method, more than half.
Olaf Helmig: Very good.
Q&A
Angela Meyer: Then I'll close the survey again. A clear sign, about 70 percent are already using the Design Sprint method. Now I'm still looking at the questions.
You mentioned that there should also be a developer.
Which departments are important for them to be involved?
Olaf Helmig: Of course, it depends on the context. But in general, I would say you need an experience designer, or at least what we define here as an interface and interaction designer, who should be there to simply bring a bit of expertise from this area. We de facto need a developer. So I always take a developer with me, quite simply to, let's say, bring the technical limitation to the table in advance, very important. And then it depends on the context. So usually I also have a project person, a project manager or a product manager with me and the same from the customer side. So on the customer side, there is always a minimum of one decision-maker, but it's always a good mix that there are two or three, maybe one from IT, maybe from marketing or from customer support, which is also very important. So, when it comes to validating or creating a product or a service, where people can really, let's say, gain added value or solve a problem, the person from customer support should of course be there, because he simply has the most experience.
Angela Meyer: I would now like to take up the next question.
Is the decision maker, PO, C-level, also allowed to work on the ideas in the first phase or does he only evaluate these ideas?
Olaf Helmig: He is an active part. Well, that's always very funny, because here Mister Decision Maker, there Post-it and a pen. Many people are averse to that, but that's one thing. The more experienced you are as a moderator, the easier it is to pick up the decision-makers. And clearly, he's sitting in. So it's just as much this insight that you have, that the people who are sitting at the decision-making level or the deputy, that they can really dive deep into the subject matter.
Angela Meyer: Okay, thank you Olaf.
Now the question here is, which tools do we use to create the testable prototypes within one day?
Olaf Helmig: Depending on the context. Well, that's what I was talking about with the fidelity in good German, so depending on the context, it has to be strongly content-based or visual or behavior-based. So you can choose between Sketch, Invision, Figma, you name it, depending on what you already use in-house, that can work. The important thing is that you really establish that ahead of time. So usually, when I say on the third day that we're going to create the prototype, we just bring developers on board. That means that we really do build software prototypes, i.e. in HTML with CSS and JavaScript. And they are very fast. We have, I don't know, React and Vue or whatever framework we're using right now, just to make these prototypes fast.
Angela Meyer: It is of course the case that the decision-makers usually don't have too much time or don't want to spend too much time.
Would it be conceivable that the decision-maker would only be involved at the end and only the results would be presented to him?
Olaf Helmig: Absolutely not. This is clearly defined in the kickoff. In the kickoff, we sit down with the customer and someone from the decision-making floor. The customer has to name a deputy. And this deputy must be anchored in this design sprint. He can't just walk in and walk out. That simply leads nowhere. And as a rule, I've done three or four such design sprints here for diva-e in the last two or three months, and it's just like, okay, it's just a bit like, how can you best spread it out? And as a rule, it really is the case that we then also send these people for two days, which is why we also say that Mondays and Tuesdays are such a full day, they are there. And then they come in again during the testing. That is an absolute must. And I would also say that every budget provides for at least a deputy who actually makes the decisions, because if the decision-maker or the deputy only comes in at some point, it doesn't lead anywhere.
Angela Meyer: We now have another
question about the sprint process
Olaf Helmig: In general, what I just said, this is just one day, we are diva-e among ourselves. Pair design, pair development, you can already hear that there are at least two from each discipline, i.e. two from the design area, interface, interaction area and two from the frontend area, because we need less backend at this point. And what the whole thing will look like. We'll talk about it again. We'll go into more depth from a design or experience design perspective. A few things will then be put right. And from the development direction, of course, we still say, okay, maybe we can't implement it technically like this, maybe we have to find a workaround or something. But the important thing is that a small team of three or four people works together on this prototype and actually completes it in one day.
And in the best case, as it is with us at diva-e, we naturally have a so-called diva-e UI kit, which means we never start from scratch. We always have something in our repertoire where we can get design solutions off the ground very quickly, because first of all it really is a tool to solve a certain problem, to create a certain added value. And then, of course, comes the expertise of our front-end developers, who then simply bring the prototype to life via certain frameworks. And the more content I need, that's just this fidelity that I always say, there's not just medium or low, medium, high, but there are four different categories, so content, visual, contextual, and behavior, where you play this fidelity the same way. And depending on what kind of materials and what kind of content we've been provided with, of course they're reflected in this prototype. Does that answer the question?
Angela Meyer: Yes, exactly. The participant wanted to know again what exactly we are planning and doing on that day. And I would now also go on and introduce our contact person or her contact person, Guido Juchert. He is our sales manager. And you are welcome to contact him directly by phone or by mail. And he is definitely open for all your questions. And he will be happy to discuss the topic of Design Sprint with you in more detail. And again, we will make the presentation and the recording available to you afterwards. A quick note about our other webinars. As I said, we will be holding weekly webinars with partners and customers on the topics of SEO, content and design, and we look forward to your participation. And you can just drop by our diva-e newsroom and register there.
Angela Meyer: Thank you Olaf for your time and for your insights on the Design Sprint. It was definitely very exciting. Many questions came in. Thank you to the participants for your time as well. And see you next time.
Olaf Helmig: Thank you very much. Have a nice day.