Prototype, Prototype, Prototype / by Jason Nunes

A great short TED talk about the benefits of prototyping. Tom Wujec: Build a tower, build a team | Video on TED.com.

I love the fact that kindergartners do far better at the marshmallow challenge than business school students.

I'm a true believe when it comes to prototyping, especially for expensive to build interactive experiences, especially low fi prototypes where you can test out concepts and ideas before you build or design anything. I think we designers spend far too much time trying to get things right before we present ideas to clients. We end up backed into a corner defending our ideas partially because they are good, but more often than not because we've spent so much time coming up with them. I've always believed that a flawed project that launches is far more successful than a perfect project that never leaves the design phase. Prototypes are a great way to communicate with our clients, a great way to free ourselves from the expectation of "getting it right" to enable us to explore new ideas or approaches,  basically a great way to play, which is such an integral part of a successful design process.

The challenge is that in traditional interactive projects usually very little time is built into the schedule for prototyping. My approach to this is to repurpose traditional user experience documents, such as wireframes, to serve as prototypes. This obviously creates additional challenges. For example, when in the process does a wireframe stop being a prototype, and start serving the purpose of documenting detailed requirements? And, how "designed" do the wireframes have to look for the client to understand what they are looking at in order to give useful feedback? And, how do you convey the interactive flow through a wireframed prototype?

Obviously I'm not the only one who uses wireframes (and other UX documents) as prototypes. I've found a process that works fairly well for me:

  1. I start with a user story based on a user persona attempting to meet a need or goal.
  2. I share this with my client, edit until the story feels right to all involved.
  3. I quickly bang out a rough wireframed screen-flow for each step in the story.
  4. Then I iterate.
  5. And iterate.
  6. Until we've got a solid approach, at which point I create a locked-down, detailed, annotated wireframe deck.

This kind of approach requires a lot of context setting, and a client who is willing to work with rough drafts of final documents. But so far it's worked for me.

I'd love to hear from other designers out there. Do you prototype? Is prototyping called out explicitly in your process? Or is it slipped in? What works? What doesn't Do you even need to prototype? What do you think?