Usability,Information Architecture,Design and Creative,Process and Methodology
Prototypes are great. They're cheap and easy to create, and they make the rest of your project cheaper and easier to create too. Good prototyping improves the quality of your project. Here's an introduction to prototypes, why they're great, and how to make them.
What's a Prototype?
Put simply, a prototype is a static model of a system that you want to develop which simulates to some degree the functions of the system.
In the world of web development, we usually think of a prototype as a series of visual representations of screens in a website or software interface that include basic interactivity that approximates the operation of the final application.
An early stage prototype might consist of not much more than some wireframe diagrams that sit alongside each other to show how the main screens of a product will work.
A slightly more developed prototype might consist of static image files that include links to other static images, which very roughly approximate the navigation of a system.
Or a prototype can go as far as incorporating a fully interactive interface that responds to a test user's input. In the world of Web 2.0 - where more advanced interfaces are being created - more advanced prototypes can help to iron out design and testing issues at an early stage of a project.
An important aspect of a prototype is that it is developed in such a way that it can be changed quickly and easily at a low cost. Prototype development should be iterative.
What Are the Key Advantages or Prototyping?
Ability to test and make changes iteratively
The first and most important benefit of a prototype is the ability to have it tested, generate feedback, make changes, and have it tested again, without the need to spend time re-programming expensively developed code or re-writing detailed functional specifications.
The system can be tested by designers and developers, and by clients, and it's easy to share feedback among the entire development team this way. Perhaps the largest benefit is realized when testing with actual users. Prototyping is a core part of the User Centred Design process.
Early and frequent changes
Early versions of prototypes don't even have to be complete in order to be put in front of project stakeholders. Review and alteration of a system is possible much earlier in a project than when no prototypes are developed. Constantly updated visual representations of the developing system allow frequent changes to be made, cheaply and easily.
Intuitive, visual clarification of interface and functional requirements
Have you ever read a detailed functional specifications document without seeing the software it describes in front of you? If you have, you'll know that that it's difficult - maybe impossible - to form a clear idea of how the software is supposed to work from written specifications. (And that's when the functional specifications are written clearly. It's a nightmare if the person writing the specifications thinks differently to you!)
On the other hand, when the system is right there in front of you, understanding comes quickly and it's easy to form questions. Development of a prototype provides an intuitive, visual representation of a system even before the graphic design is finished or code is written.
Even if end users are not engaged for active testing, a well developed prototype is an invaluable tool for sharing an understanding of how a system will work (and look) between designers, developers, project managers, and clients.
Prototypes highlight interface challenges
The car club website we're developing will show a list of current members so that other members can get in touch with them. The functional specifications that our project manager wrote have a section about the Members Screen. The specifications explain that we'll list members alphabetically by name and show their email addresses. Sounds fine when we first read it...
The catch is that the club has 14,000 members. Creating a prototype will make the interface problems we're going to have here obvious straight away. We're only going to fit a few Applebys and Andersons on the screen before we run out of room on our page! But it's easy to change our prototype, so let's try changing the listings page into a search, or add a set of glossary-like letter links to the top of the page ("A", "B", "C"). Ah, that's much better.
The Dangers of Early Prototypes
Project stakeholders can be distracted by the lack of "polished" details in a prototype. When looking at a pseudo operational system, discussions about how a system should look can distract from discussions about how it should work. Clear expectations about the purpose of a prototype should be set with the people reviewing it.
Another danger is that a prototype can have the effect of hiding the complexity of certain functions, especially from designers and developers. Sure, it looks easy to click on that button and generate a list of today's menu items in my restaurant management system. But hold on a moment, each of the three restaurants under management has minor variances in their menus that the prototype doesn't recognize, and the menu data isn't even in the database that the technical specifications for this project say we're going to use. It's common for issues such as this to be overlooked until someone sits down to write the code.
None of these potential pitfalls actually detract from the benefits of prototyping. On the contrary, it's a good thing to bring look-and-feel discussion to the fore early in a project, and it's a good thing for technical and workflow planning flaws to have a simple visual representation in our prototype (rather than to be lost on page 43 of the boring functional specifications document that some of the project stakeholders didn't even read).
I hear you say, "Ok, I'm convinced. So how do I create a prototype?" (Was that you? Or did I simply imagine it to help the narrative along?)
- Start with a pen and paper or a whiteboard. A lot of the prototypes we create at DDSN start as scribbles on the boardroom whiteboards. It's quick and easy to create a broad vision of interface screens, rub components out and redo them, and discuss design challenges when a few of us are sitting together in a planning meeting. We've even seen an early system prototype delivered on a napkin after a café lunch!
- Use wireframe development software. With the more common adoption of prototyping in the software design process, plenty of good software has been created to make the creation of wireframes a breeze. You can use traditional diagrammatic software like Microsoft Visio or Smartdraw, but there are specialized wireframing tools everywhere now. I've listed two good ones below, but there are plenty of others.
- Whether they realized it or not, traditional web designers have been creating interface prototypes using design tools like Adobe Photoshop since the beginning of web design. They're usually called mockups and used primarily to help a customer assess different screen designs, but they're really prototypes.
At DDSN we quite like using Photoshop to create a series of interface screens because we can incorporate carefully designed graphical elements into our screens as we go along. There's a danger here though: using this approach can be time consuming and cause difficulty if you want to make major changes, even if you're very experienced with the design software.
- Creating a HTML prototype can be a good approach if you need to build a lot of screens into your prototype quickly and actively link them together. Design tools like Adobe Dreamweaver or free alternatives like CoffeeCup HTML Editor can help here, but experienced web developers can often hand code a prototype just as quickly as when using a visual tool.
One of the advantages of roughly coding a prototype is that it's easy to simulate user interface behavior (e.g. form components, links and navigation) using real UI objects. Since we're primarily ASP.Net developers at DDSN, we often use Microsoft Visual Web Developer to create prototypes. This allows us to easily incorporate complex UI components into our prototype pages - like calendars, form controls, and dropdown menus - and even to mock up basic dynamic functions like logins and database interactions by writing rough system code.
- Keeping the previous option in mind (a HTML prototype), using a content management system like cm3 Acora CMS to build a prototype can help if you need to mock up a larger site navigation system, if you have more than one person contributing to your interface design, and especially if you have non technical people in your design team. Your CMS will include visual design tools so it's possible to simulate real user interface behavior without knowing anything about web coding. Navigation, pages and screens created in a CMS can sometimes be re-used in later stages of the project.
In fact, I've just outlined a possible prototype development timeline. Our prototypes often start out as sketches, are refined into wireframes, then treated graphically in Photoshop, constructed roughly in an interactive design tool, and sometimes incorporated into a content management system before we begin final coding.
Oh... I am of course talking about creating prototypes for websites and web based software in this article, since that's my background. Prototyping is used in slightly different ways in plenty of other industries but the concept is the same. Check out this cool way to shoot lasers into goo to create advanced engineering models. We have a plan to "prototype" the DDSN critters one day!
How Far Should a Prototype Go?
You'll find that developing prototypes to different degrees of completeness will suit different projects.
It's doubtful - though not impossible to imagine - that the coffee stained lunchtime napkin is enough to give to your software programmer as a development specification, but in many cases basic sketches or wireframes (with notes) are quite adequate.
If you're incorporating user testing into your project (and it's a great idea to do so), you'll probably need to create a prototype that at least roughly represents the navigation and operation of your system. In that case you might go as far as creating a HTML based prototype, and even incorporating the full graphic design of your system into the prototype in later stages of testing. That said, we often test taxonomies in early stages of a web project using simple Powerpoint-based wireframes.
The key thing to remember is that the prototyping process is flexible and it should be iterative. Think about the feedback you need from viewers of the prototype, and include just as much detail as needed to illicit that feedback. A rough sketch might be enough for a business to sign off an initial development budget. A more detailed vision of the user interface might be required in order to engage end users in interface testing.
More on Wireframing
If your interest in wireframing has been piqued, Smashing Magazine's 35 Excellent Wireframing Resources article is a great springboard from which to expand your knowledge.