At Monese we run product design sprints whenever there’s a meaty issue we need to solve in a short space of time. Up until reading the book Sprint by Jake Knapp, we used to run what we called “sprints”, although we later learned that these were really just a series of normal design reviews in comparison to Jake’s intensive process. Having run some of our own sprints now I’d like to share our experiences in the hope this might help you if you’ve not already been running them in your company. If you’re not familiar with the sprint process, you’ll find everything you need to know here.
Why Sprint?
Whilst a design sprint can be an effective way of solving problems quickly and getting everyones buy in, I believe they can also help to spread the value of design within an organisation. There’s often an issue with the perception of design in some companies in that design is thought of as a “thing” or a service. People often understand design as being the production of an artefact such as a website, app, animation etc. The reality is that making the “thing” is just the last part of the design process, and what’s often overlooked is the problem solving phase.
“One thing about design is it’s really helpful to think of it as a mindset as opposed to a thing”
As product designers we’re in a unique position to help millions of users across the world, and even change cultures with the products we create. It would be wrong of us to assume that we’re the only people that can do this kind of work. Most problems worth solving in the world can’t be solved by design practitioners alone, there’s just no way we could be smart enough to do that. We need to make it our responsibility to involve and learn from others that don’t necessarily wear the “Designer” hat.
“I believe we’re past the era of the superstar designer, and we’re in the era of teams and collaboration”
Especially in a startup where you have a small design team, it’s not good to keep design decision making too close within the design team. By including the wider company in sprints, this should help to spread design thinking throughout the business. The problem with hoarding design too closely within the team, is that people can start to think you’re the only people capable of making creative decisions. This almost encourages others outside the team to not be creative because they’re not being encouraged to do so, which impacts negatively on the work and the team culture.
Before you start
Make sure everyone who’s going to take part in the sprint has read the book, including business execs. One of the common misconceptions is that you’ll finish the week with a product ready to ship. The book does a great job of explaining what you’ll get out of a sprint, and whilst this won’t be a finished product, it should be a clear direction with validated learnings.
Have some research done before the sprint. If there’s no time to do this before the sprint starts, at least try and make sure everyone does a little bit for the lightning demos on the Tuesday.
A cautionary tale from our very first design sprint was that we didn’t have enough information from one of our partners that we relied upon for a particular feature. Needless to say, the sprint ran like an absolute dream. The team really opened up as everyone sketched out tonnes of exciting ideas. It felt fun and loose, and everyone seemed to really enjoy the process.
We prototyped a super smooth happy path and tested it all with real users on the Friday. Everything seemed to test pretty much perfectly, and all the users we tested it with couldn’t wait to get the feature into their accounts. Once we discovered that there were some pretty heavy constraints we had to follow from our partner, we had to go back to the drawing board and re architect the flows completely!
Getting people involved
Sometimes people will shy away from the sketching part of a sprint saying things like “I can’t draw”. The truth is that you don’t need to be able to draw in a sprint. All you have to be able to do is get an idea down in some form. Sometimes it’s actually the people that can draw that are the worst at this exercise because they think too hard about the execution and craft of the drawing itself. Their energy and focus is diverted from the idea generation process so they lose a lot of time.
When sketching out ideas quickly for the “Crazy 8s” part, I find it’s best to fit ideas onto a small post-it note. The great thing about a post it note is that it’s so small and un-intimidating. No matter how bad you think you are at drawing, or how basic the idea is, anyone can fill a post-it note. It’s actually great to use a purposefully thick pen. This way, the line weight is so big that it’s impossible to make anything overly detailed! This helps to keep ideas nice and quick, and prevents overthinking.
Bring in the key players
Getting executives involved ensures that the outcomes are in the interest of the business. Where we’ve gone wrong in the past is when we’ve not had the executive team in the room, and we’ve had to re-do the work later down the line because the solutions weren’t in line with the business goals. This is a waste of resource and energy which only exacerbates the issue.
Also, if you interview a customer and the executive team isn’t present, it’s much harder to explain the findings of the test. If everyone’s involved in the testing and they witness things with their own eyes, they’re instantly on board with the findings.
Stick to the book
We found that once we thought we had the hang of the process we could start to cut the sprints short. When we first tried this, we found that we left the sprint with a half baked idea and a half baked agreement on what was needed from each of us. All this meant was that we needed to solve the problems again once we got closer to the feature release deadline. This was an allround more chaotic and drawn out experience for everyone and put pressure on the development and testing teams further down the line.
If you feel it’s going to be difficult to sell in the idea of design sprints in your company, try to position it as a small experiment to leadership. This should help to take the edge off the idea and make it seem more approachable. Follow the book by the letter, especially for the first sprint and evaluate how it goes. Make everyone aware you’re going to be stuck in a sprint for the whole week as you’ll need their full attention. Get enough snacks!
When not to sprint
If you already know exactly what you’re going to make, and you’re not willing to change that plan, there’s not much point in running a sprint. We started one of our sprints when it was quite prescriptive what we needed to do. Having gathered most of the team, including execs, we later decided to speed up the process and cut the sprint short. This was a shame as we felt it was a bit of a waste to book calendars out for the week only to drop it, and we also worried it might cause people to lose faith in the process.
“If you want to be innovative — if you want to do something that’s truly different, we have to understand that we don’t know where we’re going to end up when we start”
A big part of the sprint process is about bypassing HIPPO problems within an organisation and creating an environment where great ideas rise to the top even if they come from the quietest voices, so do your best to be open to this ethos from the start. The process of the sprint should be a collective digging into the problem and discovering the needs of the customer, and from this you can only then move on to find the right solution.
We’re fairly new to the official sprint process at Monese, so if you’ve been running them in your company we’d love to hear more about your experiences.
Enjoy your sprints!
Watch the presentation from Digitized17 to learn more about Monese design.
Joe Allison is Monese’s Product Design Lead. This is the second instalment in a recurring weekly series from the Product and Engineering Team @Monese.
