Prototyping for Software Applications and Websites
Over the years, we’ve learned a lot about how software works, and we’ve learned a lot about how it doesn’t work. Sometimes our knowledge comes from a well-orchestrated development plan and sometimes the lessons have been from a series of things that went wrong. One thing that we know – prototyping is an important first step for almost any project. From simple doodles on the back of a cocktail napkin (formally called “paper prototyping” ) to mocking up an application using a RAD tool, the benefits almost always outweigh the effort.
There are several purposes for a prototype, but they basically boil down to “showing the design” or “establishing functionality”. Essentially it’s the way a designer or programmer communicates their vision of how things will look and feel at an early stage of the project. Often this vision doesn’t match what the end-user was expecting and a prototype is a good way to smooth things out and further define details of the project. The earlier these issues are addressed, the quicker changes can be made (and with less cost).
One of the nice side effects of a prototype is clarifying random thoughts and making it easier to work the design out in your head. Putting things on paper (even the electronic kind) requires extra organization that helps crystallize ideas and show potential problems. A prototype is also useful for limiting the scope of a project and verifying that you’re not adding features that are unnecessary or will be too costly to implement. It’s fun to “blue sky” a software project, but at the end of the day someone has to code it.
Earlier I said “almost any project” should be prototyped, but there are certainly times when a prototype isn’t required:
- For a revamp of a product that’s already complete, the existing software can be used as a launching point for the new version (effectively the previous release is the prototype).
- For an intranet or program that will only be used internally, a full usability analysis may be overkill since the users are typically more forgiving of a few behavioral issues.
- Some projects are so small that iterating over the design would be less time-consuming than a prototype. A one-page website that acts as a placeholder, for example.
These situations aside, a prototype will almost always help the overall development effort.
The first step in prototyping is to define the purpose of the prototype. In website design, the prototype is often a simple mockup of the proposed colors and layout. When we designed a social networking website, which had a lot of pages and a sophisticated navigation mechanism, we felt a flowchart of the links was necessary. Look around the internet for examples and you’ll see there are a lot of great UI wireframes and mockups.
Everyone should understand the purpose of the prototype before work starts. If the goal is to sketch out navigation, then the client should know that the color scheme and layout aren’t important at this stage. It’s easy to throw together a mockup of a full software program using a RAD tool, but the client needs to understand that there’s a big difference between the prototype and a finished program. Tell them before you start, when you’re done, and again when you present it. Like voting in a Chicago election, do it early and often.
The second step for making a prototype is deciding who the target audience will be. StripedCow usually creates a prototype for clients, but it’s also a valuable tool for communicating to the rest of the team. A designer can let a programmer know how the navigation should work or a programmer can put together a simple tool to show the designer what interface elements might be needed. Don’t underestimate the power of having everyone on the same page, I’ve never heard of a project that failed from “too much communication”.
The third step for prototyping is figuring out the “how”. Whatever you use to prototype, make sure it will address the goals of the prototype. An iPhone app can easily be prototyped with 3×5 index cards – they’re a little bigger than the iPhone screen, but index cards are the right aspect ration and they’re easy to work with. You can write on the lines and draw on the blank side, which makes for a useful tool that you can pick up almost anywhere. A similar option is to use sticky notes, which make it easy to reorder screens and also come in a 3×5 size. There are a stencils, sketchpads, and other options available as well.
If colors and layout are important, then an image created with Photoshop is perfect. If it’s a more complex question, or something involving usability, then a tool like Flash might better demonstrate the flow of the product. If the project is extremely complex, then taking time to create an application might be required. This might seem like a lot of work, especially since we tend to throw out the prototype when development starts, but it’s worth putting together something even if we have to cut corners at this stage of the process.
There are several RAD tools available for making a more functional “thick prototype”, each of these tools has their own strengths and capabilities. For developing a desktop business application, we’ve used GTK+ to build the user interface, then coded C/C++ internals to show how the screens would operate. This has a huge impact on establishing the look and feel – from button placement to deciding where to use a drop-down listbox and where to use a tree view.
One trick that we’ve learned – since the prototype is meant to be disposable, use a programming language or technology that isn’t going to be used in the final product. For example, we built a prototype for a remote logging application using the Lua scripting language and wxWidgets for user interface elements. Neither one of these were going to be used in the deliverable, so the programmer felt the freedom of putting things together quickly knowing that it was all “throw away” code. This greatly sped up the prototyping phase and allowed more experimentation with how the product would operate.
On the other end of the spectrum, paper is cheap and easy to use. Plus there’s no need to worry about system incompatibilities, versus prototyping with something like SilverLight. Paper also has a big advantage – it’s obviously not the product. Balsamiq understands this – they’ve created an easy to use tool for building mockups, but they’ve cleverly used a “sketch” look to show that the prototype is not to be taken as a “complete” project.
There are dangers to prototyping, but for the most part they’re easily managed.
- Often the prototype will take too long, as the designer or programmer strives to make it perfect. Review the requirements for the prototype and verify the time is being spent wisely – don’t use time on features that are not being demonstrated by the prototype.
- The client thinks the project is farther along than it is, usually accompanied by “that’s great, let’s update the web server”. This is a matter of properly setting the customer’s expectations – tell them up front and tell them again the goal of the prototype and how it relates to the actual product.
- When the prototyping is complete, the team might not be flexible enough to allow for changes to the design. While the prototype is a great communication tool, it shouldn’t be considered “engraved in stone” and everyone should be prepared to evaluate last-minute changes.
- The prototype is a failure and nothing that was mocked up works as well as expected. This is actually a good thing. One of the main purposes of the prototype is to prove what works and what doesn’t – it’s better to find out at an early stage that the concept is flawed. Again, the earlier things are found, the cheaper it is to fix.
There are no hard and fast rules for picking the right media, understanding the goals, or knowing when you’ve spent enough time prototyping – these things are learned through experience. But I think you’ll find the rewards are worth the effort – successfully implementing a prototype will greatly facilitate development, cut costs, and lead to a better product and happier clients.