This new year, I’m committing to more rapid prototyping

A couple years ago at SXSW, I watched a great demo from a few of the guys at Google about how they won over internal audiences for new products. They demonstrated several user experiences and introduced me to the idea of rapid prototyping.

image courtesy of Ben Melbourne

I don’t know how many meetings I’ve been in that have been bogged down with discussions of minutae, when what we’re there to talk about is user experience. I’m sure it’s the same for you. However, using an iterative process, you can help smooth issues and get to coding, secure that the higher-ups who need to see something working and track progress are able to do so. And all it takes is a little smoke and a mirror or two.

For many people, the things we do are magic. Or they might as well be. And most people can’t tell the difference between a .jpg and a fully functioning website, as long as you don’t go selecting areas on the screen.

When prototyping a Web application, what you’re really doing is selling people on the user experience. While some stakeholders will be interested in read/write permissions, database redundancies and the like, most just want to make sure their users can complete the task at hand. So, when prototyping, consider the following:

Slideshow prototype and video

  • A high-level presentation of a user’s process from task to task.

Hotspot prototype

  • You can add hotspots to your slideshow to go from .jpg to minimally functional Web pages which then can link back to static slides.

HTML prototype

  • Once your stakeholders feel confident in a good, mapped process and proposed features, you can begin to build out specific functions within the application. Again, you’re not yet ready to build the whole thing, just key moments in the user process.

Let’s say, for example, you’re building out a prototype for an online education course and you want to demonstrate the sign-up process. Do you need a fully-functioning form, sendMail object, and the ability to write to a database? Not at all. In fact, you might need nothing more than a few .jpgs and some simple form elements.

  1. A functioning login screen. It doesn’t need to be built out with fully functioning CSS. All you need is a .jpg wrap to give it a good look and feel and a couple links: returning user | new user
  2. Once someone clicks on “new user,” you could, again, build out a full form, but all you really need are a few blank fields. The rest can be pre-populated, or, if you wanted to get really clever, you could shfit to a fully completed form once you’re entered values for first name and last name, for example.
  3. Then, you can hit “submit” and click through to a static .jpg congratulating the new user on a successful signup, including a message to check their email account for an activation link.

Is this process laced with pitfalls? Of course. If someone asks to see functions you haven’t built into the demo, it could all come crashing down. But if you’re prepared, and aren’t afraid to note the features they want to see and promise you’ll build them in for next time, there’s no reason why your audience shouldn’t leave happy.

About the Author


Jeffrey Stevens

Jeff Stevens is the Assistant Web Manager for UF Health Web Services. He focuses on user experience, information architecture, content strategy, and usability.

Read all articles by Jeffrey Stevens