Why do we prototype? And why don’t others do it more often?

Being an engineer by training, (growing up with Erector sets, a TI-994A, model trains) I like to build stuff. Many times it’s after I’ve taken it apart and I’m just trying to put it back together. Lots of other times though, I’m trying to make things do stuff, usually with other things, that were never meant to work together. And sometimes, it’s because talking about an interface only goes so far. You have to experience something working before you know if it will really work the way you think it will.

So on most of the projects I work on here at MAYA, I try to build some type of prototype. Sometimes it’s just a bunch of PowerPoint slides. Did you know that you could actually make things in PowerPoint that have no bullets and can make you think you are really programming a washing machine to clean your dirty jeans? Or you can take apart a USB keyboard and flight simulator joystick and build a novel interface controller for soldiers? Either of these takes just a few hours to pull off.

For more detailed prototypes, we use Flash and Flex, as well as more advanced programming languages like Python, Java and our old standby C. Tools like PowerPoint and Flash, though, make it so easy to prototype a user interface quickly that I can’t understand why more people don’t do it. The point is to add just a little bit of activeness to the experience of discussing the interaction.

Over the last several years, I’ve developed the mantra, “Just prototype it.” The experience of having to think through how things are built makes you ask all sorts of questions you never get around to in a design/brainstorming meeting. There are a few things to keep in mind before you begin though:

  1. Everything has its limits. And just as drawing on a whiteboard and writing text specs can only tell so much of the story, prototyping reaches a point where you need to decide it’s over and time to move to the real thing.
  2. Every little detail does not need to work! This is imperative. If your prototype can do everything that the real product can do it is no longer a prototype. Build just enough to learn what you don’t know. Pick one particular task or feature and try to implement that to see how it feels. Then test it with a few users.
  3. Make two; they’re cheap. When you have questions about which way would be better to design a feature or component, build them both out and see which one feels better. Then ask a few other people to try them out and see what they think too.
  4. This is not production code! This is another way of stating all of the above, but the point is to not expect your prototype code to directly feed into, or be a part of, your production cycle.

The point of prototyping is to quickly learn something that you don’t already know. Can users figure out where to find this new feature idea you have? What button do users try to press to perform function ‘Z’? How fast or slow does the animation have to be to have the right visual effect and inform the user what has happened? These are all questions that can’t be easily answered with whiteboard sketches and Word docs.

Mozilla development roadmap

The thing that prompted me to write this little note was something I found while reading CNET. It was a reference to the development roadmap for Mozilla Firefox. See the included image. Note how they plan to take 2 months out of a 10-month product cycle to do Exploration & Prototyping. That’s 20% of their plan. And notice the next-to-last item in that group, “identify items for future releases & Mozilla Labs experimentation.” They are planning to find things that they know can’t be built right now, but they are planning to put them back into the roadmap for later releases.

Many of the clients I’ve worked with over the years work the same way: write the spec, build to the spec, test to the spec, release, glob on more features, release, etc. They don’t put explicit time into the project plan to explore ideas and write throwaway code. Little do they realize that they can probably save money by testing out a few ideas early in the process, rather than have users complain later that they can’t use the feature that they requested. And even if you don’t include all the findings in the first release, at least you have found out what works and you can put those ideas into future upgrades.

An unintended side effect of all these prototypes has been the benefit to the developers who now not only have a written spec of the functionality, but an interactive tool they can use to understand what the designers intended. They have almost become a standard deliverable with our written interaction and style guides. They also make cool demos for when the higher-ups visit and want to see what the next generation of the product will look like. Just make sure they don’t try to remove the bailing wire and duct tape on the back!

Related Posts

The User Jury

Aug 25 2014

I spoke to a client a little while ago about facilitating a user jury. At first, I wasn’t sure what they were asking. Were the users of their product being put on trial?

David Bishop
MAYA Fellow/Senior Practitioner & Researcher

A Simple Framework for Generating Insights

Aug 14 2014

Designer and researcher Traci Thomas on developing insights that lead to great design concepts.

Traci Thomas
Designer & Researcher

MAYApinion: App Engagement Metrics

May 31 2013

Measuring usability and user satisfaction is a best practice and a key to success, but our experience is that few projects advance to the point where they’re accomplishing this — measuring usability or acting on what they learn. Unfortunately, there is no simple recipe or silver bullet, but even the effort put into determining what’s important will be valuable to your design process.

David Bishop
MAYA Fellow/Senior Practitioner & Researcher
See all posts in Human-Centered Design