Top

Designing User Experiences for Applications Versus Information Resources on the Web

January 9, 2006

The relatively recent adoption of user-focused design practices by the Web design and development community—including personas, participatory design, paper prototyping, and the like—highlights important distinctions between the user experiences of desktop applications and those of information spaces. With the growing desire for usable Web applications, these distinctions become more topical and important to understand. Though the process of designing and creating application and information space user experiences for the Web is virtually the same—even if the deliverable design documents may differ—their user experiences are fundamentally and profoundly different. For designers, business analysts, marketing consultants, and others who are sincerely interested in delivering the best user experiences online, understanding these distinctions can reduce the cost of design and improve the likelihood of user acceptance.

I am intrigued by how a designer’s background affects problem definition and, thus, the resulting design approach and its implications for the design and development of these new forms of user experience. Developers of desktop applications and Web sites have very different orientations to user experience. As application developers move into Web development and Web developers begin to take on the peculiarities of application design, each needs to recognize the wildly variant aesthetics of the other.

Champion Advertisement
Continue Reading…

My design career started in bricks-and-mortar architecture, then quickly moved into desktop application development, focusing on CAD databases. Over the years, the substantial body of work of human/computer interaction (HCI) researchers and leading design practitioners has informed my user-centered design process.

Recently, I have had the opportunity to turn my user-centered practice toward the development of Web sites that provide online information resources. My introduction to designing for the online environment was through the practice of information architecture (IA), a broad area of practice that encompasses systems design, information sciences—within the context of library science—graphic design, information design, informatics, and user interface design. In my experience, information architects focus on Web-based user experiences or, more broadly, information-rich environments in which users seek specific pieces of information. The very name of the practice attempts to capture the essence of its purpose—providing information with some sort of aesthetic and structure, or architecture, that helps users navigate through information-intensive spaces.

In learning the—new to me—language of information architecture, I’ve discovered that the vocabulary and grammar of IA doesn’t directly map to the grammar and vocabulary of rich desktop application design. Jesse James Garret’s pancake diagram has gone a long way in providing a common way of visualizing both domains, yet that perspective doesn’t address the designer’s internal experience of creating a user experience in one domain or another.

Application or Information: What’s the Difference?

About six months into my new life as an information architect, I had a profound insight: much of my user-centered design training from my application design background was inapplicable to the needs of the Web design work in which I was now engaged. I experienced, first hand, something akin to Gertrude Stein’s remark about her childhood home of Oakland, California: “There’s no there, there.”

Much of my user-centered practice in rich application design relies on task analysis for its basis. Task analysis is a key part of the early research that usability specialists perform when determining what an application ought to do. How do users accomplish their tasks without the proposed application? What tasks would be best handled by a computer? How can we optimize the overall experience of performing a job through the introduction of specific computer-based tasks? What other tasks does a user engage in simultaneously that would complement or distract from the primary task? And so forth.

Information architecture—and much Web design and development effort—has focused on content. What information does a business want to present to its visitors? How does its Web site promote its brand message? What are visitors seeking when they come to the site? What piece of information do visitors need most—or most immediately? How are different pieces of information related to one another? What are the inherent information structures that best represent the goals of the business in a visitor’s mind? And so forth.

Application designers and developers who are concerned about user experience focus their attention on the fundamental tasks that should be part of an application and those that belong somewhere else. How can we present the various intertwining tasks within an application environment in such a way that users can easily distinguish among them?

Information architects, who are concerned about user experience, focus considerable attention on the inherent structure of information spaces. What nomenclature and relationships exist among the various pieces of content that are natural and obvious to information seekers?

For many application designers and developers—certainly for me—applying principles of application design to Web design was like scooping up clouds with an open hand. Trying to use task analysis as the basis for information space design was an exercise in frustration: “There is no there, there.” In Web design, the task is trivial: visitors seek information. Until I realized that was the only task for Web visitors, I kept struggling to find other things users would try to do. I had been asking the wrong questions.

Similarly, when I watch Web designers and developers approaching the design of task-rich applications, I see them struggling to capture information that is probably irrelevant. For application users, the information space may be inherently uninteresting, because an application is simply a tool with which users can accomplish their work. Within this context, Web designers and developers are asking the wrong questions.

The Inertia of Technologies

Complicating matters is the technology base that supports each discipline. The personal computer’s pedigree stretches back to the big-iron mainframes of the mid-twentieth century, in which central processors crunched numbers. Through the evolution of enterprise computing, a local PC, which is a node on a network, rapidly responds to users’ requests while offloading the heavy-lifting, transactional processing to central servers. The trend has always been to improve the responsiveness of a system, moving from punched card/printer I/O to dumb terminals to personal computers with highly responsive graphical user interfaces.

The Web solved the crucial problem of standardized internetworking among far-flung, heterogeneous systems using a lightweight set of protocols. When your peers are scattered worldwide and may be using hand-me-down, text-only terminals, the lighter the requirements on the local node, the better. The anywhere/anytime promise depends on these standards and a freely available Web browser application. The trend was to reduce the load on the client, moving the heavy lifting to the central servers. This liberating design approach reduces the expense of creating, operating, and managing local nodes. The client node needs only to know how to ask for what it needs correctly, so the server can do what it needs to do—serve up hundreds of thousands of requests to essentially dimwitted screens.

To make a client dumb, or—to use a more politically correct tone—thin, means to reduce the load on its local processor and resources and depend on the network to supply as much as possible. This means you can neither rely on nor design into the client the ability to remember. From the client’s perspective, it is stateless, which means it can’t remember from one click to the next what action a user has performed. This is the essential nature of its aesthetic and what contributes to its thinness. It is also the primary contributor to its aggravating lack of confidence: a thin client always has to check in with its server, because it has no state.

Within the context of information requests and retrieval, that works pretty well. The experience is one of serial requests and fulfillments of information, as the server dutifully responds to its swarm of clients. In this environment, it is possible to easily modify, update, or even dynamically create an information framework, based on the needs of a specific user. The server can adjust individuals’ experience of the information space to suit their current context.

How well does that model satisfy the needs of a different sort of interaction—one that requires substantially more autonomy on the part of the client?

Consider the case of the thick client, in which the local node is responsible for handling the logical outcome of most user interactions. It polls the backend only when it needs a refresh of current data, often asynchronously and transparently to users. The very aesthetic of this environment drips with rich, fluid, and responsive behaviors—lights flash, multiple widgets work interactively with one another—in other words, states are in constant and complex flux.

Few multi-tier application designers, for example, would consider polling a database to populate the menu choices that represent the basic functionality of a product. They couldn’t imagine a scenario in which the structural or functional framework of an application changed dramatically from one session to the next. Given that an application’s structural framework is designed to optimize users’ tasks, it is difficult to imagine a dynamically changing framework.

Web-Based Applications: A Turbulent Convergence

When asked to create a task-rich application for an information-rich space, then, which model should prevail?

Web design for information-rich environments is as much about dance as it is about library science—or perhaps high opera might be a better metaphor. Visitors seek information relating to simple objects—attractors that have little inherent value aside from being stage props. A properly designed image impels a visitor to click it; then, the screen changes, presenting whatever the visitor was seeking. An elegant design for an information-seeking task is one that leads a visitor through a well choreographed dance, with each turning point a delight along the way. Just as in opera, the scrim that appears so solid and substantial when lit from the front, completely disappears when lit from behind. Its purpose is primarily as a backdrop, or supporting element, to the main action—seeking some piece of information.

Application design is about tools—the more robust and rugged, the better. When a user wants a specific function, she expects it to be where she left it, for it to behave the same way each time, and for it to remain available no matter from which direction she approaches it. A tool’s primary value is not as an element in a landscape. Users measure a tool’s value by its appropriate usefulness within a current context. In highly utilitarian environments, highly graphical attractors become superfluous. Instead, the goal of visual design is to minimize competition for user attention by creating integrated work environments that enhance the utility of each function or tool.

Technology and business drivers are rapidly changing the landscape of application design and development. The need for online resources that provide richer interactions with tools rather than simply supporting information-seeking is already driving many design efforts. Users will not accept impoverished applications that fail to provide the richness of their desktop applications. Simultaneously, they will continue to expect the availability, delight, and choreography they’ve come to expect from Web experiences.

Rich internet applications (RIAs) continue to emerge as an evolutionary development. As designers, our success in creating user experiences for RIAs depends on several factors:

  • recognizing design for the Web and the desktop as radically different efforts
  • understanding the technological influences that have driven each domain’s preferred form of interactivity
  • being well versed in the aesthetics of each design discipline
  • maintaining a strong user focus in the face of ever-shifting technologies 

Senior Manager, User Experience, at Home Depot Quote Center

Principal at Phase II

Portland, Oregon, USA

Leo FrishbergWith over 30 years of experience in design management and design—as both a bricks-and-mortar architect and a UX designer—Leo drives highly differentiated and innovative solutions. At The Home Depot QuoteCenter, Leo leads a dynamic team of UX professionals in delivering engaging experiences for Home Depot associates. Previously, as Product Design Manager at Intel, he led UX teams on mission-critical programs. As Principal UX Architect for Tektronix’s Logic Analyzer product line, he filed several patents and spearheaded product vision and definition for the next generation of instruments. Leo is a Certified Scrum Product Owner. Over the past 20 years, he has served as Program Chair, Chair, Vice Chair, and Treasurer on the board for CHIFOO (Computer Human Interaction Forum of Oregon), the Portland Chapter of SIGCHI.  Read More

Other Articles on UX Design

New on UXmatters