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

5 thoughts on “So you want to prototype?

  1. Please can you add iplotz.com into the list of online and offline tools for wireframing and mockups.
    thanks
    mark

  2. Great post. I think one thing to keep in mind is that the tools you mention are really great for visualization. By that I mean visualization helps the business focus and define their needs, desires and requirements without needing any development resources. Expensive and busy developers can be involved in other projects while the business is still getting its act together. In large organizations this is very valuable.

    As for fidelity, I’ve used tools like iRise to create extremely high-fidelity visualizations that looks, feels, functions and smells like the real thing. I routinely use the high-fidelity visualizations to prove requirements, test concepts, and conduct usability activities.

  3. Prototyping is a means to an end. The problem lies in its being the ‘focus’ towards that end.

    It is simply one element in a larger Design Thinking realm, a means by which to illustrate the possibilities. In the frame of this larger construct, it is more clear how far to take ‘prototype’ — typically through successive means.

    One of the failures I see among practitioners is the inability to effectively weigh the value of the results to the effort. FAR too often colleagues go down a prototype path by ‘rote’, investing far too much time where the real potential return is not that great.

    As practitioners we either need to take direction from others who understand this difference (which is also lacking) or learn the differences ourselves.

    Hint: Practitioners who are best at this typically have a business degree and/or have studied economics.

  4. Good post, I’d like to add ForeUI to your tool list. The most interesting thing is that it allow switching the look and feel of the prototype, the prototype with native look and feel is more suitable to be used in design documents.

  5. Interesting review, thanks!
    Can you add GUI Machine (http://www.gui-machine.com) – new powerful prototyping tool for desktop and web applications – into your list, please?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>