Prototyping Web Apps – Nobody Loves a Wireframe

Loose notes from SXSW 2010 session Prototyping Web Apps – Nobody Loves a Wireframe, with Darren Delaye and Michael Leggett of Google. I’m more of a back-end guy than a designer, but with an increasing interest in design considerations and usability. This became one of the most useful sessions of the conference for me.

Ship experiences that people love. If you show a wireframe, client won’t have a concept how it will look. A mockup will help with visualizaton. But a prototype increases the level of discourse/engagement. Prototype is interactive, usable. Not just pixel for pixel but interaction for interaction.

How would you prototype a roller coaster ride? How can you simulate that experience for client? User stands in line for 30 minutes then moves in a linear experience for 3 minutes then exits. But with a web app, there are infinite number of paths you can take through the system.

– Linear experience, just the good stuff
– High fidelity, every step, in a browser
– Be scrappy, iterate a lot
– Make a commercial, not a spec
– Learn to code, be creative
– You can iterate faster and do more in code
– Prototype and discussions is your spec

That Old Spice commercial with the guy ending up on a horse? Not CGI – all one shot – lifting up the set, etc. Done “scrappy”. Prototypes should be like that – special effects to get the user to a particular experience quickly.

Three types of prototypes.

1) Slideshow prototype. You’re going from one mockup screen to the next. The mocks are high fidelity and it looks real. This only works when you’re presenting your own ideas, not when the client gets to navigate themselves. Make a video of you interacting with the slideshow. 2-3 minute screencast of us using the slideshow prototype. You can even feign pauses like you’re making real decisions – makes it extra convincing.

2) Hotspot prototype. Lots of tools will let you create these. Fireworks will let you output a design with built in hotspots. It’s still a slideshow, but with a bunch of hotspots navigating to other slides, so you get fake “real” interactivity. But with too much complexity, this becomes arduous to iterate. Still, very convincing.

3) Only here do we start using real HTML. The iPad commercial that looked like it supported Flash, where the Flash block was later replaced with a broken plugin icon? That was because the designers had done an HTML prototype with a browser, not because the iPad secretly supported Flash.

Google Docs problem: The browser already has File, Edit, View menus etc. But Google Docs introduces its own. Would this duplication fly with users? They did a functional prototype where the top menus were HTML but sub-menus were images popped up with CSS and Javascript.

Trick – build a 2-second pause into the demo so it looks like there’s a server on the other end, processing the request. The user has a mental preset where this delay tells them they’re working with a remote server. Very clever.

Sending a working prototype is very different to the team from sending a spec. Legget would not have been sold on the super stars project in GMail if they had not been able to play with the prototype – it would have died on the vine.

Google seldom builds functional specs anymore. But they prototype like crazy. The prototype is a living spec.

Prototyping is not ALL about the client. 50% of the value is working out UI problems for yourself.

“Learn to code. No way to lose an engineer’s trust faster than to recommend an idea that is not possible.”

Dummy content: Don’t use lorem ipsum. Don’t say “Image goes here.” Use real content in prototypes.

Google has its own Javascript library called Closure but 90% of the designers there don’t use it. We use JQuery or whatever we’re comfortable with.