4

Good Design

“It takes less time to do a thing right than to explain why you did it wrong.”

—H.W. Longfellow

Topics Covered in This Chapter

Good Design Goals

Are Designers Against Users?

Paper Prototyping and Storyboarding

Good Documentation Design

As you put together your business case, your stakeholders may ask what you mean by good design. What does good design mean, and why should they care?

Users’ desires and constraints are different from those experienced by designers. There is a disconnection between users and designers that you and your project team need to bridge as you develop your interface. Good design is presented as four goals that you should always adhere to when you design your user interface: ethical, purposeful, pragmatic, and elegant. (The next section discusses these goals in more detail.) Adopting the four goals of good design as you create the user interface design is what you need to resolve this disconnection.

One effective way to design your user interface to meet your goals is to engage in paper prototyping and storyboarding, which allow you to create mockups of the user interface designs that you and your team are discussing. Paper prototyping is a form of usability testing that you can work on with your team as well as with focus groups of users. Although paper prototyping lets you quickly create tangible ideas that others on your team can look at and think about, it is not the best tool for all situations. This chapter will look at what paper prototyping is and when it is appropriate.

Finally, you’ll learn about good documentation design, which is another important goal if your product is to succeed. A significant amount of documentation is now available as online help. A good design for which users can find online help—or help of any kind—is your company’s first line of customer support. You’ll also learn the steps you need to take to develop and rigorously review the documentation before your product is released to the public.

This chapter ends with a reinforcement of what you learned about good design in Chapter 3, “Making the Business Case.” It also explains why good design doesn’t end with the first version of a product you’re developing. In fact, if you’re creating subsequent versions of a product, adhering to good design is vital if you don’t want to alienate your customers.

Good Design Goals

Robert Reimann, Hugh Dubberly, Kim Goodwin, David Fore, and Jonathan Korman developed a list of the four top-level good design goals for general design work (Cooper and Reimann, 2003). These goals are important whether you’re designing software or furniture. If you adhere to these four goals, whatever you’re designing has a better chance of being accepted by others:

• The design must be ethical.
• The design must be purposeful.
• The design must be pragmatic.
• The design must be elegant.

So how do these goals apply to user interface design? Cooper and Reimann (2003) applied the four goals to user design as follows, and I’ve added a few tips of my own:

• Ethical—The user interface design should do no harm—that is, it shouldn’t make users’ lives harder than it already is. You should develop your user interface so that it actually helps improve your users’ lives. For example, an interface should not include unnecessary information that distracts the user and makes him less efficient in completing tasks.
• Purposeful—The user interface should help users achieve their goals in using the software. Having a purpose not only means helping users achieve goals but also understanding their limitations so that you can strengthen your users as much as possible. You can learn about the purpose of your users by understanding how users behave; you will explore this further in Chapter 5, “How Users Behave,” in the process.
• Pragmatic—Create a user interface design as early as possible to meet the requirements of the stakeholders that I discussed in Chapter 3. By ensuring that you are aware of and regularly discuss the requirements and needs of all the stakeholders—users, engineers, marketers, and managers—you can create a design that meets all stakeholder needs. It takes time to overcome the gap between users and designers, and I discuss that gap in greater detail later in this chapter.
• Elegant—The user interface design must be as efficient as possible. In other words, if a function in your interface is accomplished with two clicks, try to get the function down to one click. This is especially true of Web site design, because visitors can lose interest in your site quickly if they have to keep clicking to find something.
  Elegance also means that all parts of your interface must feel like they work together as part of a whole, not disparate parts cobbled together, because incoherence can breed confusion and frustration among your users. Later in this chapter, I discuss how paper prototyping and storyboarding help you create a consistent interface for your product on paper before you start the actual building process.

You’ll learn more about applying interface principles and patterns that adhere to these good design principles in Chapter 7, “Designing a User Interface.”

Are Designers Against Users?

Designers and users have fundamentally different goals when it comes to design of any kind, and that includes user design. For example, designers actually design the product, and they’re intimately involved with its development. Users, on the other hand, don’t use the product until it’s finished, and they may not agree with the designer’s sense of design. Ultimately, however, it’s the users who decide whether to plunk down their money to purchase the product.
These fundamentally different goals create a disconnection between users and designers that must be addressed and overcome before you can create a good user interface. Both users and designers have different constraints placed upon them that the project team needs to recognize at the beginning of the process so it can overcome them. If it’s not possible to be constrained this way, the project will fail.

User Constraints

A user is faced with a number of constraints imposed by the physical world (Norman, 2002). These constraints can be grouped into five areas:

• Physical—For example, you can sit in a car only one way.
• Semantic—The meaning of the situation causing the constraint. For example, the driver’s area in a car is designed in such a way that the driver can only drive the car by sitting in a certain position so she can reach the pedals, the steering wheel, the transmission controls, and so on.
• Cultural—For example, if you’re developing a car for international markets, there are different cultural issues that have to be addressed, such as the fact that drivers in some countries drive on the left side of the road, and drivers in other countries drive on the right side of the road.
• Logical—For example, my father and I put together a crafting table from a kit for my mother’s craft room recently, and we logically concluded that because the kit required assembly, all parts that came with that table must be used to construct it.
• Social—This constraint might be pressure not to admit mistakes or admit that you don’t know something in front of others because you don’t want to look dumb in a social gathering.

Designer Constraints

Designers have constraints of their own to deal with, which may divert their attention from users’ considerations and constraints. Designer constraints include the following:

• Time—Designers may be facing only a limited amount of time to produce the product because of user expectations or because of an artificially imposed deadline set by others in the company.
• Individuality—The desire for individuality is strong within all of us, and it’s easier to think about ourselves than about others even without thinking about it. Therefore, the designer may think about designing a product that he would find aesthetically pleasing.
• Pressure from above—Designers may be receiving directives and pressure from others in the company to create “the next iPod” and bring the company awards and recognition instead of something that he finds functional and useful.
• Serving a different user base—The designer may not design the product for external users directly but may only answer to internal users such as the engineering department. The designer may also deal with only one subset of customers, even though the product will be used by consumers at large.
• The designer thinks he is a typical user—The most important constraint is that the designer thinks of himself as a typical user; therefore, he designs to what he thinks is the best design for him. The designer doesn’t think or realize that he is not in a position to determine all usability factors for all the product’s current and potential customers.

Bridging the Gap

The ideal method for overcoming these issues is to bring them up when the product development process starts and resolve them before you begin design work. This is not always feasible. For example, you may come into a situation where there are severe artificial time constraints to get the product out the door quickly, and no amount of persuasion will get people to change their minds. There could also be political issues involved, where some people won’t be challenged about their assumptions and directives because of their position within the company.

When you come into a situation in which there won’t be many changes in the current development cycle, make sure you can obtain as much customer feedback about the product as possible. You can do this yourself, or you can talk with other departments such as marketing about what feedback they’re receiving from current customers and prospective customers at trade shows.

The more information you receive, the more you’ll know about whether you or the designer(s) who designed the product accurately represented users’ needs. If they didn’t, you can come better prepared to make your case when the product is upgraded and for the development of other products.

Paper Prototyping and Storyboarding

You may have heard or read about how movie studios create storyboards that show the various scenes of a potential film, particularly an animated film. A storyboard puts ideas on paper and then puts the papers in a certain sequence to provide a concept of how the film will play out. It also gives the production team an opportunity to look at the concept and make suggestions for improving the film before it takes its final form.

In user interface design, there is a more interactive version of storyboarding called paper prototyping. Paper prototyping involves creating a paper version of a software program, hardware product, or Web site so you can learn how users interact with the design before you develop the product. The paper version is easier to create, and it gives you some additional flexibility, such as the ability to move an object from one location to another on the page in response to user suggestions.

Much of the material in this section is based on Carolyn Snyder’s 2003 book Paper Prototyping. I’ve also added some information about other issues that may also come up during the paper prototyping process, such as accessibility and the needs of different user segments. These differences may require you to produce several different paper prototype tests, or decide not to give a paper prototype test at all.

---

Note

You can view Carolyn Snyder’s Web site about paper prototyping at www.paperprototyping.com.

---

Paper prototyping offers you and your design team an opportunity to test the design without expending a great deal of money. You will encounter skeptics, but this section will discuss how to overcome them.

What Paper Prototyping Is . . . and Isn’t

Snyder (2003) uses the following definition of paper prototyping as a variation of usability testing, where representative users perform realistic tasks by interacting with a paper version of the interface. That interface can be anything that requires human-computer interaction, or interaction between the user and the hardware if the user is testing a hardware product.

The test is controlled and interactive. It can be given to several users at the same time or to an individual user. The test is moderated by a facilitator, who doesn’t explain to the representative users how the interface is supposed to work before the test takes place; the test is designed to simulate a real-life situation.

The paper interfaces can be hand drawn, printed screen shots with additions or deletions, or even a hardware product with some added paper buttons pasted on to mimic new functionality. One of the testing team members acts as the computer or hardware product and provides feedback based on what the user does with the paper interface.

Paper prototyping contrasts with similar activities that vary in interactivity, including these:

• Producing mockups of the product you’re going to produce, either on paper or in a graphics file. For example, you can create mockups that show how different elements and different pages of a Web site will look. Mockups are completely static—that is, you can only look at them, not interact with them.
• Wireframes, which can be Web site page layouts or software window layouts that show where text, graphics, links, buttons, and other elements will appear on the page. A wireframe page can include active links to other wireframe pages or windows, thus providing a more interactive idea of how the pages or windows will work together.
• Storyboarding, as discussed in the introduction of this section, where you create different pieces of paper and show how each piece of paper is related to the other, either in a linear fashion or in a decision tree structure. Storyboarding is also a static tool.

Overcoming Skepticism

Stakeholders such as your project manager and designer may wonder why you have to create a paper prototype to get user feedback. Snyder (2003) asked this question to a number of her classes she teaches in paper prototyping, and the concerns fell into one of four categories:

• Validity—Does paper prototyping find the problems we hope to find? And are there problems we can’t solve with paper prototyping that require one or more additional or different tests?
• Bias—Does paper prototyping change user behavior in such a way that we can’t trust the results? Will behavior change dramatically after the user tests the design on the computer?
• Professionalism—Will paper prototyping result in the project team or company looking unprofessional and sloppy?
• Resources—What’s the return on this investment (ROI) of time, money, and resources?

The skeptics are not trying to make you look bad. You should show respect to them because they are sincere in bringing their concerns to you. However, be prepared to answer their questions and assuage their concerns. Snyder (2003) suggests several ways to deal with your skeptics to address questions in one or more of the following four categories:

• Create a sample paper prototype to show people how it works. After people see what a paper prototype looks like, they can better understand how the test works. After the skeptics see the prototype, they may provide feedback that could make your prototype even better. Also, be up front about the disadvantages of the paper prototype tests, and provide suggestions for additional tests that can address problems that paper prototyping cannot resolve.
• Have influential people in your company test your sample paper prototype as mock users. Walk through the paper prototype with those influential people so they can experience the benefits of the paper prototype test firsthand. Ask those people for feedback so you can make changes to the prototype before the actual test. By testing your paper prototype beforehand, you can identify any problems with bias and ensure that the paper prototype tests meet your goals.
• Seek support from sympathetic departments, and invite anyone from those departments to your paper prototyping activities. For example, the sales and marketing department (or departments if they’re separate) will likely be interested in your results and may want to participate in the paper prototype tests as subjects or observers. People who are interested in your paper prototype will be willing to give you more direct feedback and also work with you to provide the best ROI figures to win over skeptics.
• Ask for feedback at the conclusion of the paper prototyping test to help assuage the concerns of any skeptics who still aren’t sure about the benefits of such a test. For example, to enforce the look of professionalism with your paper prototype, use heavier paper or cardstock to make the prototype more resistant to wear and tear during testing.

Advantages

As you implement the feedback you received from the sample paper prototype test and report back to your stakeholders, be honest with them about the advantages and disadvantages of paper prototyping.

Encourages Better Planning

The biggest advantage of paper prototyping is that you will have a better idea of how your users use the product. However, you must also be aware of all your potential customer segments when you create the test, because a number of factors affect interface use (Thatcher et al., 2002, Brinck et al., 2002). These factors include the following:

• Needs for people with disabilities—Between 15 and 30 percent of the general population have functional limitations that affect how they use technology products—and that translates to more than 50 million people.
• Different market segments may have different needs—For example, there is the increasingly graying demographic in the United States as the “baby boom” generation nears retirement age. Although these baby boomers are computer savvy, there may also be functional limitations here as well (such as eyesight issues) that can affect how you design your product.
• Cultural issues—If you’re designing your product for use in more than one country, there are cultural issues like different conventions and symbols used to communicate a concept, not to mention different languages.

If you know these factors before you create the paper prototype test, you can create a test that takes your customer base into account.

For example, if you’re developing a user interface for multiple cultures, you can have the same interface on a piece of paper but have separate paper buttons with symbols attached with a piece of tape. When you use the paper prototype with people from another culture, you can detach those buttons and replace them with other buttons with culture-specific symbols, like the Cyrillic language for Russian speakers.

Resolves Problems and Encourages Creativity

Paper prototyping provides substantial advantages (Snyder, 2003). Paper prototype tests produce substantive user feedback early in the development process. A paper prototype also doesn’t require technical skills; the user can simply manipulate the piece(s) of paper as necessary to perform a task. Therefore, users find the process less intimidating, and they feel more comfortable giving feedback.

You can invite coworkers from multiple disciplines and departments to participate in the test either as observers or as testers. This results in multidisciplinary communication earlier in the development process, which in turn promotes greater collaboration and the exchange of ideas.

The user feedback from paper prototyping also helps your development team by promoting communication between the development team and users taking the test, which in turn helps resolve design misconceptions and encourages development creativity produced by user interaction. For example, if the user finds a problem, the tester can quickly make changes to the interface, such as erasing a design element on a piece of paper and redrawing it somewhere on the paper. The design team can then make a note of that for further discussion.

The Results

When you approach the stakeholders, they will want to know what paper prototyping will expose in the design. Following are problems that paper prototyping is likely to find (Snyder, 2003):

• Unclear concepts and terminology.
• Problems with navigation, work flow, or task flow.
• Content issues that can lead to refinement, which leads to a better design that sends the right message.
• The way the user expects to find and use product documentation.
• Functionality issues.
• The layout of objects on the screen on the hardware product. Objects can include text, windows, and buttons.
• The effectiveness of the product. If the product isn’t easy to use, it won’t be effective.

Disadvantages

Paper prototyping is not appropriate for all situations. Some situations may call for a different type of usability testing or for further testing.

Different Testing

The following list of situations should be indicators that you may not want to promote paper prototyping but a different type of usability testing instead (Snyder, 2003):

• There are only a few people working on the project, or there aren’t enough people in the company to conduct a paper prototype test.
• Everyone is familiar with the technology used in the product.
• The development team is close by or can test the product remotely.
• You can easily set up a test environment to create a different type of usability test in the early stages of the development process. For example, you may be testing an upgrade to a software program that’s already set up in your company’s training room, so it will be no trouble to install the upgrade version.
• The development team can control everything the user sees.
• The user doesn’t have to sit through long delays (a minute at most).
• Usability testing can wait until the middle or end of the development process. For example, if your team is producing a software upgrade, the testing for that upgrade doesn’t need to be done early in the development process.

Further Testing

Unfortunately, paper prototyping is somewhat static, and you can’t replicate some dynamic features such as scrolling in a paper prototype test. You should also point out to your stakeholders that paper prototyping is not a substitute for full user testing of the actual software product, hardware product, or Web site. It is, quite simply, a first-phase development tool.

When you report to your stakeholders, you need to identify what other questions need to be answered through further usability testing and inspection (Snyder, 2003). These issues include the following:

• Scrolling and link rollover issues. A paper prototype test doesn’t show dynamic responses such as what happens when you scroll down a list or what happens to a button when you move the mouse pointer over it.
• Long documents and lists. For example, if you have a long list of options available, wait until you have the entire list finalized in the software, hardware, or Web site so the user can scroll down the list.
• Keystroke, mouse, and other input errors that the user makes when using the product.
• Keyboard or mouse preferences. For example, your users may have different ideas for keystroke shortcuts, such as pressing Ctrl+S to save a document.
• Long download times, screens that take a long time to load, or a function that takes a long time to perform. For example, if a Web site takes a long time to load, you can’t replicate that in a paper prototype test.

Good Documentation Design

In Chapter 3, you learned that documentation is not only part of the complete user experience, but it’s also part of the first line of customer support for your business. Users who run into problems usually turn to the documentation first for help. If they can’t get help, they may call your company for answers, and poor documentation factors directly into customer support costs that account for as much as 60 percent of a high-tech company’s total costs.

Unfortunately, your development team can fall victim to the same argument about documentation that it does about usability testing. That argument usually goes something like this:

You: “We need documentation for our software so our users will know how to use it.”

Developers: “But the software is so easy to use that we don’t need documentation!”

Just like usability testing, a rejoinder to this documentation argument can be hard to come by, because the developers are right—if your development team members are the only people using the software. That, of course, is part of your answer: Documentation is for other people—the users.

Create a Documentation Plan

The financial benefits of having good documentation make for a powerful argument, but that argument isn’t enough. You need to have a complete documentation plan developed and ready to present to your stakeholders before you approach them. When you promote documentation, you will need to identify who you will work with to develop the documentation as well as what documentation you need to develop for your users.

Just as when you start a road trip, you need to put together a map and plan ahead. For documentation creation, there are eight steps that compose a documentation map.

Step 1: Create Your Documentation Team

Before you know what to create, you need to build your team. Your team not only includes more than one or more technical writers, but you also have to know who your subject matter experts (SMEs) are. Many of those SMEs will be on your project team, but some won’t be. For example, you may have other engineers who have knowledge you need but aren’t on the project, and you may want to consult people in the sales or marketing departments.

After you identify the technical writer(s), if any, as well as your SMEs, you need to do some scouting by talking with them or their superiors to find out if they will be available to help you construct documentation. If so, you should determine when those people will be available (some may be working on different projects that have a higher priority than yours) and how they prefer to be contacted so you can get the fastest response possible to your queries. Some people like to be contacted by phone, others by e-mail, and others like to meet face to face.

If the people you want to bring into your project won’t be available, you should bring up this issue with the rest of your project team, and perhaps some executives, about how you should get around the problem.

Step 2: Create a Checklist for Your Project Team

After you have identified your documentation team, you need to work with that team as well as members of your project team to create a documentation checklist that answers two questions:

• What type(s) of documentation does your company need to create?
• What information do you need for the documentation?

Documentation comes in many forms:

• Paper documents—In an October 2000 article in Scientific American, Steve Mirsky reported that people have an easier time reading paper documents than online documents because reading online requires different brain skills. However, there is a generational aspect to paper versus online documentation, because many younger people have grown up reading online and may have better developed skills for reading online documents.
  The advantage of paper is that you can hold it in your hands, as shown in Figure 4.1. This is important if the user wants to read the documentation when a computer is not available or wants to use tangible, interactive tools like a highlighter or a bookmark. What is more, if you have a hardware product, paper may be the only media you can provide for your documentation. The disadvantage of paper is cost. Paper prices keep rising; therefore, the costs for printing (and perhaps binding) documentation at a print shop also keeps rising.

Figure 4.1. A print documentation sample.

• Portable Document Format (PDF) files—PDF is the de facto format for sharing, displaying, and printing formatted documents. Adobe System developed PDF and currently maintains the standard. Adobe allows anyone to download the free Adobe Reader program to view PDF documents on many platforms including Windows, Mac OS, Linux, as well as major handheld PC operating systems such as the Palm OS.
  PDF is a good way to provide documentation that looks like a printed document that users can print on their printers without having you print the documentation yourself, as shown in Figure 4.2. PDF files are also portable, so you can put them on your software product CD-ROM as well as make the PDF file available on your company’s Web site.

Figure 4.2. A sample PDF file.

• Online help—Online help can take different forms. It can be incorporated into a software program, or it can be a standalone file that is accessible on the Windows desktop or from the Web, as shown in Figure 4.3. Help creation software such as RoboHelp can create one help system and then convert that system to a number of formats including WebHelp, which is HTML-based help that you can view in any modern Web browser on any computing platform. You can also create help desk support modules from your online help for use by your customer service staff.

Figure 4.3. A sample online help window.

The disadvantage of online help is that it usually isn’t designed to provide quick access to the specific information that people require. Many companies also don’t realize that online help has different design challenges; therefore, those companies simply create a user manual in online help. Furthermore, for those who like to view paper documentation, online help usually doesn’t format well when printed, unlike PDF documents.

• Web site—A Web site can be one that is available to the public, a private Web site that is accessible only by entering a user ID and password, or an intranet that is available only to customers within the company. Many company Web sites, such as the Adobe product support Web site shown in Figure 4.4, have additional customer support information available, including documentation files, technical support issues, and frequently asked questions (FAQs), which list commonly asked questions and answers. It is tempting to replace customer service with a Web site. The disadvantage is that if the user can’t find the answer to her question, she feels like she wasted money on your product.

Figure 4.4. The Adobe product support Web site.
© 2007 Adobe Systems Incorporated. All rights reserved. Adobe, the Adobe logo, Flash and LiveCycle is/are either [a] registered trademark[s] or a trademark[s] of Adobe Systems Incorporated in the United States and/or other countries

It’s important to understand what sort of documentation to include that meets the needs of your audience. To do that, you need to interview your users as often as possible.

Step 3: Interview Your Users Often

You may need to create different types of documentation to meet the needs of your audience. For example, your documentation may include a printed “quick start” guide, online help that’s accessible from the Help menu in the software, documentation that can be printed or published to a PDF file, and multimedia training simulations.

However, you won’t know what types of documentation you need until you understand the needs of your users. You need to know who the software, hardware, or Web site user experience level is before you determine what needs your users have. You’ll learn more about user experience levels in Chapter 6, “Analyzing Your Users.”

As you go through the design and development process, you’ll likely have preferred users test your product as you develop it and provide feedback. (In software development, these preferred users are called beta testers.) Take advantage of your testers by also having them review the documentation as you develop it and send you feedback. The testers will provide invaluable feedback that you can use to create better documentation before it’s released to the general public. For example, you can ask your testers how many graphics and screen shots to include, how to present information in the documentation, and how well they find information (or not) in the documentation.

Step 4: Define Style Sheets and Formatting

After you know what documentation you need, you should define style sheets and formatting conventions. Defining style sheets and formatting conventions helps both your internal staff and your users. A defined style sheet and formatting will help your team and subject matter experts (SMEs) understand how you will structure and present information in the documentation. Your users will benefit by seeing a clean and structured presentation that is consistent in tone, style, grammar, and layout. The company may already have style and formatting conventions that you can use in the creation of your documentation.

Step 5: Create an Outline

After you create the style and formatting guidelines, create a high-level outline for each component of the documentation. For example, create outlines for online help, printed documentation, and any training modules. Then circulate these outlines to SMEs as well as the marketing and sales staff for feedback and possibly other technical writers for peer feedback. High-level outlines include header topics that provide a broad view of each document you’re creating. After you receive the feedback, send the revised outline to the original reviewers for a final review.

Step 6: Draft a Table of Contents

When the outline is complete, create a table of contents from it. In the table of contents, you “drill down” by adding subtopics underneath the broad headlines that you created in your outline. It’s always a good idea to include sections for a glossary of terms and an index in printed or PDF user guides and online help. You may also want to add appendixes that users can refer to in a hurry, such as an appendix that contains answers to FAQs. When the draft is ready, circulate it to the appropriate stakeholders for review.

Step 7: Acquire the Information

As you write the documentation, you will have to interview SMEs to fill in any gaps that present themselves. If you do your homework about the contact preferences of your SMEs in step 1, interviewing will be far less difficult than it would be otherwise. As you gather information, it’s likely that you will refine the table of contents to best present that information.

Step 8: Review Thoroughly

Users will recognize a poorly reviewed document right away. Therefore, it’s important to have a structured, rigorous review process as you refine drafts of your documentation. The review team should include members of your project team, at least one person outside the team (for example, a sales engineer), as well as beta testers.

Review your documentation in multiple stages to catch as many problems as possible with accuracy, style, grammar, and the amount and appropriateness of information. You may want to include a printed or online form with your review copy so the reviewers can see what they need to check for, indicate their approval, and write down changes. Be sure to tie all review stages to strict deadlines so your document arrives on time and is as accurate and useful as possible.

Why You Should Care About Good Design

In Chapter 3, you learned about the business reasons you should care about good design. In sum, those reasons can be boiled down to three:

• Save money you would unnecessarily spend trying to fix problems caused by poor design—These problems not only include users contacting your customer support department asking how to use the product, but they can also result in users using the product incorrectly, which can lead to even greater problems.
• Convince users that they should use your product—Users determine if your software will be used. Even if users are required to use a software product in their workplace, the usability of the software you design can go a long way toward determining whether your customers will keep making your software product, hardware product, or Web site.
• Keep your existing users, and bring in new ones—If your product solves the user’s problems, she will feel that your company knows what it’s doing and feel more confident in your company and your product. If the product doesn’t help her, she will let others know through word of mouth that your product isn’t good enough.
  Today, the Web makes it easier than ever to share good and bad information through such media as sites that let people share opinions about products and services, as well as blogs (short for Web logs). When you’re blogging, you’re sharing your ideas with hundreds or thousands of other users on blog sites such as Blogger, WordPress, and MySpace.

These rules, and the rules of good design, aren’t just for the first version of your software, hardware, or Web site. If your company produces software and Web sites, chances are that you update these products often to add new functionality in response to what competitors are doing, and to prevent your customers from gaining the impression that your products, and therefore your company, are stale.

However, good intentions for the next version can go awry. How many times have you upgraded your software to a new version that promised a better user experience only to find that the feature you were used to no longer works the same way—or isn’t included at all? You need to care about good design and good design goals not only for your first version, but also for subsequent versions. That not only includes the design of the product—be it hardware, software, or the Web site—but also any documentation you create for the product. You’ll meet all three of the preceding guidelines, and you and your company will be better for it.

Case Study: Creating a Paper Prototype Test

Now that the ROI statement is completed, Mike has given you the go-ahead to construct the usability test, starting with updating information in the existing database application. Mike has decided to work on upgrading the existing application first so he can have all the internal issues worked out first before making the capabilities available to his customers through his Web site.

Therefore, it’s time for you and Evan to start walking the project team through the changes in the database application interface by using a paper prototype.

Evan purchased Susan Snyder’s Paper Prototyping from the neighborhood bookstore to get more information about what’s needed to create a paper prototype, including materials and steps for completing tasks.

You and Evan decided on the following office supplies to be purchased at the nearby office supply store:

• White poster boards, which provide fixed backgrounds onto which prototype session participants can place other elements.
• Blank paper for drawing larger prototype pieces and taking notes.
• Unlined index cards for smaller prototype pieces such as dialog boxes and menus. Get 4 × 6-inch and 5 × 7-inch index cards in case you need to cut them into several large pieces or if you need to write a lot of information on one index card.
• Markers and pens to hand-draw parts of the prototype, such as new buttons.
• A highlighter pen to make a highlighted element on the screen.
• Scissors to cut screen shots into pieces as well as create smaller prototype pieces from pieces of paper and index cards.
• Restickable glue to keep elements of the prototype in place on the page but which allow you to move those elements when you need to.
• Removable tape to write on and represent small amounts of text that change, disabled buttons, and list elements.
• Transparencies used with overhead projectors so you can hand-write data on the transparencies without altering the prototype, which is useful when you have a large number of fields to complete and you don’t want to use a large amount of removable tape.
• Transparency pens for writing on the transparencies.
• Paper towel or cloth to wipe the transparencies.

The good news with this project is that you and Evan can print current screens, perhaps by taking screen shots and then enlarging them on a piece of paper. These screen shots will serve as a basis to show what the interface looks like, but you and Evan will also have to hand-draw parts of the prototype (see Figure 4.5).

Figure 4.5. A mockup of the application screen.

The user interviews that you and Evan conducted that were discussed in Chapter 3 resulted in a list of specific goals for the upgraded database. (For example, the Parts Maintenance page should display visual cues that indicate key status points for each part.) Each task must show a specific example of meeting this goal.

Each task should be large enough for a user to achieve his goals but also have a finite and predictable set of solutions with a clear end point. The task should take only a few minutes for an expert to complete. For example, in the Mike’s Bikes database application, one task could be to order a product online by clicking the appropriate button in the product availability page.

Each task should be written down using the following template:

• The task number and task name.
• The goals or output of the task.
• Inputs and assumptions. For the Mike’s Bikes database application, you need to list all the tangible and intangible information and resources that the user needs to complete the task, such as a user ID and password to log into the application.
• The screen-level steps needed to complete the task. Each step will let you and Evan know how many prototype pieces you need to create for each screen in your prototype.
• The amount of time it would take an expert to complete the task.
• Instructions for the user to complete the task.
• Notes about the task, such as what you and Evan need to be aware of as you conduct the test.

Using the template should yield a document like that shown in Figure 4.6.

Figure 4.6. Documenting the tasks.

The tasks should be written down as bullet points or as tersely as possible so the tester learns only as much as he needs to know to complete the test and so you and Evan can quickly refer to the steps in the task.

As you prepare the prototype, you need to prepare not only the blank screens but also the data that will be associated with them. For example, you will need to prepare a dialog box that contains the error that the user will see if he does something wrong. Conversely, you will need to add the elements that will appear if something works correctly. Because you’re updating an existing application for Mike’s Bikes, it’s easy to see what sort of errors the application returns by using the program. Mike has given you and Evan access to the application to see how it works.

Note that if you have dummy text in the paper prototype that’s not important to its functionality, such as content that will appear on the page, you can “greek” the text by drawing lines that represent the text on the page.

Organizing a paper prototype can result in a lot of clutter, so you and Evan must decide on a strategy to organize all the paper prototype materials in one place. You will place all the tasks and screens in a binder with dividers so you can keep everything in check. The binder will also include a “pieces page” (see Figure 4.7), which is strips of tape with data that stick to the page. You and Evan will be able to remove the page from the binder, unstick the pieces as necessary to place on the paper prototype, and then return those pieces to the “pieces page.”

Figure 4.7. A pieces page.

All 10 team members will participate in the paper prototype test. Before you perform a dry run of the test with yourself and Evan, you need to add more information about the users’ conceptual model and apply it to the tasks you want to offer in the paper prototype test. You’ll learn how to do that in the next chapter.

Summary

This chapter began with a discussion about good design goals. You must implement four good design goals into any user interface: to implement ethical, purposeful, pragmatic, and elegant designs. The benefits of user design include lowering long-term production costs, focusing your energies on improving the product instead of fixing problems after your users have complained about them, and applying your design processes to other projects.

You learned about the constraints that users and designers face, and the gap this causes in producing well-designed user interfaces. You should try to bridge this gap as early in the process as possible, but if you can’t, you should acquire as much information from the users as possible about whether the designer’s outlook for the product matched the users’ outlook.

Paper prototyping and storyboarding were covered next. You learned about the issues involved in creating a paper prototype, why it’s the most effective means of developing and testing a user interface before you start developing that interface, and the limitations of paper prototyping. You also learned how to address skeptics’ concerns, including being up front with the disadvantages and making paper prototyping look more professional through the use of stronger paper material so the prototype is more resistant to wear and tear.

You then learned about good documentation design and why it’s important not only to good design overall, but a good user experience. Creating good documentation is an 8-step process similar to a road map that takes you from building your documentation team to reviewing the documentation thoroughly so you have documentation that looks good to your users, because users will spot poorly reviewed documentation right away.

The chapter ended with a discussion about why you should care about good user interface design. There are three primary reasons for good user interface design: good design saves you and your team time and your company money, convinces prospective customers to use your product, and keeps your existing customers happy. Note that good design goals for your product and your documentation don’t end with the first version; they continue with subsequent versions of your product that your company releases.

Review Questions

Now it’s time to review what you’ve learned in this chapter before you move on to Chapter 5. Ask yourself the following questions, and refer to Appendix A to double-check your answers.

1. Why should you resolve conflicts and constraints before you start the design process?

2. Why does a user interface need to be elegant?

3. How do you bridge the gap between user and designer constraints?

4. Why should you use paper prototyping?

5. How do you give a paper prototyping exercise a professional look?

6. What are the advantages of paper prototyping?

7. What are the disadvantages of paper prototyping?

8. Why does a product require good documentation?

9. Why is good documentation design important?

10. Why is good design important?