After over 2 years of extensive research, Todd Zaki Warfel has released the book “Prototyping: A Practitioner’s Guide”. I talked to Zaki Warfel about his interest in the area, the surprising results of what prototyping methods practitioners actually use , and how he seeing prototyping being used in the future.
VT: What was the inspiration to write about prototyping?
At my company, Messagefirst, we had starting doing more and more design of webapps and things that took advantage of modern technologies like AJAX to improve the user experience. We were finding that as detailed as our wireframe documentation was, it was falling flat when trying to show transitions like self heal and progressive reveals. We needed something that could show and tell the story of the experience better—we turned to prototyping.
How clued up is industry right now when it comes to prototyping?
Not very. I’ve seen a high degree of interest, but from practical standpoint, there’s a very small minority of practitioners doing prototyping as a regular part of their design process. I find it’s most common at the most extreme ends of the spectrum. Based on the research I did for my book, it was something that I found to be more likely in Agile-type shops and really large corporations with hefty budgets like Microsoft. That’s not saying that all Agile shops or corporations with hefty budgets are doing it, but those seem to be two environments where it’s more likely to occur.
While there is interest in prototyping, the two main things that prevent people from adopting prototyping into their design process are that they don’t know where to begin and they have a hard time convincing their client or boss that it needs to be.
There’s this misconception that prototyping has a high cost, adding significant time and financial cost to the design and development cycle, when in fact the exact opposite is true. Not that prototyping doesn’t have a cost, it absolutely does. The thing is, just like anything else, you’re going to pay now or later and prototyping has a much lower cost than paying later. Fixing something in the design process is much less expensive than trying to fix it once it’s been launched. Depending on who you ask, fixing a problem once your system has launched will cost 100-1000 times as much as what it would have cost had you fixed it during the design process.
Getting past the “cost” argument can be challenging for people who don’t have experience prototyping and can’t speak to it first hand. Fortunately, I’ve seen the benefits firsthand and have a number of stories I can tell about those lightbulb moments we’ve experienced with customers and clients that we’d never experienced with wireframes. I can also give our clients examples of how prototyping enabled us to uncover hidden problems, explore design solutions, and make informed decisions prior to launch that we simply couldn’t have done with out prototyping.
People just need to find the comfortable place to jump in and try prototyping, something small with a low initial cost that can provide some value they can show clients in order to make it a regular part of their design process.
One interesting concept in the book was using prototypes for communicating ideas (Robert Hoekman, Jnr. coined it “proto-communicating”).
The standard practice is to either use wireframes with behavior notes and or a spec document. Spec documents are the worst. They’re typically 60-200 pages, mostly text, occasionally include screen shots to illustrate what the text is trying to describe. It’s still a static representation of an interactive and dynamic experience.
Wireframes are a little better for communication, as they rely more on visual representations of the system with behavior notes. But like a spec or requirements document, it’s still a static representation of an interactive and dynamic experience.
Since the dawn of man, we’ve used pictures to communicate. Our first form of written communication was cave paintings—drawings. We are visual thinkers by nature. If I try and describe a system to you, your brain is wired to immediately draft a picture of what the system is, how it might look, the way you move from screen to screen, or state to state. Why not leverage that native visual thinking language?
Prototypes are about show and tell. They’re a visual way of communicating the design of a system. First and foremost, they communicate your design. That’s kind of ground zero.
You did a lot of research into the prototyping tools interaction designers currently use. Did you have any surprises?
Initially, I was surprised at the number of people using Visio and Excel to prototype. Let’s be honest, as a drawing tool, Visio is mediocre to decent at best, but as a prototyping tool, it’s pretty poor. And then there’s Excel. Who in their right mind would ever prototype in Excel? Turns out, someone who has access to it, knows it, and is comfortable using Excel.
This turned out to be one of the biggest influencers in selecting a prototyping method or tool: use what’s available and what you know. The thing is, that as bad as these tools are for prototyping, the worst tool you can try to prototype with is the one you don’t know, aren’t comfortable with, or don’t have access to.
There are a number of better prototyping tools available: Fireworks, Flash, Axure RP Pro, PowerPoint/Keynote, and HTML just to name a few. And while they might actually be better prototyping tools, if you don’t know them, don’t have have them on your computer, and need to prototyping something quickly and have it ready today, tomorrow, or in a few days, then you use what you know. Learning a new tool does have a cost. You just have to decide when you can afford a little downtime to learn that new tool.
What are your preferred prototyping tools?
Has doing the book changed how you prototype?
I’m continually evolving the design process we use, so it’s hard to say. It did open the door to some new tools that I was aware of, but hadn’t tried out yet, like Fireworks. In the past, I had only used Fireworks for visual design and production of visual assets, but not for prototyping. The more I learned about it, the more I wanted to try it out for prototyping.
One of the things that did happen along the way, was that our prototyping process evolved to the point of being more and more comfortable creating production-level prototypes. Most prototypes are built with the intent of being a “throw away”—little if anything from the prototype will actually be recycled for production. Personally, I think that approach gives you a great deal of freedom and flexibility. And honestly, it’s the approach I would advocate for most people. Our situation is a little different. Most of our prototypes are created with the intent that eventually most if not all of it will be repurposed for production.
Since we’re creating prototypes that often make their way into final production, our approach is a little different. We use our own custom HTML/CSS framework to prototype. There’s nothing really proprietary about it—it’s all standards compliant HTML and CSS with Prototype, jQuery, or YUI! thrown in for AJAX effects. However, as part of the ever evolving refinement of our design process, I’ve rewritten this framework three times and am currently working with Jonathan “Yoni” Knoll to rewrite it again to make it even better.
I think the book has encouraged me to explore additional toolsets and continually refine our prototyping process and framework.
Are there many things in the design process you can’t prototype?
Not that I’ve found yet. The nice thing about prototyping is if you can fake it. One of my guiding principles is: If you can’t make it, fake it. So, there really isn’t anything I can think of that can’t be prototyped at some level. Some things are easier than others, but I can’t think of anything I haven’t been able to prototype to date.
In nearly every case in the past three years, prototypes have become our documentation. There are a few exceptions, where we need to include some supplemental documentation, say a 10-20 page document to specify some business rules that happen on the backend, which aren’t clear from the prototype. But I’m willing to do a 20 page spec document and a prototype instead of a 200 page spec. It still takes less time to build a prototype and write a 20 page supplemental spec than it would to write a 200 page spec and get consensus on it. And you still won’t know if it’s going to work or not until the system gets into production. Any design based on a written spec is a design based on theory. A design based on a prototype is a design based on experience and practice.
Any design based on a written spec is a design based on theory. A design based on a prototype is a design based on experience and practice.
Any predictions or hopes as to how prototyping might evolve in the future?
My hope is that it becomes more of a common practice in the design process of anyone making products. I know personally how much making prototyping a core part of our design process has changed the way we approach, design, and validate our assumptions. It’s also made our solutions much more creative at Messagefirst. Once we start to see how the system will work, it begins to inspire new ideas. We can also identify issues much faster and earlier in the design process. Those issues create opportunities for more creative solutions. And the earlier you find problems with the design, the cheaper it is to fix them. Frank Lloyd Wright once said “You can fix it on the drafting board with an eraser, or on the construction site with a sledge hammer.” Prototyping is the eraser. All in all, my hope is that I’ve given the community something they find will help them improve their design process, their designs and make it easier to communicate their designs to clients and colleagues. Less pain, more gain.
Frank Lloyd Wright once said “You can fix it on the drafting board with an eraser, or on the construction site with a sledge hammer.” Prototyping is the eraser.
Any other insights about prototyping that you’d like to mention?
Probably the biggest insight is that making prototyping a core part of our design process has literally changed the way we approach exploring, crafting, and validating our design concepts. Prototyping has given us the power to show and tell the story of our design solutions to any given problem rather than just tell the story waving our hands in the air to describe the magic.
I think another significant insight is that reactions we get to from our prototypes from clients and customers is far beyond anything we were ever able to achieve with wireframes and static Photoshop visual comps.
One last insight is prototyping has not only given us the ability to test out our designs early and often, quickly uncovering issues with the designs, but has also given us a method to inspire new design solutions. It’s not until you start experiencing and playing with the design that we know whether or not our theory will really work. Once we start playing with it, seeing how it works, experiencing it, we often have those light bulb moments of “Oh, now that I see it does that, imagine if we take it a step further and do this…
Prototyping has given us the power to show and tell the story of our design solutions to any given problem rather than just tell the story waving our hands in the air to describe the magic.
Getting the book
Prototyping: A Practitioners guide is available now in paperback and digital format.
Thanks to Rosenfeld Media, Johnny Holland readers will receive a 20% discount on the book with the code JOHNNYHOLLAND when buying it from the Rosenfeld Media website. It is also available via the UX Bookstore.