 |
|
 |
|
|||||||||||||||||||
|
by Jonathan Simon | |||||||||||||||||||
Interaction Happens: Prototyping Techniques | ||||||||||||
| ||||||||||||
|
See if this situation rigs a bell: a manager tells you to build a proof of concept to test the look and feel of a new application. You hack for a week straight, day and night, producing some of the ugliest code you have ever seen to make the Big Demo. After all of your hacking, the meeting is a huge success and everyone loves your prototype. Then someone asks you how long until the application is deployed. You respond with a reasonably worked estimate of six to nine months. The feeling in the room quickly changes like someone just stopped the music in a bad 80s show. No one understands why its going to take nine months to build something that they already see in front of them. No one is happy anymore. Uh-oh.
What's really going on in this story is full-fledged, high-fidelity prototyping (don't worry, I'll explain what the "high fidelity" means in a bit). This approach to prototyping has some dangers that were not mitigated and led to potentially dangerous circumstances.
This article takes a high-level survey of some of the standard prototyping methods. You'll learn a little about each of the methods; where they work, and where they don't. Wherever possible, I'll embellish this with examples of the different prototyping methods, from my experience and others'.
Why Are You Prototyping?
First, it helps to figure out why you are prototyping in the first place. You'll be more informed when choosing a prototyping method the more you know about why you're prototyping. Here are a few popular reasons as example (your actual reasons will vary).
- Getting "buy-in" from stakeholders.
- Helping business analysts gather requirements.
- Running a usability test before full production.
- Testing an architecture.
- Testing a series of interaction widgets (a new text field, for example).
- Designing by tinkering with working code.
- Resolving flow issues when all you have are some screenshots of what your application is supposed to look like.
Keep in mind that this article focuses on interaction design in prototyping. So although testing an overall system architecture code is a reasonable thing to do, we'll call that more of a proof of concept rather than a prototype. With that in mind, it's also important to consider your working environment. Here are a few example questions to ask yourself.
- Are you working on an internal project or do you work for a product vendor?
- Are you in a hostile work environment, or is there a fair amount of trust?
- Are you working under very strenuous deadlines?
Keep all of this information in your mind as you read the rest of the article. This is also a good time to decide whether or not to prototype at all.
To Prototype or Not to Prototype
There is a recurring debate in software development about whether or not to prototype. This is the same type of religious argument that wages around which IDE you currently use, type-safe versus non-type-safe languages, object-oriented versus functional programming, native versus custom look and feel, and so on.
Proponents of prototyping make the point that prototyping helps with upfront design, making development easier since everyone knows what to build up front. In practice, I've found that analysts and managers tend to like prototyping because it gives them something tangible--however unreal--to latch on to. This can be a great help in facilitating requirements-gathering from users. Prototyping can also help analysts write requirements docs.
Opponents of prototyping are often realists who see too much prototyping as a time drain, if not a complete waste of time. Full upfront prototyping with complete specs before development fits the waterfall development methodologies and is generally out of favor these days. Things change during development, as preconceived usage changes and corner cases are discovered, often rendering prototypes irrelevant, or at least of less useful than previously thought.
Agile development avoids prototyping almost entirely by iteratively honing in on a UI design with the code. This works well for internal software development with understanding users. It's more difficult for product vendors who don't really have the leeway for iterative releases. Product vendors often have one real shot at the market with an innovative product. It has to be right, or at least really good, right out of the gate.
But there is a middle ground. There are many tools and techniques for prototyping. The best thing to do is look at the different prototyping methods, analyze them according to your product and organizational goals, and use what you can.
Fidelity
Interaction designers and usability specialists often break down prototyping in terms of fidelity, specifically high and low fidelity. Fidelity refers to how responsive a prototype is.
High fidelity prototypes are "working" applications--you press a button and something happens. I say "working" because high fidelity just refers to something happening. It doesn't mean that it really works, functionality-wise. There is an assumed majority of smoke and mirrors. False back ends and embedded screenshots are all fair game. The goal is to give a realistic taste of what your application is going to look and feel like.
Low fidelity prototypes, by contrast, are non-functioning. Examples of low fidelity prototypes are screenshots and sketches. An extreme form of low fidelity prototyping is paper prototyping. Obviously if something is printed on paper, buttons aren't going to work, at least not yet.
High Fidelity and Java
If anyone has ever asks you to do a screen mockup in Java, you are building a high fidelity prototype. As a Java developer, you probably tend to lean towards this approach, because it's what you know. That's not necessarily a bad thing.
Pros
- Like the final product.
- Good for stakeholders, venture capital, etc.
- Give you a feel for the technology while designing.
- Lower design risk.
- Sometimes a good option for modification to a current system.
Cons
- False sense of completion.
- Time consuming.
- Difficult to change.
- False sense of security.
- Time sink! You can spend all your time tweaking the prototype. It's hard to make a hard split.
If you decide to go with high fidelity Java prototypes, there are a couple of things you can do to mitigate some of the larger risks. Consider the false sense of completion as an example. First, you could do a watermark with PROTOTYPE in big bold letters plastered on your application. Watermarks and their implementation are explained in detail in "Interaction Happens: Thinking Graphically." Figure 1 shows the Java Web Start management application with a watermark indicating that it is in development.
Figure 1. A watermark to reinforce the prototype status
Believe it or not, sometimes this kind of reinforcement alone can remind your stakeholders and users that this simply isn't the real deal yet. If that's not enough, you can go the extra mile and give the Napkin look and feel a shot. This is a Swing pluggable look and feel (PLAF) that makes your applications look hand-drawn. Figure 2 shows a screenshot of Sun's SwingSet demo in the Napkin look and feel.
|
|
HTML can be an interesting choice. It runs in the browser, so all of your users, testers, and stakeholders can use the application before you figure out how your installations are going to work. Also, a lot of people in this day and age are familiar with at least basic HTML, and therefore non-programmers at your company could probably work on the prototype a bit. There are also a number of tools for building websites at your disposal: Dreamweaver, FrontPage, etc. If you're building a web client, this can probably work. If you're building a rich standalone application, you could run into some difficulties prototyping as a thin client and building as a standalone application.
Another option would be to prototype in another high-level language like C++ or .NET. The problems here are very similar to prototyping in Java, except that you have the extra complexity of managing a different development environment. That can be very resource-expensive. Also, all you're really saving is the demand that you turn your prototype into production code. At the same time, you run the risk of someone doing that anyway, then all of the sudden you end up writing your application in an entirely different language. Stranger things have happened.
Low Fidelity
At its most simple, a low fidelity prototype is something that doesn't run. This could be anything from a screenshot to a napkin drawing. Low fidelity prototypes are great because they are faster to develop than high fidelity prototypes. On the downside, they sometimes leave a little to be desired in communicating the interaction of your system. Also, your prototype idea might not be completely finished, and that might be OK. You may have a few flows that are yet to be analyzed. It's much harder to hide such issues with a high fidelity prototype.
Pros
- Quick to make.
- Fast and easy to change.
- You can leave more design unfinished.
Cons
- Usability testing more difficult.
- Stakeholders may be less comfortable with this.
- Easy to miss flows that would be obvious with a high fidelity prototype.
Wireframes
Wireframes are the extreme form of low fidelity prototyping. Simply put, wireframes are black and white outline sketches of an application. On the upside, they are the quickest to make and assume the least about the final application product. On the downside, they can be hard for new users or application stakeholders to wrap their heads around. Figure 3 shows a fictional wireframe prototype of Java.net if the "Community" link were replaced with a new "Blogs" link.
Figure 3. Java.net bloggers page prototype, wireframe style
Use wireframes when:
- You are brainstorming.
- You don't care about the finished look as much.
- You have visionary stakeholders that don't need to see the finished look.
- You are doing rapid internal releases so you don't need all design completed upfront.
Screen Capture Mockups
For lack of a better term, "screen capture mockups" refers to making a realistic-looking picture of the final product using a graphics application. This is a middle ground if you want a little more realism than a wireframe prototype, without going to a full-fledged high fidelity prototype. These often work well when you're taking an existing system and making enhancements that don't require high fidelity prototypes. Screen mockups might be a good choice for the new blogs page prototype on Java.net, since it's already live. This way, you can take a screen shot of the current Java.net and use a graphics tool like Photoshop to add the new page. Figure 4 shows a Photoshop-edited screenshot of Java.net with the new fictitious "Blogs" page. Notice that all of the content is in place. It looks exactly how it would look if it were real.
|
|
Remember that these techniques are not mutually exclusive. Imagine a scenario where you plan on using wireframe prototypes for a series of usability tests. Stakeholders are nervous and anxious to see the final product. You could always run the usability tests with wireframes and create a select few full screen mockups that look as if they are screenshots from a finished product.
As with the high fidelity prototypes, I can't stress the importance of reinforcement of the prototype status. If your screen mockups are good, someone might think that your screen mockup is actually a screenshot from a working product. I've gotten in the habit of always using watermarks on screen mockups when they leave my desk. This reminds people that it's not a finished product. Notice the "prototype" watermark.
Use screen mockups when:
- You are testing your product for marketing purposes.
- You are testing with users that might be uncomfortable with the unfinished look of wireframes.
- You are building a very graphics-intensive application (graphs, diagrams, etc).
- Your management wants a better feel of the overall appearance of the application.
Be aware that some don't make a distinction between what I'm referring to as wireframes and screen mockups. I have often seen realistic-looking screenshots referred to as wireframes. I think it's important to make a distinction between these two types of low fidelity prototyping, since they have different benefits and drawbacks.
Paper Prototyping
One of the common objections to low fidelity prototypes is usability testing. Carolyn Snyder explains an interesting approach in her book Paper Prototyping, which is also the term for prototyping a working system with only paper. Imagine you're testing the navigation of a website. There are a finite number of pages in the site. You could then test the navigation by asking them what they would click on, then replacing the page printout in front of them with the page in the web site that they would have navigated to if they had actually clicked a button. This way, you can still test workflows and navigation without building a high fidelity prototype, or even running a computer in a usability test! This can be powerful, not only because it gets people's heads out of the computer, but also because it makes logistics easier--all you need is a couple of paper printouts to run your test.
Fidelity Purgatory
There are a number of applications that ride the line between high and low fidelity prototyping tools. These are mostly applications that are built specifically for prototyping. A good example of this is Visio's application builder. It puts a suite of Windows components at your disposal: buttons, scrollbars, window frames, and more. What's more, you can build multiple screens and connect them together by assigning actions to the components. This way, you click on a button and you actually move to another screen, giving the impression of real functionality.
The upside of this is that you get some of the benefits of a high fidelity prototype (realism, for example) while bypassing some of the more serious problems like having a manager demand that you put prototype code into a production application.
You can't build a real working application in Visio's application builder, but you can make a semi-decent, semi-high-fidelity prototype for basic applications. In practice, I've always shied away from this approach because of its inherent limitations. These prototype builder applications usually work for basic applications. But as soon as you want to do something out of the norm (like a custom graphical data display, for example), these applications can run into difficulty. And that doesn't even account for the learning curve for a custom prototyping application that doesn't have proven longevity. Even as I say that, I think this is an interesting space to watch. There could be a great prototyping tool developed in the future that'll solve all of our little interaction designer woes.
Wrap-Up
The first step in prototyping is trying to figure out what you want to accomplish. Are you just getting stakeholder buy-in? Helping your analysts visualize the system to help them gather requirements? Screen mockups or wireframes might do the trick here. Then consider your corporate climate. Do you work at the type of place that would make you put high fidelity prototype code into production? If you do, stay away from high fidelity prototypes. Or at least make it clear with a watermark or the Napkin PLAF that the prototype is not a real application. Finally, consider the project you're working on and what it needs. Are you testing website navigation? You can do this pretty effectively with paper prototyping (wireframes or screen mockups). Or are you testing marketing strategies and overall effect? In that case, you might be better off building a basic engine with several skins and testing them once your project is getting closer to completion.
When choosing your strategy, just consider all that you want to accomplish with prototyping, your corporate climate, and your specific project. Consider the strengths and weaknesses of each approach. And then come up with a plan using one or more of these strategies. In general, I always suggest leaning towards the least work in your prototypes. Favor low fidelity over high fidelity, and wireframes over screen mockups. You want to spend as little time prototyping as possible. The more detailed you get in your prototypes, the harder they are to make, the harder they are to change, and the more expectations are created.
Links
- "Interaction Happens: Thinking Graphically"
- Paper Prototyping: website for Carolyn Snyder's book of the same name
- "Paper Prototyping: Getting User Data Before You Code," by Jakob Nielsen
Jonathan Simon is a developer and author specializing in user interaction.
Read more Interaction Happens columns.
 |
View all java.net Articles.
 java.net RSS Feeds
|
