Making the Web Work: Designing Effective Web Applications

Written by: Jeff Lash
“ ‘Making the Web Work’ is an excellent read for someone making the transition from print design to web design and has the time to read and reflect on the content.”Making the Web Work: Designing Effective Web Applications” is a well-written, meaty book on the entire process of designing interactive websites from a user interface perspective. It should be commended for succinctly describing the entire user-centered design process, but at the same time chided for not focusing more specifically on web applications. A more concerned focus on guidance specific to web applications and a more specific focus on full-fledged web applications would have made this a more distinguishable item on the crowded user-centered design book shelf.

The book itself is structured into five sections. The three middle sections correlate to the three tiers of a visual model that Baxely uses as the framework for discussion of his approach to design. The visual model is similar to Jesse James Garrett’s “Elements of User Experience (PDF)” diagram, though in Baxley’s case, there are three sections—Structure, Behavior, Presentation—each of which are comprised of three subsections, moving from Conceptual Model in the “Structure” tier all the way to Text in the “Presentation” tier.

Baxley’s writing style is simple and straightforward, casual enough to not be boring but direct enough to be authoritative. The structure of the book is clearly apparent, allowing the reader to skim, skip over familiar sections, or quickly refer back to sections if needed.

The first section—Foundations—is an excellent introduction to the fundamentals of interaction design. Anyone looking for a quick introduction to personas would be hard-pressed to find a better reference than Chapter 2, “Putting the User First.”

Section two—Structure—is broken down into Conceptual Model, Structural Model, and Organizational Model (Baxley’s preferred term for information architecture). While the information in the Structure section is certainly worthwhile and presented well, readers expecting to immediately dive in to web application design specifics may be disappointed.

There are plenty of other books that provide this same basic overview of the user-centered design process, and there is not a significant emphasis on how this information relates to web applications versus traditional websites. Baxley defines a web application as “a specific type of web site that implicitly and explicitly stores and manipulates data unique to each of its users. Put more succinctly, a Web application is software on the Web.” As examples of web applications, he mentions online stores, financial services, travel services, information portals, and online services.

The problem with Baxley’s definition is that it is exceedingly broad. True, a good percentage of sites incorporate these sorts of features, but simply having one interactive feature does not a web application make. If a web application is truly as Baxley defines it—any website that does not give the exact same data to user A that it gives to user B—then nearly all websites would be classified as web applications, and the terms “web application” and “website” would be synonymous.

Describing this book as pertaining to “web applications” implies that it discusses applications that allow users to perform tasks like email, stock trading, and photo sharing (which it does), but not websites that are merely “interactive” in one way or another. For example, readers may not expect to find online shopping (e.g., Amazon.com) and portal personalization (e.g., myYahoo) defined as “web applications.” Perhaps some will see this as splitting hairs, but readers expecting information specific to intensive applications may be put off by the attention paid to ecommerce.

The discussion, additionally, could have benefited from more varied examples of web applications, rather than focusing on the aforementioned email, stock trading, photo sharing, and online commerce, since these are but a few of the large variety of web applications that may be developed by readers. An additional perspective could have been gained by discussing web applications that allow system administrators to monitor servers, enable employees to fill in timesheets, let users balance their checking accounts, or permit students to register for classes, just to cite a few examples.

It is not until halfway through the book that the information specific to web applications becomes apparent, and even then, only bits at a time. Chapter 7, “Viewing and Navigation,” focuses mainly on site-wide navigation, but near the end begins to focus on controls for sorting, filtering, and viewing data. Chapter 8 focuses on editing and manipulating data, and chapter 9 rounds out the Behavior tier by focusing on user assistance.

Part four—Presentation—discusses Layout, Style, and Text. Baxley manages to fit a large amount of useful tips and examples into a mere 64 pages, but one would think that a larger part of the book would have been devoted to this tier, since it is here that web applications are most easily distinguished from web non-applications from a visual and interactive standpoint.

The final section includes case studies on Amazon.com and Ofoto. Baxley analyzes these sites according to his three tiers and nine layers, providing useful descriptions and screenshots where necessary. The index, often thrown in to books at the end as a metaphorical afterthought, in this case is extremely well designed and readable. Kudos to indexer Cheryl Lemmens for closing the book on such a positive note.

While accurate overall, there are some minor inconsistencies that stand out. For example, he describes the merits and drawback of using the <ALT> tag for contextual help when he is really talking about the “title” attribute (p. 292), and uses Wine.com as an example while discussing the merits of a hierarchical organizational system when it is actually facet-based (p. 186). These mistakes are neither common nor severe, but they are fairly noticeable in a book that otherwise should be commended for its fastidiousness.

From cover to cover, “Making the Web Work” weighs in at just over a hefty 470 pages. Though about half of each page is devoted to text, with the extra space used for notes and labels, it is still a lengthy read. It is an excellent resource for someone making the transition from print design to web design and who has the time to read and reflect on the content. Those looking for a shorter way to absorb the information would be well-served by only reading the concise and helpful summaries at the end of each chapter.

Those new to the field of user-centered design will find “Making the Web Work: Designing Effective Web Applications” most useful; intermediate or advanced practitioners looking for in-depth information specific to web applications may want to look elsewhere.

Read a sample chapter (Chapter8 – 1.6mb PDF)

  • Making the Web Work: Designing Effective Web Applications
  • Bob Baxley
  • New Riders, 2002
  • ISBN 0735711968
  • 474 pages
  • List price: $45.00
  • Target audience: Practicing designers, product marketers, software engineers
  • Chapters:
      Part I: Foundations

    1. Common Ground: Defining Web Applications and establishing the Goals of Design
    2. Putting the User First: Describing Target Users and Product Goals
    3. Deconstructing the Problem: Prioritizing and Categorizing Different Aspects of an Interface
    4. Part II: Tier 1, Structure

    5. The Conceptual Model: Selecting a Fundamental Motif
    6. The Structural Model: Understanding the Building Blocks of a Web Interface
    7. The Organizational Model: Organizing and Structuring Content and Functionality
    8. Part III: Tier 2, Behavior

    9. Viewing and Navigation: Creating Consistent Sorting, Filtering, and Navigation Behaviors
    10. Editing and Manipulation: Using HTML Input Controls to Accurately Capture Users’ Data
    11. User Assistance: Communicating with Users Through Help, Status, and Alerts
    12. Part IV: Tier 3, Presentation

    13. Layout: Positioning Elements to Maximize Understanding and Readability
    14. Style: Defining Visual Appearance
    15. Text and Labels: Writing for the Web and Calling Things by Their Right Names
    16. Part V: Case Studies

    17. Amazon.com: Browsing the Aisles of the Web’s Supreme Retailer
    18. Ofoto: Looking at the Leading Online Photo Processor


Jeff Lash is a Usability Specialist and Information Architect at MasterCard International and writes the IAnything Goes column for Digital Web Magazine. He is also on the Leadership Council for the Asilomar Institute for Information Architecture and is co-founder of the St. Louis Group for Information Architecture. His personal web site jefflash.com proudly has no IA-related information.

Introducing Interaction Design

Written by: Bob Baxley

Part 1 of a 12-part series about interaction design for web applications

“[Design] has never cohered into a unified profession, such as law, medicine, or architecture… Instead, design has splintered into ever-greater subdivisions of practice without any overarching concept of organization…”
—John Heskett in Toothpicks and Logos: Design in Everyday Life
When the founders of this site set out to create what we now know as Boxes and Arrows, they had four things on their mind: information architecture, interaction design, information design, and interface design. Now, only nine months later, Boxes and Arrows stands as one of the preeminent design communities on the Web and is well on its way to fulfilling its mission to be the “definitive source for the complex task of bringing architecture and design to the digital landscape.” With its first birthday a few short months away, it seems an appropriate time to expand the conversation and the community by examining issues outside the traditional scope of information architecture. To wit, I offer the first of a twelve-article, twelve-month series devoted to the field of interaction design.

The focus of this series is on the challenges inherent in the task of translating established product requirements into a browser-based interface. Along the way, we’ll discuss the activity of interaction design as it relates to the Web and the relative advantages and disadvantages of the Web as an interactive medium. In addition, we’ll examine a variety of solutions to common interaction design problems. Although the next eleven articles are already loosely mapped out, if there are particular topics you would like to have covered, please let me know and I’ll do my best to work them in.

And so we’re off. I hope the journey is a fun, useful, and educational one for us all.

We’re in this together
Ours is a world, an economy, and a profession that has embraced the idea of specialization of occupation on a scale heretofore unknown. Where six years ago someone who designed software could readily lay claim to the title “interface designer,” the explosion of the Web and other interactive mediums has split our profession into a variety of increasingly granular specialties.

Although this has sometimes been both necessary and useful, it has also resulted in a cacophony of competing titles, responsibilities, and consulting rates. As a result, even though we all approach our work from the same user-centric orientation, specialists working on one aspect of a design may be ignorant of the issues and compromises being made by other specialists working on other aspects of the design.

In particular, information architecture and interaction design have often been sequestered from one another. Where information architecture has tended to focus on content-centric sites, interaction design has tended to focus on functionality-centric sites. Now however, the two often find themselves in meetings together thanks to the proliferation of websites featuring both large volumes of content and sophisticated functionality.

Therefore, seeing as how we’re going to be in meetings together, it seems only polite to introduce ourselves to one another.

Structure vs. behavior: teasing apart IA and ID
A good place to begin is the definition of information architecture offered up by two of Michigan’s better minds. In their recently published second edition to “Information Architecture for the World Wide Web,” Sirs Rosenfeld and Morville offer a lengthy definition of the field which focuses on four key themes:

  1. Information
  2. Structuring, organizing, and labeling
  3. Finding and managing
  4. Art and science

Other than the fact that “art and science” is endemic to all forms of design, their definition describes a fairly specific universe of design issues and challenges. In contrast, the field of interaction design concentrates on the following:

  1. Human/machine communication – At its most fundamental, interaction design serves to translate the conversation that goes on between the technology and the user. In the role of translator, interaction designers are required to understand the subtleties and colloquialisms of both parties, ensuring that they can readily and efficiently communicate with one another.
  2. Action/Reaction – Not surprisingly, the action/reaction dynamic of interactive media sits at the heart of interaction design. This requires the designer to understand and anticipate how interactions unfold over time, designing for the wide range of permutations that can occur.
  3. State – As part of its role as translator, interaction design is also concerned with ensuring the user understands the current state of the application. In the same way that humans use body language and social situation to govern and predict behavior, interactive systems communicate state so that users will understand what type of operations are possible or appropriate at any given time.
  4. Workflow – In addition to facilitating the completion of discrete tasks such as selecting a payment method, interaction design is also concerned with the completion of multi-task goals such as browsing, selecting, and purchasing an item. Like a film director connecting individual shots into scenes, and scenes into movies, the interaction designer uses individual screen elements to create pages, pages to create complex operations, and operations to create a complete application.
  5. Malfunction – As with all forms of communication, misunderstandings and mistakes occur. Therefore it is also part of the designer’s role to anticipate and mitigate those problems, ensuring that both the user and the system can easily recover.

Well-designed interactive products balance each of these concerns with the respective limitations and capabilities of both people and technology. Such products allow people and technology to carry on a complex and elegant dance relying on multiple, simultaneous forms of communication. The role of the interaction design, therefore, is to choreograph and facilitate the dance in a manner that makes everyone feel like Fred Astaire.

Such choreography, of course, requires an understanding of both the stage and the dancers. As a result, the best interaction designers draw from a variety of disciplines ranging from perceptual psychology to computer science.

Looking ahead
With that brief introduction to the field of interaction design behind us, we can start to examine more specific and thorny topics. Next month’s installment will include a comparison of web applications to traditional content-based sites as well as a consideration of the relative advantages and disadvantages of the Web as an application platform.


Bob Baxley is a practicing designer who specializes in interaction design for Web applications and desktop products. He currently runs the Design and Usability teams at The Harris-myCFO and recently published his first book, “Making the Web Work: Designing Effective Web Applications.” He looks forward to hearing from you at .

What You Should Know About Prototypes for User Testing

Written by: Chris Farnum

There are several important factors to consider when you are planning to do prototyping for user testing. You will want to make careful choices about fidelity, level of interactivity and the medium of your prototype.

Degree of fidelity “An information architecture wireframe is NOT graphic design. I swear, it’s really not!!!”Fidelity is the degree of closeness to the “depth, breadth and finish of the intended product” (Hakim & Spitzer). Opinions vary a great deal on how much a prototype should resemble the final version of your design. Usability practitioners like Barbara Datz-Kauffold and Shawn Lawton Henry are champions for low fidelity —the sketchier the better! Meanwhile, Jack Hakim and Tom Spitzer advocate a medium- to high-fidelity approach that gives users a closer approximation of a finished version. You’ll want to make a decision about the right approach for you based on the needs of your project.

Low fidelity
You can use hand-drawn sketches to create a paper prototype. If you go this route, you may also want to help your users get into the spirit of things during the test by creating a complete low-fidelity, paper environment. This could include a cardboard box made to look like a computer and an object to hold to point and click with. These techniques help users to suspend their disbelief and get their imaginations involved so that they can better visualize the interface. The advantage of using rough sketches is that users will have an easier time suggesting changes. They may even grab a pen and start making their own changes (Datz-Kauffold and Henry).

In theory, low-fidelity sketches are also a time-saver, but this really depends on your point of view. Personally, I like to draw diagrams and wireframes in Visio where I can revise and move things around without erasing and redrawing. If you prefer to work this way too, and if time allows, you can always have those Visio drawings hand-traced or use them as a roadmap for making sketches to test with. You might even find a graphics tool with a filter that will convert a Visio-generated graphic into a hand-drawn sketch with wavy lines.

High fidelity
This approach takes you as close as possible to a true representation of the user interface —screen-quality graphics. All of the blanks on the page are filled in, and it looks good. However, you might not have all of the technical or backend problems worked out yet, or you might have only a small part of the entire site rendered. That’s why it’s still considered a prototype. For example, it might consist of a small series of Photoshop images or HTML pages with just enough functional links to convey the feel of the site’s flow. You may need to enlist the help of a graphic designer or web developer to build these in a reasonable amount of time. Advocates for high-fidelity prototypes argue that they are easier for users to understand just by looking at them. There is no disbelief to overcome, and it is easier to determine when they really do not understand the design. If you choose a high-fidelity prototype, make sure the you have enough of the design fleshed out so that users can complete several tasks. Decide on these tasks early, so you know which areas of the design need to be represented for your tests. Otherwise, you will be in for a great deal of preparation work.

Medium fidelity
In the grand tradition of Goldilocks, I find myself drawn to the middle approach. A medium-fidelity approach tends to include some visual design and a level of detail somewhere between high and low fidelity. Does this sound familiar? As an information architect, I’m accustomed to creating wireframes I can hand off to decision-makers, graphic designers, web developers and programmers. An information architecture wireframe is NOT graphic design. I swear, it’s really not!!! But… I’ll admit that it has enough visual design to convey a rough version of the user interface. Because I create these with drawing tool software, they tend to have more polish than hand-drawn diagrams. Hakim and Spencer are champions for medium-fidelity prototypes because they fit more seamlessly into the design process while providing more realism for users. I found this to be true during a project to design a search interface for Egreetings with my colleagues at Argus. I created rough draft wireframes for the prototype, and after testing I revised them for use in my deliverables.

Interactivity
Interactivity describes how your prototype behaves. Does your prototype react to user inputs with feedback? Can they “click” on something to go to another page or fill in a form? Will buttons appear to depress and drop-down menus work?

Static prototypes
Prototypes used for testing are static if they are pages or page elements shown to users, which don’t provide any feedback. It can sometimes work well to show a page to a user and ask them to explain it to you or to guess where they can go from here. In this kind of test, the user interprets the prototype rather than interacts with it. This is a good way to validate your design by checking to make sure users understand it. It’s also easy to score this sort of test when you have a standard list of questions to ask about each page.

Automated
Automated prototypes allow users to make choices that cause changes. The testing prototype provides the user with feedback. Elements are “clickable” and forms can be filled out. The interface reacts to the user while the tester observes. One way to do this is to create the prototype in HTML or some application that allows interactive elements such as Flash, Visual Basic or even PowerPoint.

Another way to achieve a kind of pseudo-automated interactivity when you have chosen a paper prototype is to pretend (Datz-Kauffold and Henry). Have you ever seen children at play pretend that they are driving a car by setting up chairs for the front and back seats, drawing a dashboard on a cardboard box, and using a Frisbee for the steering wheel? If you have set up the right environment for your users, you can ask them to pretend scraps of paper on a table are their computer screen. When they “click” on a drop-down menu by touching the element with a pointer, a tester assigned to the role of the computer provides feedback by swapping the closed menu for an open one that shows choices. The “computer” may need to write on some elements before showing them to the user, i.e., “Your search retrieved 523,621 hits.” It takes a few minutes to get test participants used to the idea, but if you encourage them to have fun with it you will learn a great deal. You can also easily try out different possible reactions to user input.

This method worked well during the Egreetings project. We especially emphasized the technique of asking the users to click and then provide feedback. We found it useful to laminate the screen components so we didn’t need to produce a clean copy of the test for every subject. The users could write on the laminated pieces with thin whiteboard markers when making selections and entering search criteria. Of course, this meant that we needed to take careful notes because of the need to erase between each test subject.

Here are some other tips to try for low-fidelity testing with simulated interactivity:

  • Bring extra paper so you or the respondent can sketch out an idea if the opportunity arises.
  • As with any user test, it really helps to ask the respondent to think aloud.
  • If you have the luxury, bring a team of three to the test: someone to take notes, someone to play the “computer” and another to facilitate.
  • Use a piece of posterboard as your “screen.”
  • Cut your design into separate pieces or zones as appropriate and ask the user to rearrange them in the order they prefer.
  • Attach the folder tabs that come with hanging files to components so they are easier to grab.
  • Invite users to throw away or cross out components that they don’t think are important.
  • Number the pieces so that you can easily refer to them in your notes and keep them organized.
  • If you do decide to bring separate copies of the test materials for each session, tape down the components to a larger piece of paper as arranged by each user so you have these artifacts to analyze later.

Prepare a kit for yourself containing:

  • Scissors and tape,
  • Different sizes and varieties of sticky notes (which make great drop-down menus),
  • Markers and pens in various colors and sizes,
  • Paper clips and binder clips for keeping slips of paper organized, and
  • Objects that the user can pretend are the mouse pointer, such as a feather or a small toy.

Medium
There are many possible combinations to choose from for building your prototype. One of the first choices to make is whether you want to have your prototype viewed on an actual computer screen or if you’ll be working on a tabletop with a paper prototype. Believe it or not, fidelity and interactivity are independent of the medium you choose. It’s probably most natural to think of the extreme cases. An automated HTML prototype is often high-fidelity and, of course, the medium is a computer screen. Likewise, a natural medium for a low-fidelity automated interactive prototype is hand-drawn sketches on paper. However, you can also have the following:

  • Low to medium-fidelity wireframes built in PowerPoint that show only lines and boxes with text;
  • animation features provide automated interactivity,
  • Static Photoshop prototype pages shown to users on a computer screen, or
  • Same as above, but printed out in color on paper.

Mixing the variables
You can mix these three variables (fidelity, interactivity and medium) in many different combinations. The exact combination you choose should match the goals you determine for your testing. Possible goals for an IA prototype include:

  • Testing the effectiveness of labels and icons.
  • Finding out the right balance of depth and breadth of a topical hierarchy.
  • Determining the right options to offer for narrowing a search.
  • Choosing the most important metadata elements to show on a search results screen.
  • Settling the question of whether your target audience accomplishes tasks better with a task-oriented organization scheme or with a topical organization scheme.

If you live and breathe NetObjects Fusion and don’t have much time, your preference might be to create a medium-fidelity prototype. That way you could test that sitemap you are working on using some rough placeholder graphics or text instead of the finished graphic design. How you mix the variables depends on the time and budget you have available, as well as your work style. Try experimenting with different approaches to learn how prototyping will work best with your design process.

For more information

  • Evaluating Information Architecture,” Steve Toub (2000).
    http://argus-acia.com/white_papers/evaluating_ia.html
  • UPA 2000 Proceedings:
    #28 – “Waving Magic Wands: Interaction Techniques to Improve Usability Testing Low-Fidelity Protoypes,” Barb Datz-Kauffold & Shawn Lawton Henry.
    #32 – “Prototyping for Usability,” Jack Hakim & Tom Spencer.
  • “Prototyping for Tiny Fingers,” Marc Rettig, Communications of the ACM, Vol.37, No.4 (April 1994).
    http://portal.acm.org/citation.cfm?id=175288 (ACM Membership required)
  • Using Paper Prototypes to Manage Risk,” User Interface Engineering.
    http://world.std.com/~uieweb/paper.htm
Chris Farnum is an information architect with over four years’ experience, and is currently with Compuware Corporation. Three of those years were spent at Argus Associates working with Lou Rosenfeld and Peter Morville, the authors of Information Architecture for the World Wide Web.