Prototyping the Todd Zaki Warfel Way
Todd Zaki Warfel
I attended Todd Zaki Warfel’s webcast on prototyping last week. Hosted by our good friends at UIE, the seminar focused on the principles behind creating informative, useful web-based prototypes. It’s a fantastic primer, and I encourage anyone who’s interested in learning more about prototyping to grab a (legit) copy of the session from UIE.
I’m not going to reveal all of Todd’s key principles (watch the webcast!), but I do want to hit on several that I like to incorporate into my own work methodologies at ProjectEric.com.
(Some of) Todd’s key principles
- Plan a little – prototype the rest. First, let’s be honest: prototyping can be a lot of fun. Too much planning takes the fun out of it. Whether your prototype is a paper model or a high-fidelity, HTML-based masterpiece, part of the fun of prototyping is the ability to learn-fail-learn-apply very quickly. Too much planning impedes the natural art of tinkering. At ProjectEric.com, I like to keep my workflow very loose. Key milestones towards completion, a broad sense of what I want to get accomplished sprint by sprint. Then, I just let creativity take over.
- Explore concepts & make progress. Prototyping is exploring. For instance, I’ll log into JQuery, find a few good scripts that loosely accomplish the primary function(s) I’m trying to get across, then I might create several different mini-prototypes based on each script I find. Take navigation: there are lots of solid JQuery-based techniques. I’ll find my favorite two or three, then I’ll enter in the navigation items I think the client wants, make sure it aligns to my overall architectural plan, then I let ‘er rip. The client gets to see each option; that way, they instantly become part of the prototyping process. Plus, with prototyping, I reduce that often dreaded request from clients: “Show me 4-5 screen comps.” Ugh….
- Explore a direction. In particular, a user direction (or use case). Too often, I see designers prototyping the whole experience, end to end. Instead of a discovery/learning mechanism, prototyping becomes nothing more than a spec – like a detailed wireframe – from which developers code. No, prototyping is more powerful than that. Explore the unexplored when putting together a prototype. Take the hardest user flow (or use case) and prototype just that. You can fill in the undeveloped areas around the use case with filler images or square boxes. That way, you can focus on the most challenging aspects of the project by way of prototype and filter the easy stuff out (e.g. I may not need to prototype the footer; I may choose to leave it out entirely or fill it in with a placeholder image). You can always spec the remainder of your work (the non-prototype stuff) in a wireframe.
- Get your hands dirty. Many designers I’ve met have an insatiable need to be perfect the first time. Probably all that client rejection, year after year. Prototyping is dirty. The dirtier, the funner. It’s one of the reasons I sometimes choose not to develop prototypes using HTML/CSS/JavaScript. I find that too often the code locks me into a design idea, rather than the other way around. Lately, I’ve been using Fireworks CS4 to put my ideas together in a sort-of clickable model. It’s forgiving, it’s easy to move elements around on the page, no code required. What’s better, I can often prototype in real-time at a client meeting, have them give me immediate feedback, then I can turn around and make changes before the meeting adjourns. (Oh, and that reminds me, do make mistakes in front of your client. You’re human. They want to see you trying ideas. Rarely do I meet clients that expect perfection the first time. If they do, consider taking them off your client list.)
