Table of Contents
Can you solve pretty much anything in 4 days? Design Sprint claims to do so, and I had a chance to apply the Design Sprint method to a couple of projects. Here’s a list of my biggest takeaways.
Design Sprint is un-orthodox #
The rigid framework that the Design Sprint provides, at first sight seems a bit strange. But this difference is the outcome of GV, Google and many other smart people working for years on how to think about solving product problems. Trust the process, as they say, and your results will speak for themselves.
My biggest mistake — ignoring ideas from other industries and parallels As I learned more and more about the Design Sprint, I realised the one mistake I’ve been doing in my own UX process: ignoring examples from other industries. The Design Sprint actively encourages you to have a look at similar problems solved in other industries. Although the solutions are not a great match, the way people have gone about solving their problems tells a great story about the challenges faced, and how they were tackled.
Crazy 8’s are great #
I loved the Crazy 8 technique for brainstorming and sketching. It forces you to solve a problem in more ways than you can initially think of, and if the problem you picked is key to your Sprint goal, it can pay great dividends.
The mapping is not what you think #
Mapping in a Design Sprint is slightly different from a conventional user journey mapping exercise. This was my initial hunch when I approached it, and got corrected. However, I discovered that the way we do mapping in Design Sprint leaves many doors open for refinement and discussions later on, which is awesome, as the time you take moving towards your solution is the mental space you need to produce great designs.
If you are keen to understand more about mapping, watch some of AJ&Smart videos on the topic, or better yet, grab the book.
Framing assumptions as questions make them a lot more useful When thinking about a new business problem, it’s worth a shot to identify risks up front. However, traditionally, they sound like distractions from achieving the project goal. Design Sprint turns this thinking on it’s head, by converting risks and assumptions into questions. So an assumption like ‘Building user trust into the product is an assumption we must make’ becomes ‘Would we be able to gain user trust?’
Nothing beats actual user feedback, and Design Sprint has a short feedback loop The best thing about Design Sprint is that you get direct user feedback, fast. In my case, I discovered that with the feature I am designing for the project, the company might be cannibalising it’s other primary product. This might mean the whole product question needs to be re-evaluated.
But that’s probably a good thing. That’s what Design Sprints are for. If your product hunch is wrong, better find out about it in a week, than in a year after you’ve spent millions on it.