Usability for the Web: Designing Web sites that work
This is a book review of Usability for the Web: Designing Web Sites That Work by Tom Brinck, Darren Gergle, and Scott D. Wood (San Francisco: Morgan Kaufmann, 2002). The book is a how-to guide. It describes methods and techniques for designing websites with the assumption that the principles of usability are pervasive throughout. This book is not about HTML. It is a book about the concepts and principles surrounding the organization, creation, and design of interfaces to data and information presented via a Web browser.
This book was well worth the money because it outlines and details a systematic process for creating usable websites. The just-shy of 500 pages (including an extensive index and bibliography) is divided into twelve chapters and seven sections. Each section is a stage in a website design/redesign process:
- pervasive usability - methods for competitive analysis, user interviews, and surveys
- requirements analysis - case studies, task analysis, and information architecture
- conceptual design - visual and interactive representations combined with usability testing and focus groups
- mockup and prototypes
- production - "final" product is created, text and graphics are created, and quality assurance measures are taken including more usability testing
- launch - the site is made available to the public
Each section outlines particular aspects of designing websites complete with color illustrations and examples. Principles are defined and supported by scholarly evidence, personal experience, and case studies. Many of the chapters in each section include forms, checklists, and survey questions used during the design process. These items are available from the book's website at http://www.mkp.com/uew/ . Unlike other books about website design, you will be hard pressed to find any HTML code in the text. This book is not about HTML; websites are not about HTML anymore than newspapers are about ink and paper.
The balance of this review outlines the content of each of the book's sections, and it summarizes of how the book's ideas can be put into practice, specifically, in libraries.
The first section, Pervasive Usability sets the tone for the balance of the book. It defines the concept of pervasive usability as a "process that addresses usability issues throughout the development cycle."
Brinck defines a usable website as one that allows users to accomplish their goals quickly, efficiently, and easily. Characteristics of a usable website include functional correctness, efficient to use, easy to learn, easy to remember, tolerant of error, and subjectively pleasing. Sometimes these characteristics are conflicting. While a site might be very functional, it might not be aesthetically pleasing.
"Usability is a key factor in achieving maximum return on information investments."
Assuming the concept of pervasive usability, above, the book advocates a requirements analysis as the first step in a website design/redesign process. Requirements analysis begins by defining a website's audience, and then doing research on what the audience is really like as well as what they need.
Brinck advocates creating scenarios whose goal "is to make sure the site is not merely theoretically usable, but that is actually serves the needs of specific people in real life." There are three parts to these scenarios: a profile of the user, a schedule, and an interaction episode. These scenarios are very similar to the personas described in information architecture and usability circles. Once the audience is defined, Brinck suggest you design for diversity and accessibility using simple, direct, and concrete language. Stress standard technologies.
The goal of user needs analysis is to: define the audience, identify their goals, define your business (library) goals, set usability objectives, identify design constraints, and define functionality specifications. In order to address these goals Brinck suggests a number of techniques including the use of surveys, competitive analysis, as well as interviews and focus groups
"You can't change the users, so understand them and design for them."
Task analysis is a articulation -- a listing -- of the task users are suppose to be able to accomplish at a particular website. If user's are not able to accomplish their desired task(s), then users will not... use the website. In order to learn what tasks are expected of a website, it is a good idea to examine an institution's existing training materials and standard operating procedures, as well as simply observing users, conducting surveys and focus group interviews, and examining recorded users' behavior (such as Web server log files). Once a list of tasks is created, the next step is to optimize the process used to accomplish the tasks. Streamline them. Make them clearer and simpler. Plan to implement them from the user's perspective. In other words, implement human-error tolerant design by preventing problems, reducing the possibility for error, making it easy to recover from an error, and mitigating problems so irrecoverable losses are not encountered.
The book defines information architecture as a process involving content analysis and planning, organization, providing clues to help users help themselves, labeling, searching techniques, and navigation design. In order to develop an architecture, Brinck advocates: 1) reviewing prior art, evaluating content, creating a core structure, add shortcuts and redundant links, develop orientation clues, design final specifications, implement, and finally, train staff. The text reviews a number of ways to organize content hierarchically, from the top-down (like a table of contents) and from the bottom-up (like an index). They advocate using card sorting techniques to determine the labels of things, and to create a style guide to ensure a consistent Web presence. The navigation bar should be a summary of a site's content, not an exhaustive list of places to go. Finally, the book describes characteristics of effective searching interfaces and enumerates ways to order search results. Again, take into consideration human-error tolerant design.
"Task analysis is used throughout the design process because it acts as a road map for the entire design team.... Information architecture refers to the structure or organization of your web site, especially how the different pages of the site relate to one other."
Mockup and Prototypes
User needs have been identified. Tasks and architectures have been defined. It is now time to create graphic designs embodying these ideas. The book defines good design as one that is simple, consistent, and having focus. Simple designs are designs where the displayed information is salient to the user. Consistent designs make the entire system easy to learn and easy to remember. Focus means placing information in the relevant locations on a page. As the Web develops there are becoming a number of increasingly used layouts usually with a global navigation bar across the top of the page, and local navigation down the left-hand side. Within the content of the page, it is a good idea to minimize the number of vertical alignments. Too many vertical alignments makes things difficult to read quickly.
Keeping these things in mind, the next step is to draw many mockups implementing the ideas above. This usually means drawing on pieces of paper the major elements appearing on the website. These elements will be grossly illustrated staying away from tiny details. The details will come later. Brinck advocates drawing these mockups quickly and refining them later. These mockups provide a means of brainstorming various designs. As the mockups become more and more refined, it is important to include things in the designs such as: layout, background, navigation, text and fonts, images, color, and client requirements. The design process can go on forever. After choosing a design, stick with it for a while and don't tweak it forever and a day. Constant tweaking is a sign of a less than thorough work done previously.
"The primary objective of graphic design is effective visual communication."
The structure is now in place, and it is time to fill it with content. Much of the book's description of writing for the Web assumes the content of the website will be textual including things such as news stories and lengthy product/service descriptions. Brinck outlines the writing process in the following steps: 1) define who will do the writing, 2) establish a writing style guide, 3) collect the necessary information, 4) write the text, 5) review and re-write the text, 6) markup the text in HTML. Keep in mind that writing for the Web has its own characteristics. Be concise. Write for scanability. When reading on the Web people are often goal-oriented. Figure out ways to help people accomplish their goals. Additionally, the book outlines the various elements of written Web content including: navigation, titles, body text, quotes and sidebars, footers, dates updated, and corporate identities.
A website will contain more than marked up HTML text, and there will need to be a technical infrastructure to support these other things. The book briefly compares and contrasts various technologies such as CGI scripts, server-side includes, search engines, the use of databases and XML, and content management systems. There were few hard-core recommendations considering the evolving nature of the technology. The only thing to keep in mind is usability. Will the system be usable if a particular technology is employed? For example, what would the answer be to some of the following questions:
- Does the technology provide real value to the user?
- Is it cross-platform?
- Is it a standard?
- How much of the user's time will be saved?
- How much will users use it?
- How much learning will it require?
- What are the over all benefits to the user and the provider?
- What are the development and maintenance costs?
- Will the extra complexity add significant risk to the project?
In short, does the application of a particular technology solve more problems than it creates.
"The bottom line: Tell the people what they want to know. Tell them what they need to know. Tell them something meaningful and concrete. Be clear and concise. Get every detail right."
Launching a website is a process, not a single event. There are pre-launch activities and post-launch activities. During the pre-launch phase a set of completion criteria ought to be articulated. This includes things like a listing of numbers and types of errors the system and/or user is allowed to make. For example, 0 mission-critical errors, 2 minor coding errors, or 6 cosmetic errors. Keep in mind the technical infrastructure as well. Can your hardware/software handle the load? After these criteria are established, test the site, compare the result to the criteria, and if the criteria are met, then launch the site. Otherwise, repeat. It very import to remember that testing a site is not the last thing one does because if tests are only done near the end of the development process, then fixing errors not only become more expensive, but developers and content providers will have made more of an emotional investment in the implementation and less like to desire change.
Post-launch activities includes examining log files for things like: search terms used to find the site, analyzing design changes, determining entrance pages, watching for growth over time, establishing peak usage times, finding orphaned pages, find extremely popular pages, determining a bit of user demographics.
"You should focus on testing the possible paths a user might take through the web site for the most common and critical tasks."
Brinck describes three types of evaluation procedures: 1) usability inspection, group walk through, and 3) user testing. Usability testing involves the designer evaluating the interface based on general design principles. This is a sort of heuristic test -- a test of experts. A group walk through is very similar to usability inspection except the evaluation is done by a group of stakeholders. User (usability) testing involves observing users perform specific tasks and activities against the website.
As a part of usability inspection, Brinck advocates looking for these sorts of things:
- Page layouts are consistent throughout the site
- Page titles are consistent with link names
- All headers have consistent syntax, capitalization, and punctuation
- Bullets are the same style throughout the site
- Images receive the same stylistic treatment throughout the site
- Logos all conform to strict corporate standards without variation
- Link colors do not vary from page to page
- Link colors are consistent with web conventions
The process of usability testing is also described in detail. For example, you must decide what to test and select tasks requiring finding specific information (i.e. "What is the price of..." or "Find and article on..."). Create tasks that are unambiguous, and don't hesitate to ask questions that can't be answered on your web site. Such an exercise will be interesting. Ask the user to think aloud.
"You can evaluate a web site through usability inspection, walk throughs, or user testing at almost any point in the design cycle... The most important step in any usability evaluation is to go back and fix the problems that were identified."
It took me a long time to read through this book. Not because the material was difficult to understand, but rather because it was so dense. Creating a usable website is not a trivial task, and consequently, describing how to accomplish this task is difficult to summarize.
Websites in libraries, just like websites everywhere else, grew up rather organically over the past few years. They still represent an extraordinarily young technology, especially compared to other communication media such as books, newspapers, journal articles, or even things like photography and film. The process of website design, creation, and maintenance is still in its infancy! There are no hard and fast rules that have stood the test of time, and there won't be for some time to come.
Yet, websites they are here to stay, and users expect information services to be provided via their Web browser. Consequently, libraries must do their best to provide Web-based services and take advantage of the best practices that have been articulated to date. The book, Usability for the Web by Tom Brinck, attempts to list, in great detail, these best practices. This book is well worth reading if you are charged with managing a large Web presence. Highly recommended.
Creator: Eric Lease Morgan <firstname.lastname@example.org>
Source: This book review was never published.
Date created: 2003-02-06
Date updated: 2004-12-05