This post was originally published on Brandwatch's main blog on 15th August 2014.
A couple of weeks back we ran our first full-fledged design sprint. We sketched, brainstormed, wireframed and storyboarded and discovered many new avenues to explore but also learnt a lot about running design sprints themselves.
In the engineering department we work to constantly to fix bugs and develop new features so as to improve the experience that you have with Brandwatch software.
Once in a while we break away from this and try to do some big picture thinking.
What would be new features that our users could benefit from tomorrow? What novel approach can we use to solve this problem in a more elegant way?
Design sprints help us do just that.
What is this ‘design sprint’ you speak of?
Design sprints are an application of design thinking into a scrum-like sprint that enables you to combine creative thinking and problem solving under time pressure.
Design sprints were developed at Google Ventures and have been successfully used within many companies to solve design problems. The sprint consists of roughly 5 sessions that align with each step of the design thinking methodology.
The Steps of a Design Sprint
Before everything kicks off, you need to get all the people and things you need. Gather up all the (whiteboard) markers, paper and post-its you can find and block everyone’s calendars. Also set up user tests in advance as this puts the pressure on!
We chose to run the sprint over a two week period and involved the Head of Product, Head of Frontend Engineering, another Product Manager and myself as the UX Designer.
In the first session you dig into what the problem is that you’re tackling. What is it that is really troubling the user?
You look into business metrics and analytics, do competitor analysis and run interviews. Using all of that you set up a metrics that will measure the success of your design.
Then you start to develop solutions, thinking of as many as possible without criticizing them (yet).
You evolve the most promising solutions until everyone has one or two potential solutions storyboarded out. At this point you critique the solutions and vote on which parts of each solution seem most useful.
Taking all of the solutions from the previous session into account, you look for differences in approach and decide which seems best.
You won’t always have enough information to make an informed decision, which means that you will have to make assumptions. You can keep track of these assumptions and test them in your prototype.
You’re now ready to start building.
Depending on the amount of time you have available and your own personal preference, there’s a whole range of ways to build your prototype.
We chose to use Axure, as we use it in our design process on a daily basis and are familiar with it.
Whatever you choose, the most important point to remember here is that you want create the amount of fidelity that validates the prototype with the least amount of effort.
As a last step you run user tests with your prototype so that you can assess if you’re proposed solution is an answer to your design question.
We chose to do this in a very open manner.
We first went through a use case that I had created and then discussed the concepts behind the solution in a more general manner. This gave us both insight into the actual prototype and how the broader concepts would fit into a persons workflow.
Results and Learnings
The whole point of design thinking and all agile methodologies is that you learn and iterate continuously. Here are three of the things that we learned about design sprints that we would strive to do better next time.
1. Prepare well
We started the whole sprint with a discussion on which challenge we wanted to tackle. This made hindered preparation as we didn’t know ahead of time who could be interviewed or which analytics data would be best to look at.
Deciding which design problem you want to solve ahead of time puts everyone in the correct mindspace.
2. Keep everything in one room
The idea of a design sprint is to visualise everything and put it all up on the wall, so that you don’t have to keep it in your head.
We didn’t have a single room available to us for the duration of the whole sprint which meant that we had to move our post-its, and sketches from one session to another. This was a hassle that cost time but also, it stopped people from coming back into the room outside of the session to browse through everything for inspiration.
3. Block large amounts of time
In the same vein of not having a single room for the duration of the whole sprint there were calendar constraints.
We ran overtime on the decide session and we thought we only a little extra time to finish up. But having broken up the session that extra session turned out to be significantly longer as it took us some effort to get back into the flow.
We generated an unbelievable amount of ideas and thoughts on how to improve our product.
We also came up with a very innovative solution to a problem that we have been thinking about for a while. It’s quite out there, so we might not be able to implement it tomorrow, but we now have an event better vision of the direction we want to be heading. This enables us to put stepping stones in place to get there.