Two designers from Google (@leggett and @darrend) made a fascinating presentation this morning at SXSWi around prototyping web apps (#prototypingwebapps). Starting with the premise that your end goal is to “ship experiences people love” they laid out some guidelines and recommendations for quick, effective prototyping of web apps that:
• Help make your ideas awesome
• Get other people excited about your ideas
The opinion was shared that wireframes don’t really let you see what things look like, a mock up is better, but a prototype is ideal as it lets you see how interaction will work – this elevates the level of discourse and engagement from those who are providing feedback. Prototypes also help you see more flaws in the design.
PROTOTYPE TYPE 1 – Slideshow
A great place to start is with a straight-up slide show whereby clicking on any area on the screen brings you to the next screen. How much code does it take to show an interaction? None! Dump in a folder of comps and out comes a slide show. One step further is to put it in a browser to make it reflect what your app will look like that much more.
PROTOTYPE 1A – Slideshow with Video
The straight-up slideshow is hard to pass around so, a second approach is to make a video: A simple little 3 minute screencast of someone using the slideshow prototype with narration, etc. These get passed around really easily… hopefully, it leads to getting your app greenlit. (Remember, of course, that it’s all got to be predicated on good feature design.) Adding a story, joke or some kind of surprise can make the thing that much more compelling.
PROTOTYPE TYPE 2 – Hotspot
If you want others to actually be able to use it, construct a HotSpot Prototype. This type of prototype lets you represent actual action and an advantage of this over a slideshow is that you can branch.
There are a couple of cheap ways to do it… Fireworks will let you export slices/click targets or you can throw it into Powerpoint, but these don’t really feel real. (At Google, they have a script for doing some of this stuff in a prototype.) You can add more than just click targets (like text or input fields) to ramp it up, but at some point you eventually hit the end and it gets arduous to iterate, so be judicious with the paths/opportunities you enable. A good rule of thumb is to think of the effect you need, think of the change of state you need and think of “how do i make it look like the effect that I need?” The presenters like to “be as scrappy as we can be so we move on and iterate on our design.”
PROTOTYPE TYPE 3: HTML PROTOTYPE
When heading down this path, continue to keep it simple. Replace whole chunks of your app with an image whenever you can. Determine “what do I really, really, really need to work?” Just code the pieces that you need to work. If you’re testing a tool bar, code that, but you don’t need to make all of the menu options go anywhere. A related trick suggested was to add things like a 2 second pause so it seems like there’s a server behind you. This helps the ‘mental model’ for testers.
SUMMARY NOTES
• Make a Linear Experience: Show one awesome use case. Just concentrate on the good stuff.
• Go high fidelity, every step of the way
• “Be Scrappy. Iterate a lot”: Throw it into a slideshow and click, click, click. Let you see how it feels before you send it out.
• Make a commercial, not a spec when you’re trying to sell your ideas.
• Learn to code and be creative (you’re your own special effects dept). Also, the best way to lose an engineer’s trust if you propose things that don’t work. Learn/know what’s feasible in the browser.
• Let your prototype coupled with discussion be your spec.
By following these rules, “you can do everything quickly and make everyone jealous about how fast you can make quick stuff.” A couple of good, random final points that came up during the question and answer part of the talk:
• Avoid churn/client review cycles by showing small chunks (start with 10%)
• The speakers recommended guerilla usability testing a la the book Don’t Make Me Think, basically advocating getting anyone other than the designer to use it. – But real testing in a lab is valuable too.
• The speakers don’t believe in rigid line between Interactive/Interaction design (aka Information Architecture), Visual Design and Usability. All three off these things must be connected and interconnected with one another.
• The only real “wireframes” you need/want to do are sketches . Knock these out really fast on paper. There’s no value in high fidelity wireframes.
• Google designers use Jquery and/or write really sloppy, messy code that gets the job the done.
• Show things that have real meaning in your prototypes/comps. Don’t use Lorum Ispum in place of real text and don’t put in things like “description goes here.” Think out the language at this stage of the game.
The speakers promised to put some resources up at SLIDEFOLDER.COM within a couple of days. I’ll do my best to update this post at that time.
