I recently finished reading Ken Kocienda’s “Creative Selection” book about his time on the original iPhone engineering team. Most of the book is his work building the the soft keyboard for the iPhone and coming up with systems to allow users to productively type on a glass surface without any tactile feedback (with the specter of the awful handwriting recognition software that killed the Newton in the background)
So much of this book spoke so personally to me. Most of my career has been in very early stage projects where we were still figuring out what the products and technologies were trying to be. As part of Comcast Labs, demos and prototypes still remain the bread-and-butter of most of my daily work. And while I have met a few other folks who, at least at some point in their career, have had to work on these, I haven’t found many books that talk about the process of building prototypes and demo-ware.
Prototypes vs Demo-ware
One of the things I have learned in the last so many years that prototypes and demo-ware can be very different things. The primary goal of a prototype is to learn something (Houde and Hill’s excellent paper from 1997 breaks that down to Implementation, Role and Look-And-Feel). Demo-ware is more about getting people excited about the possibilities.
That said, a great demo can sink your product if you set unrealistic expectations. Among some of my prototyper-friends who now prototype at different companies, we still give each other “Clinkle bucks” for a good demo. For those who may not remember it, Clinkle was a once-hot-in-Silicon-Valley startup that raised $30M on the back of a great demo. The history of Clinkle is a fascinating read but highlights how a great demo made with no regard for feasibility cannot save your company.
A few thoughts on demos
Here are some of my personal notes on making good demos:
- Get to the point: You only have a few minutes for a good demo, so get to the interesting point fast. Do not waste your time implementing general software constructs like real login systems, etc. Fake as much as you can.
- Have the right team: Quite a number of devs I have met consider demos a waste of time. Make sure your team is passionate about making great demos
- Remember Theater: Lean into a bit of theater with good design and animations. Choreography is important
One final thing I’d like to say is that it is that in terms of tooling, it’s a bit of a bummer that tools like Flash are dead. While I love JavaScript, it doesn’t have the same ease of building amazing visuals like Flash did (Bas Ording, Steve Job’s main interaction lead responsible for many iOS interactions, did most of his work in Macromedia Director). A couple of my friends in other companies have moved to Unity but building demos for 2D experiences in a 3D game engine is not ideal. We need better and more approachable visual tools for sharing ideas.
Code Zen 