"Idea to prototype in five days." "Get to your goal in one week." Sound a little bit over-ambitious? It shouldn't be. We've been running Design Sprints with our clients for almost a year now and we've really come to learn the value in this new way of working. Sprints bring together the best people to build an even better product. Without the faff.
Harry, our Head of Product Strategy, and Will, our UX Producer, have been spearheading this new direction, and with no sign of them slowing down, we managed to find ten minutes to scratch the surface of what a Design Sprint can do for your product idea, whether you're a startup or a large and long-established business. Interested in our Design Sprint Campus workshop? Details here.
Harry, Will, what can a client expect to get out of a Design Sprint? Can you explain it for those who are new to the process?
Will: A design sprint is a five day process where you’re going to get invaluable insight into exactly what you want to achieve anywhere from six months to two years ahead. It’s a good opportunity to address any elephants that are in the room, so if there’s a problem, it’s a safe place to bring them to the table and find out how we can turn those problems into positive solutions.
By the end of the second day, we’ve all worked through and voted on a solution, and removed any bias or hidden agendas. The product owner can hear what the group are voting on and make the decisions around what to take forwards. Across the next 24 or 48 hours, we can create a prototype that actually looks like the final product. Then we can test, and that’s the most important thing. Many past projects that Harry and I have worked on have completely ignored user testing. You get so much good insight into whether it’s the right way to go or not.
By the end of the five days, you’ve answered the big questions like “can we achieve these long term goals?” and “can we achieve these short term goals?”, “are we getting the answers to our problems?” And we can ask three key questions: “Is what we’ve created desirable?” “If not, what changes can we make?” and “Do we really want to move forward?" Sometimes the answer may be to just park it. This can avoid spending months or years of commitment to a waterfall style approach only to find out that out of 100% of your investment, only 5% is effective.
So there’s every chance that a client could come back and say “This doesn’t work”, and they’ve only spent a week’s worth of time and resource, rather than months of their time and thousands of pounds, to find that out.
Harry: Yes, the key is getting the right people in the room, and to move them towards a ‘design thinking’ mentality. And that’s something you usually won’t get. The goal is a startup mentality. You don’t want three or four CEOs or directors in the room. Instead, you want the main product owner, and the right people surrounding them to help them to come up with the right answers to the critical business questions. That’s the kind of setup that allows you to test for market readiness in five days.
And how do you go about facilitating the room? We’ve all been in those meetings where everyone is trying to get their point across and has their own individual objective or bias.
Harry: Meetings can go on and on and on, meeting after meeting. I agree with what people say about having fewer meetings. We certainly shouldn’t get rid of them, but the aim is to have more ‘designed’ meetings opposed to just sitting around and chatting about shit. Designing this time ensures you’re not all talking over one another. Each person has their say and the outputs are of far greater quality. That’s why a lot of the design sprint is done in silence – to allow you to get your opinion down on paper before putting it up on the wall for a group vote. You avoid situations like someone pushing an agenda because the Marketing Strategist may be very opinionated, or the CEO is very passionate about one particular line of thinking. When you really listen to the wider team you’ll come up with a wider set of answers that are probably more sensible and more focused on what your product is. For instance, if you have developers in the room, you’ll absolutely need to listen to what they are contributing because they are bringing invaluable insight around the building of the product.
Design thinking is more than a set of tools or workshops. It’s a mindset, a full cultural shift.— Harry Ford (@HarryFord) June 20, 2019
Will: It’s understanding what the problem is that you’re solving and then bringing in the right people to solve it. The sweet spot is seven people; stakeholders, product owners, anyone who can contribute deep insight and knowledge. But these same people ultimately have the power to stop a project from taking place. Involving stakeholders early means that they feel they’ve contributed to solving the problem. It’s the balance of having the right stakeholders but not every stakeholder.
Harry: The CEO or product owner still has the final decision at the end. And they are still able to guide the whole process, but it’s just opening it up to a wider, specialised team. A lot of companies don’t have design, and this is where a design sprint can be especially useful. The facilitator allows you to be creative without you even knowing it, and this puts everybody on an equal pegging. But you are still allowing your product owner to make some of the final decisions.
Have you deviated from the ‘vanilla’ concept of design sprints to make them a little more ours? What’s the Kyan flavour of design sprints?
Harry: Yes, we have. We took some learnings from past experiences and from working with lots of other companies in consultation, design and innovation. We introduced our version of design sprints a year or so ago and we've been doing them full-time for about six months. During that time we’ve adapted them to allow us to get the best out of them. We want to be able to test real market readiness with a high-fidelity prototype within the five days. So we do two days of prototyping. We've also introduced what we call ‘problem framing’. This happens before the sprint and it ultimately means that we’re not spending any time on the first day of the sprint having to ask the expert about everything. By introducing problem framing, we have already started building a relationship with our client and have created out design sprints ‘problem statement’ to focus on before we've even started the sprint itself. A problem statement is invaluable to us now and that's our way of staying a step ahead – not only in the sprint itself, but a step ahead of our competitors.
Will: The book (Sprint by Jake Knapp) and the traditional approach will only touch very lightly on the problem at large before diving straight in to the sprint activity. Problem framing is its own dedicated workshop, and we spend no more than half a day understanding the client's business. By the end of the session, we understand them, their users and most importantly, what their problems are. Where we’ve brought in problem framing has significantly reduced all of the “what is the problem?” questioning in the sprint itself. The sprint should be geared towards and focused on “what is the solution?” not “what is the problem?”
Harry: When you speak to a lot of other design sprint experts, you learn that this is where sprints can go wrong. If you haven’t identified the right problem and the right user, then that’s where you’ll slip up either straight away, or when you try to release your product. Because you’re trying to fill an unclear gap with a product that has no market space.
Will: Being reactive to a situation that isn’t clearly defined is dangeous. Running a problem framing session beforehand means you can understand what the mid-level complex problems are. Simple or chaotic problems are an ineffective use of a design sprint's time; a simple problem can be resolved with a chat, a chaotic problem can’t be resolved in a design sprint. It’s like putting a piece of gaffer tape on a broken chair. It’s still broken, you’ve extended its shelf life, but it will only break again. It’s about making sure there’s clarity behind what the problem is, and how it is going to be solved.
Harry: Design sprints are just solution design. That’s how it should be spent.
Who have you worked with so far?
Will: We’ve been really lucky to work with a broad range of industries already; retail, construction, insurance, music, online storage, career development, healthcare...
Harry: Healthcare is in its innovation infancy. Seeing what is going on globally at the moment is so exciting. It’s such a huge market and there will be a lot coming out of that. Insurance is a massive market right now, too. Innovation is a big word there. I'm working with the Innovation Foundry at Zurich, helping run and teach design sprints, and there are a lot of exciting projects coming out of this space right now.
Our fourth Design Sprints Campus event is fast approaching. What can an attendee expect from one of these workshops?
Will: It’s bitesize pieces of information on how to run a design sprint and a great opportunity to take those learnings and see how you can start bringing the approaches and activities of a design sprint into your workplace.
You can’t just turn around to your boss and say “Hey let’s run a design sprint”. But bringing them to one of these sessions or taking back a clear, strong case for sprints and design thinking is what we’re hoping to help you with.
Harry: It’s a lightweight two-hour design sprint challenge. We squeeze days one and two into a workshop-style session and then talk through prototyping and user testing. As a group, you work out the most popular ideas to solve. Also you get some world class tips on Post-its.
Will: Don’t give it away, Harry.
Our Design Sprints Campus is on Wednesday 26th June from 4pm. Join us for a 90-minute workshop followed by food, drinks and networking. This session is usually £35 per person, but this one's free. Sign up here.