Design Sprinting
At ResDiary, we are trying to become more focused on Design Thinking, a concept popularised by David M. Kelly of IDEO fame, founder of IDEO. From what we can see, the easiest way to try that out is to experiment with the ideas and techniques in the Design Sprint book.
The concept of a “Design Sprint” simply condenses and focuses design centred collaboration and problem solving into just 5 days. That’s totally end-to-end, too, including some user testing. The kinds of problems can be medium to very large. The bigger problems are usually better fit, as there’s more to get your teeth into.
Since it was our first attempt at this new process we decided to try and condense it into 2–3 days, rather than the whole 5; call blasphemy if you like and read on for the results.
In the 5 days you:
- Explore the problem space, and try to specify it by agreeing goals and mapping it out.
- Allow individuals to sketch their ideas in a controlled and timed manner. Keeping track of time is really important. As you are trying to achieve a lot, and people easily get side-tracked with conversation.
- Gather ideas on how other companies or individuals have solved similar problems.
- Design Sketches — where many different techniques for rapidly producing designs are tried.
It might be crazy . . .
But we actually experimented with running two at once. We recently adopted a team split based on the kind of task, rather than specific areas of ownership or technologies. Thinking here is that it would be easier to move towards cross functional and self organising teams. One team focuses on small improvements, the other, larger new features. The split might not work longer term, but it’s a starting point.
Day one (actually contained days {1,2,3} )
Yes, so, rather adventurously we decided to tackle days 1 2 and 3 from the Design Sprint book in one day. Squeezing things in like this wasn’t ideal, but since this was our first attempt, we decided to try and condense it to not take up too much time one something with an unknown outcome.
In the morning we created a long-term goal, built a map and agreed the scope of the rest of the sprint. From the start we felt good about the collaboration and I think the team felt like we were getting a lot out of it pretty quickly. Often conversation would start swaying towards specific solutions. When this happens you just have to keep on track. The facilitator should keep everyone in check and remind them what we are trying to achieve in that session. As well as keeping everyone to time, important when you’re trying to condense it. After and during building the map, the team silently uses postits to write “How Might We” questions. (HMW). These are based on the map just created.
In the afternoon.
After lunch we started Remix and Improve, this is where individually you research ways how other companies etc have solved similar problems. This helps get inspiration and ideas. We were looking at re-designing our settings pages, so we took a lot of inspiration from Mac OS settings, Google Apps, Chrome and some others.
Day 2 (actually contained days 4 & 5)
To produce our solution sketches the group dispersed and we undertook a four-step process
- Notes — Gather key info from our work to this point
- Ideas — Doodle rough solutions
- Crazy 8’s — Try rapid variations of these solutions by folding a piece of paper 3 times, and using the sections it creates for mini storyboards.
- Solution Sketch — Finally, figure out the details of our favourite solution
Art Gallery, Heat Map and Speed Critique
Once we had all produced our solution sketches we gathered together to critique. Each solution was hung on the wall (or window) and as a group we looked at each one and using stickers indicated which aspects we found interesting. We then said what we thought was good/bad/unclear which was added to post-its. The team member whose work it was then had the opportunity to fill in the gaps and answer these questions. This was repeated for each solution.
Afternoon
Before moving on to produce a prototype we took some time to review our winning solution(s) and produce a storyboard to prevent getting bogged down by small unanswered questions, pieces that don’t fit together etc. This storyboard represented all the steps of our winning solution.
One Mock to Rule them All
Ideally, you will end up with one mock, maybe two. Then designers can create these into high fidelity mocks.
I will share the final mock in a separate post… to keep you coming.
Design Sprint Materials
To find out more about design sprints, there’s a really great video:
And of course, the book.
