The design sprint: the best tool for solving tricky problems in a team
I joined Tanda a little over two years ago as designer, since then we have released lots of features in the product, and in doing so, learnt a lot about what a really good product process should look like.
One of the biggest improvements we’ve made to our process, as obvious as this may sound is to have designers work in teams to nut out those big tricky problems rather than trying to tackle them on their own.
Once upon a time we would have a designer working on a problem on their own, and once they were happy with their solution they’d present it to the team and get feedback from other areas in our business, such as sales, support and product. Often this would result in lots of things that we hadn’t really thought about being brought up, or new aspects of the problem being brought to light that we hadn’t really considered. This isn’t really a very effective way to build software.
The much more productive way is to collaborate with others, particularly those who are closest to the problem, and have the best information needed to solve it. Different perspectives and creative ideas are always going to be better and you will end up thinking about all the sneaky gotchas that might have tripped you up if you’d tried to work on it alone.
Unfortunately though, trying to solve problems with a group of people often ends up in lots of meetings and lots of pointless debate that can derail any real progress on the way to a well-rounded solution. This can leave you feeling discouraged from collaborating with others and opt for the solo approach.
Introducing the design sprint process
We were introduced to this thing called ‘the design sprint’ by Kelvin, a designer in our Growth team. Conveniently, here is Kelvin explaining what the sprint process is:
Kelvin and the Growth team led the way in introducing sprints at Tanda and now we are using them all the time.
The part that I like best is that it forces you to really understand the problem you are solving before moving to a solution, something that can often be glossed over a little too easily. It also enables you to approach old problems in new ways, throwing away old assumptions that are probably not true anymore.
A recent example for our team was redesigning the way our leave and unavailability features work. I’d heard a lot of different opinions on how these features should work, but it was really hard to try and come at the problem with clarity until we ran a sprint and had other people involved. We ended up re-imagining the way time off should work so it both accommodates what the business needs, but is also fair and transparent for their employees, read about it here.
As you can probably tell, we really like this process. So much so that we’ve made a video about it and are hosting a one-day workshop to teach it to others.
