Jeremy Johnson — Dallas Area UX & CX Leader
customer experience leader


So you want to prototype?

prototyping_blog I personally think prototyping is the way to go when creating a new software product (or any product really). You get to "blueprint" out how something is going to work, how the pieces fit together, and how it will really work once launched. I think most people are sold on the concept, so it's a matter of how to build this close-to-real product that you can test with your user base. Do you use paper? Mock-ups? Tools like iRise and Axure, or get real and build a non-functioning ready to reuse front-end?

The first step is defining what you're going to use this prototype for. Is it to drum out business requirements? Demo to clients before they write the big check? Or get something as close as possible to the real thing, so you can start the User Centered Design process and test your ideas on actual people that will be using your product.

Obviously I enjoy prototyping for the latter, getting real feedback that our team's ideas were dead on, or widely off-base (never!). To do this, you really want to build the prototype in the technology you're going to create the finished product in (usually HTML or Flex for web based software). This solves two problems: one, this truly is as close to the real thing as you can get. By using the actual UI technology you'll be creating the final product in, you'll know what can and can't be done, users will get a real feeling for the responsiveness, animations, and interactions. It's real, sans the months of backend development needed to power this prototype. And two, you can pass this finished front-end code off to the development team, taking pressure off backend developers who may not be well versed in front-end development.

Microsoft when working on Office 2007 did this very thing:

“if you’re trying to build a prototype that you want use as a blueprint, it should exist in the same medium as the final product.”

In the past when I've run prototyping projects, the teams usually consist of just one designer/IA, one developer, and a small amount of a backend developers time (to get some fake system data up and running). Depending on the maturity of your front-end development group, you may have sets of UI widgets and code ready to go, this will help speed up the overall process.

Dave Cronin from Cooper recently wrote an article titled "Industry trends in prototyping" - which I agree with about everything in the article - he lists out four reasons for creating prototypes: prototypes make your designs better, help facilitate communication, enable user input and usability assessment, and help assess technical feasibility and reduce development time. He's also a fan of creating "real" prototypes where it makes sense.

I love this comment from Philip Fierlinger:

Prototypes, on the other hand, let people feel the flow and experience the relationships. Building prototypes allows architects and interaction designers to quickly identify broken pathways and iterate quickly to find better flows - by feeling the experience, rather than thinking about it in the abstract. Developers, designers and clients also get a much more tangible sense of what the end product will be.

Again, I can't stress enough how a "real" prototype will give you the best feedback for the effort. We've also used these prototypes to help sell ideas to business groups. Imagine trying to sell an idea for a mobile app by letting your VP access it directly on their phone. This will beat out any PowerPoint presentation.

Garrett wrote on this topic years ago, and the technology is now easier to use than ever before. There are frameworks, open source systems, and reusable icon sets ready to be molded into your own prototype.

Using wireframes or paper for low-fedility prototyping is not necessarily a bad thing. Maybe your just testing internally, or you're limited with your technology skills. There are discussions about what fidelity wireframes should be (both form and function). There are many tools at your disposal for creating wireframes and prototypes, and they've really just recently gotten easy to use. No longer are you stuck with Visio - here's a list of some tools, ranging from very expensive to free with varying sets of features:

Boxes and Arrows has an article from 2006 written by Scott McDowell, that goes over some of these options, but what's really interesting are the comments below the article where designers talk from real world experience. And Russell Wilson from Dexo Design compares 16 prototyping tools (2008) and again, the comments are interesting.

I tend to use wireframes to quickly get across ideas and interactions. Something that could possibly be thrown away, or will be changed a number of times. Once the idea seems to stick, I move to high fidelity mock-ups, sometimes merging the mock-ups together in a slide-by-slide presentation showing the page flow with faked interactions.

GUUUI posted some links to videos showing lo-fidelity prototypes in action. Again, this can work to help guide overall concepts, but to get true feedback - you really need to have a higher level of fidelity.

If you're in a good situation where you're ahead of the product timeline, prototyping is your next step. Just like how a architect moves to a model, build out your prototype and test, iterate, improve, and in the end launch a successful product!

(additions) Great post over at Adaptive Path: Rapid Prototyping Tools