You only need a few days to assemble your prototype. At worst.
If there’s anything I’ve learnt from prototyping day running Design Sprints, and attempting to prototype regularly to speed up development cycles for the startups we partner with, it’s that proficiently prototyping is hard. Don’t get me wrong – we all typically have a set of skills to make decent prototypes – but you can easily burn more time than is necessary to get the same outcome.
I want to share with you why you only want to spend a few days on each iteration, worst case scenario, and how we arrived at the prototyping process we use today.
Why only a few days per prototype?
Setting the scene terminology wise, each prototype I consider an iteration. In between each iteration you will want to test how well that prototype fulfilled the requirements or solved the problem at hand. If it doesn’t work too well, you adjust it rapidly and try again till you get to about 80% of the solution that you need.
In the case of Dyson, he crafted 5,127 prototypes before moving forward to release his first model. If it took just 2 weeks per prototype, that would have taken Mr. Dyson almost 200 years*. Suddenly, even a couple of days per prototype to validate and test an idea doesn’t seem so farfetched. The question then becomes “how do create a prototype every few days?”.
*N.B. one year is actually closer to 365.25 days.
Proof-of-Concept (PoC)
Within startup and software development circles this term often gets thrown around a lot. Different people have different interpretations, and to make matters worse none of them are incorrect per se. My original working definition always included a technical build, not dissimilar to a slightly better hackathon by-product, and took at least a few weeks to put together.
This was okay when the value of the idea or concept was already verified through other means or a “sure thing” and all we needed to do was prove it was technically feasible. You could argue that a prototype is useless once you’ve arrived at that point though. A few weeks or months of build on a losing idea can be a recipe for disaster, easily crippling some companies into bankruptcy. There must be a better way.
Design Sprint 1.0
Reading and performing these are where things improved dramatically. For those of you who haven’t heard of it before: it’s a 5-day process you can use to build a prototype and test any business idea, often used for digital products. (You can read more about our workshop with Jake Knapp). The beauty of it is that it takes only one day to build the prototype, using everyday tools like KeyNote or Google Slides. Simple. Solved, right?
Well… it doesn’t always work that way. Being both a Facilitator for a Sprint and the only resident Designer made it a challenge to get a really high level of fidelity in the time frame budgeted. The prototypes still tested the underlying flows very well, but something was still missing. For me personally I knew there was a way to push this forward to the next level, but I also knew I couldn’t rely on the rest of the Sprint team to use a tool like Sketch.
Design Sprint 2.0
In the pursuit of excellence we knew there was more to learn and a way to get better. After attending the free AJ&Smart Webclass I subsequently got to work studying the Masterclass to peek at how the best of the best have updated the Sprint to be better than ever. What I took away from it was that you can absolutely rely on the strengths of your team, especially once you’ve assembled the right type of team.
Whilst I had been slowly but steadily getting more proficient at using the good old Sketch + InVision combo for everyday mockups and concept testing, there came an inflection point where the prototypes became quicker to produce than the Design Sprint 1.0 method. Even accounting for a whole Sprint team working together, it was taking about the same amount of time for me to produce something that looked more realistic. The “aha” moment was had!
Planning is Key
A common theme throughout these different mindsets and interpretations is that the quality and the speed of execution always improved when we spent time planning ahead. Not just breaking down the work into chunks and assigning it to people, but having that top-down view of the prototype end-to-end before getting to work.
Above you can see a storyboard from Disney’s The Lion King. It’s a well established technique that helps animators craft the story together into their own master plan. Doing our own version of this always helped everyone get on to the same page, or even when working by myself I found it invaluable to see what the intended outcome was before I even opened up a Sketch file.
As we like to say, sometimes you need to go slower so you can eventually go faster.
Key takeaways / Conclusion
- You can skip the prototyping, but it’s often more costly in the long run to charge ahead instead of taking inventory before making a move.
- Rely on the strengths of your team. If you have a designer or two, use them! Let the other members of the team leverage their strengths in other ways such as copy or arranging testers.
- Craft your own master plan so you know what you’re trying to achieve as a whole before moving forward.
If you think you could do with some prototyping love, want to learn more or simply discuss it with someone then you can always reach me on Twitter via @chuckwired, email charlesr@thestartupfactory.tech or pop into the tsf.tech pod to chat over a brew.
