My design sprint beginner mistakes
6 Mistakes from my first design sprint(s)
The last ten months —
The design sprint, if you haven’t heard, is a five-day process for answering big questions or problems through design, prototyping and testing ideas with users. The sprint was developed at Google Ventures — Mainly by Jake Knapp, Braden Kowitz & John Zeratsky.
Over the last 10 months I have taken part in a few different design sprints at Bosch Power Tools, as an intern, and in my studies so I won’t pretend I have a wealth of experience. What I do have, however, is a reflective nature that can spot where things went right, where things went wrong and what we could do to improve our design sprints as teams. I thought this post could be useful for people with all kinds of experience with sprints by highlighting the biggest 6 mistakes from my experience for others to avoid.
it’s a “greatest hits” of business strategy, innovation, behavior science, design thinking, and more — packaged into a battle-tested process that any team can use.
Design sprints have become a sort of a big deal and whilst some don’t see the value, others reap the rewards. They can and have been a very useful tool for small and large organisations alike, to quickly solve problems or validate solutions in order to bring products, features or better experiences to the market. Below is six mistakes I have encountered in the sprints I have taken part in.
1. How big is the problem?
Picking a problem for a potential sprint is essential to how the sprint will be carried out. If anyone is going to clear their schedule for a whole week then the problem needs to be substantial. I’m not saying you can’t carry out sprints for problems that are not substantial but you don’t want people to feel like they have wasted their time. Sprints are about learning — success or failure.
Perhaps if the problem isn’t a huge one consider an alternative? Use tools from the sprint to accelerate certain areas of your problem to get them out of your way for good. I have found that by taking the How Might We and sticker voting methods from the sprint our team meetings have become faster, more efficient and more importantly we all come out of the meeting with the same level of understanding.
2. Getting started and with who?
Recruiting for Sprints is tricky, not everyone has the time or the patience to clear an entire week, especially in large organisations where hierarchy is not as transparent than in smaller of design cultured organisations. One of the biggest mistakes in recruiting you can make is assuming design sprints are for designers, they are not.
When sprints lack key players with various experiences the outcome is always severely limited. With these different experiences there has been a lack of range of solutions in projects and whatever we did during the sprint seemed slightly flawed due to this limitation.
3. Starting after the end
Sometimes its easy to jump straight into sprints. You have your research, you want to collate it and find insights straight away but you can do this without making a sprint map, without asking key questions before you get started.
The design sprint encourages you to start at the end, to already know a potential solution for a problem and think of how you may get there. Before gathering insights, or even mapping out the project it’s important to ask “what has to be true for the project to succeed? or “Imagine the project fails… why did it?”. through questions like these, you can be sure to avoid potentially unwanted assumptions or mistakes.
4. How Might We do this better?
How Might We’s (HMW) can feel unnatural. HMW is a framework for a question or phrase to make the idea standardised for the rest of the team to understand. It’s important to generate these together, either from previous user research or the interviews on the ‘experts’ and then votes towards the most valuable ones.
One of the mistakes I have come across is that people tend to favour their own assumptions before seeing the research or going through the interviews so will always vote for their own assumptions instead of the realistic options. These assumptions at an early stage can lead you down the wrong path in the next few steps of the sprint.
5. X marks the spot but where was X again…
The sprint map is undeniably quite hard to make simple, we love to get carried away with complications and what-ifs? The sprint map, when done correctly, can be such a great tool to visualise insights or questions in specific parts of the user’s journey of a potential product or feature. It allows the whole team to pinpoint where exactly they want to focus on and by combining the power of HMW’s and the visualisation the map provides it’s a lot easier to move forward.
What I have seen time and time again is this map being completely missed. Maybe this importance of this part of the sprint is missed but by missing the map or scenario you are missing out on centring in on user pain point sta specific parts of their journey.
Here’s a great video that makes the sprint map ALOT clearer.
6. When you assume you make an ass out of u and me
Getting lost in your own assumptions can be a very common mistake in sprints, in fact, its what leads some to think they are a waste of time or not user centred at all. Someone mentioned the phrase “team centred design” when talking about design sprints before and although I disagree they have a really great point.
When sprints start without user research, background work or expert interviews the insights translated into HMW’s can be a little too assumed. Furthermore, the expert interviews are up to everyone in the room to be as unbiased as possible and perhaps without a neutral facilitator, it can become hard to keep track of a teams assumptions. This is because there can be some difficulty in assuming people in the organisation as “experts” when they are so connected to the brand they only see what they want.
It’s really important to stay on track and validate ideas in a user-centred way because if you lose sight of that then come to the end of the sprint all user tests are more than likely going to send you back to the start. (In hindsight its probably what we needed to happen at times, failing & learning and all)
My conclusion? Well it’s never really over but
With all of these mistake in mind, it’s perhaps important to mention that through my experience I have learnt that design sprints are not just for design. They are a tool for solving problems and validating solutions and can be used in a wide range of contexts. In addition, the methods and techniques used in a design sprint can be isolated and applied in different situations from problem-solving in meetings to making decisions faster.
