Prototypes are great. They're cheap and easy to create, and they make the rest of your project cheaper, easier, and better too. Good prototyping improves the quality of your project. Here's an intro to prototypes 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 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 analyse the business requirements, or even 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).
Prototyping Tools
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.
- Balsamiq Mockups has been around since the start. It has desktop and web based versions, and has been integrated with some project management tools and wikis like Jira. It's pretty cheap.
- Axure RP is nearly the digital industry standard for creating advanced, high fidelity user interface prototypes. It's surprisingly easy to get started with, and hides very advanced design tools for professional users behind a flexible and intuitive front end for beginners. This is our weapon of choice at DDSN.
- Cacoo is an easy to use online wireframing tool that also offers site map templates, UML and network charts. There's a free version to whet your appetite.
- And here are 18 other excellent wireframing tools (20 tools, less two that I've already mentioned)...
- 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 work if your system has a strong requirement for static content (like simple websites often do), or if your design ideas are fairly advanced already. HTML prototypes can often be spun into finished screens without the need to be re-coded. Web designers and developers can create HTML prototypes in any number of ways.
Using your existing content management system to build a prototype can help if you need to mock up a larger site navigation system, or if your focus is on copywriting or simple page layouts, and if you have more than one person contributing to your interface design. Your CMS will include visual design tools so it's possible to simulate or even create real user interface behavior (even forms and advanced interactivity) without knowing anything about web coding. Navigation, pages and screens created in a CMS can easily 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, given more detail in an interactive design tool, then treated graphically in Photoshop, 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, and we all know how far 3D printers have come along. 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 would usually go as far as creating a functioning HTML based prototype (e.g. using Axure, or asking your technical people to turn your sketches into linked pages some other way), 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.
Who Will Create My Prototype?
Well, that depends of course. If you've got a concept that you'd like to articulate but it's early days or your budget doesn't exist yet, I encourage you to give it a shot yourself. Getting started is a lot easier than most people think. You'll find the ideas start to flow after the first few sketches.
Experienced information architects and designers will be able to create more advanced prototypes quickly of course. Perhaps you need a consultant to take you through a requirements planning workshop, or perhaps a simple verbal brief will be enough for a consultant to help you design the system. Either way, trust in the fact that budget spent prototyping is well invested. You'll save big bucks fleshing out your ideas and ironing out design flaws before graphics are created or code is written.
We can help, of course! Get in touch.