Fake it ‘til you make it.
An Approach To Prototyping That Sells
When it comes to web and mobile application development, it seems to me that many entrepreneurs and product teams are often too anxious to develop (coding implied) a proof of concept (POC) and much less interested in understanding the problem space or seeking user validation of a product’s viability.
Jumping into a coded solution prematurely is not only expensive but far less flexible and for these reasons, less likely to be considered disposable.
Disposable is a key tenet of rapid prototyping. The other tenets are Fast, Efficient and Enough.
Prototyping Over Coding
From my experience, a combination of iterative prototyping (no coding implied) and user validation testing is the best — i.e., fast and efficient — way to design and vet a product’s viability.
As for enough, very few product concepts require actual coding to convey the idea. Those that do are typically technology-driven solutions that depend on new and unproven tech. The phrase new and unproven tech, by its very nature, implies a technical POC. For everything else, faking it is enough.
Faking it (i.e., prototyping) ‘til you make it (i.e., coding) saves time and money, not to mention undue frustration for your developers.
Multiple Approaches to Prototyping
I have identified three kinds of prototypes or rather three approaches to prototyping...
This approach is widely accepted, and what I believe most readers were imagining as they read my opening remarks: low fidelity, disposable, rapid prototypes that might be described as a clickable wire-frame. To be sure, this type of prototype has its place. It is enough for quickly working out UX patterns and product workflows.
The remaining two prototyping methodologies represent a road less traveled and therefore I find them a bit more interesting.
The second approach is similar to the first, also generating disposable, rapid prototypes, however, the screens are high fidelity. If it is done right, the prototype could pass for a finished product, at least within a demo context.
This approach flies in the face of conventional wisdom which values low-fidelity black and white wire-frames over high fidelity, color screens because it is believed that the incompleteness of a wire-frame illustration indicates to viewers that the product is not finished, therefore freeing them up to engage the presentation in an intellectual fashion, rather than getting hung up on design elements, such as color and form.
If that were true, we would not be hearing, "Is it going to be black and white?"
In fact, if you read my recent post, “Presentation Matters”, you already know that I believe the opposite to be true. There are situations when wire-frames are clearly not enough. Let me explain.
Experience suggests that most individuals are not looking to offer a design critique — if it looks professional, they pretty much take it in stride. On the other hand, practically everyone reacts to bad or inadequate design. They may not be able to articulate why it is bad, but believe me, they form an opinion — "mom and pop", "unprofessional", "dumb", whatever — in seconds!
This is not the reaction you want to risk from potential investors or partners.
My theory is that by presenting a cohesive, professionally designed, high-fidelity user interface, the quality bar has been established and the user can relax and buy into the experience. This is not to say that the interface represents the finished design, but that it could be a finished design.
As it turns out, high-fidelity prototyping doesn’t necessarily require a lot more effort and is the only approach which offers enough for certain audiences.
One way to make sure the high-fidelity approach doesn’t consume an inordinate amount of time and resources is to follow the advice of Austin Kleon’s excellent book, “Steal Like An Artist” — find an existing application UI that you or the client likes and rip it off, whole cloth. Remember, this isn’t meant to be the finished interface, it is simply meant to establish a quality bar.
We get everyone to agree, up front, that any discussion about styling, is strictly off limits at this stage. The only valid design questions are, “Does it look professional?", and "Can you imagine another company releasing a product that looks like this?” Since we have lifted the UI design from an existing product, the answer to both questions is always, “Yes”.
This is terribly freeing, allowing us to create, test and iterate high-fidelity mock-ups quickly, knowing that the final styling conversations will be had at some future date and time.
Approach No.3 is a roll-up of Approach No.2. We call it a “Linear Prototype”.
The term, linear prototype, was coined years ago by my friend and mentor, Mark Dillon. Basically, we leverage the final high fidelity prototype described above to create a video demo — an extremely predictable and effective demo.
A good linear prototype should not be “salesy”, or too polished. Instead, it needs to be intimate; like a good friend letting you in on something new and cool. We try to keep these demos short, like 90 seconds, and the goal is to most definitely create the illusion of a finished product.
Why this approach? My answer to this draws on my background in filmmaking. It’s a concept that all filmmakers rely upon in order to engage their audiences: the willful suspension of disbelief.
It turns out this concept is not only helpful to the enjoyment of stories about galaxies far far away; but, it is also helpful to getting investors and strategic partners to capture the vision of your product.
I first discovered this approach to prototyping in the early 90’s. We were designing an interactive television (iTV) pilot for The Discovery Channel and we were depending on Philips, to provide a critical set-top box technology, which they had developed, but not released.
They turned us down three times!
As a last-ditch effort, we decided to create a linear prototype demonstrating what the experience of watching Baseball might be like on the iTV system we were envisioning. Major League Baseball agreed to provide footage and a license for our prototype with the stipulation that we show them the finished demo for their approval, before sharing it with anyone else. Two weeks later we had created a very believable linear prototype — all faked in video post-production.
When we shared it with Major League Baseball they loved it, asking us how soon could get their hands on it. We had to explain that it wasn’t real technology.
Then we sent the video off to Philips. They contacted us a few days later, saying, “Oh, that’s what you want to do. Now we get it. We’re in!”
This approach worked then, and it continues to work today.
So, here's the takeaway... Remember, there is more than one approach to prototyping a web app. Low fidelity wire-framing has its place. It is fast and efficient but it isn't always enough. If you are seeking buy-in from an investor or strategic partner, the high fidelity, linear prototype approach is MONEY!
I had to smile when Apple recently launched the latest AppleTV supporting custom apps. The demo Apple chose to explain the power of their new product was a Major League Baseball app – nearly 25 years after our linear prototype. :-)
Special thanks, to Susan Culkin for her input on this post.
For more articles by Steve Lomas, visit Digital Bits at blog.stevelomas.me.