Two (2) weeks ago (Nov 19 & 20), I attended a 2-day event organized by Leah Oliveira and Carlos Oliveira (co-partners at AdaptiveX.). The first day was a Design Sprint Bootcamp facilitated by John Zeratsky (former design partner at Google Ventures and co-author of Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days and Make Time), while the second day was a Prototype Thinking Bootcamp facilitated by J Li (a partner at Prototype Thinking Labs).
While I won’t go through the happenings of both days, I will summarize a few learning points that hopefully whet your appetites to look out for such events, read books or engage in these practices.
But first, Design Sprint OR Prototype Sprint …
I really avoided calling this “Design Sprint VS Prototype Sprint” because I didn’t want to see them as toolkits to pitch against one another. This is not a debate. They are 2 toolkits with different approaches that achieve similar purposes in different ways. You can adapt – we’ll get to that later.
Design Sprint is a five-day process for solving problems and testing new ideas. It’s based on the premise that if you take a small team, have a clear schedule for a week (don’t give up yet, you do not need to clear your entire calendar for a week), and rapidly progress from problem to tested solution using a proven step-by-step checklist, you can project into the future to see how customers react before you invest all the time and expense of building a real product or service. Ain’t that cool?
Prototype thinking encourages prototyping, testing, and iterating in hours. Hours. (Yes. I’ve done it in 2 hours). This means you can validate a solution in a matter of days. It’s based on the premise that you can maximize your rate of learning by reducing the time to try new ideas.
A 50% optimization on 90% of variables is better than a 100% optimization on 20% of variables
and
5 user tests will yield 85% of the key information you need to validate an idea
Prototype Thinking is claimed to be the next evolution of the Design Sprint (aka Design Sprint on Steroids) to help you get immediate, fast, nuanced experimental outcomes from real-life users following a defined methodology.
Now let’s get into the learning from the 2-day event
1. Get out of the shop and fail!
The Introductory chapter and annotation of my current read “Talking to Humans” captures this point nicely for me. You’ve got to find the right balance between vision and reality. And you only know reality when you get out of your shop and talk to real people that don’t know you and have no vested interests in your product or service (P.S: your mommy will lie to you and your spouse will not demoralize you by telling you your idea sucks, so they do not count as users!). More importantly, while talking to your users, do not be on the defensive of your solution, rather be a detective. Do not sell your idea but get feedback. I saw a quote recently that summed this up for me:
Good Designers hope to be proved right; Great Designers hope to be proved wrong.
I read “Good “anything” hopes to be proved right; Great “anything” hopes to be proved wrong.”
Don’t be scared of being proved wrong by a valid reason – wrong is good feedback and time-saving.
2. Adapt. Adapt. & Adapt.
Trying to run through all the various steps of a design sprint or prototype thinking session one by one in detail may be overwhelming as I find it through practice. I mean, if you’re not a design sprint shop, you probably do not even need to be keen on running through the entire thing. As an individual that wants to apply these toolkits to their jobs effectively, you probably should focus on efficiently facilitating ideation sessions, making sure the right frameworks and tools can be leveraged to get your work done and then keep it pushing. Do not forget that you already work in an existing organization with its own culture, practices and business in which these innovation toolkits are supposed to be adapted into and this is highly important to keep in mind. For example, the 5-day design sprint does not have to be done in 5 calendar days, because your organization may not be able to close shop on operations for 5 days and dedicate it to a design sprint. But does that mean a design sprint will not be applicable if you don’t have 5 days to work with? No. That’s why you need to adapt and adopt the relevant components of these toolkits.
3. Never skip Prototyping and User Testing!
#NuffSaid. This is the easiest to put off but probably the most important. These frameworks do not end the ideation sessions with the team. But they encourage actual prototyping and testing. The bus stop is not the fancy sticky notes on the walls but the user feedback we get. The whole point of the Agile culture, design and prototype sprints is to engage your users and validate ideas before you go to town on them. But how do you validate without testing? and who do you test with? The outcomes of these sessions should be aimed at testing with actual users – whatever that test looks like (prototype) and measuring outcomes of those tests in order to improve.
Prototypes could take different forms, shapes and sizes, but as much as possible they should be close to the real thing, as cheap as possible and easy to adjust even as the user tests are going on. Also, be sure to test the assumptions that:
- are the riskiest
- you’re most unsure of or
- are fatal flaws in your solution, which if do not go as planned will totally cripple your idea.
This way, you are surer of what you’re getting into and you’re minimizing your risks with minimal cost and a few cans of coke.
Bonus point:
You get better with practice – I should take my own advice. So should you!
Enjoy innovating!
.
..
…
You made it this far! Great – See photos of my fangirl moment with John Zeratsky and my signed books below
