Designing User Experiences for Applications Versus Information Resources on the Web

By Leo Frishberg

Published: January 9, 2006

“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.”

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.

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?

“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. … Information architecture—and much Web design and development effort—has focused on content.”

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?

“In Web design, the task is trivial: visitors seek information.”

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

“The Web solved the crucial problem of standardized internetworking among far-flung, heterogeneous systems using a lightweight set of protocols.”

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

“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. … Application design is about tools—the more robust and rugged, the better. … Users measure a tool’s value by its appropriate usefulness within a current context.”

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.”

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

11 Comments

A nicely written article. I especially enjoyed the way you brought your own experiences to bear.

I do disagree, though, with your fundamental premise—that designing for applications is dramatically different from designing for Web sites. They both require understanding users, specifying the interaction that enables users and business to accomplish goals, and evaluating how well you’ve done that.

Too, it’s all software design…not much different from the work we’ve been doing since the ’80s, certainly the early ’90s. For example, Ginny Redish & JoAnn Hackos wrote User and Task Analysis for Interface Design during the mid-90s, publishing it in 1998. The book is about observing people doing tasks in their environments, analyzing these tasks, and determining the interaction that enables successful task completion.

Indeed, the Web is discussed only in the book’s last chapter. As they write, “The Web is a medium, not a structure…[E]very Web site and Web page has an interface. So everything we’ve been saying in this book applies to Web design and development.” In addition, the following quotation sums up better than I could why Web site & application design are the same:

“Web site design and development need exactly the same combinatin of skills as any other design and development project: usability specialists to do user and task analysis and iterative usability evaluations, document design and technical communication specialists to create useful layouts and provide clear writing, graphic artists because it is a very visual medium, subject matter specialists to check that the content is accurate, and technology specialists (developers) if more elaborate programming than HTML scripting is required.”

So, respectfully, I disagree that designing applications for the Web is fundamentally different than designing information sites. Ultimately, as UX professionals, we are involved in understanding users and their contexts of use, defining solutions that help them meet their goals, and evaluating these definitions throughout the projects—all within the constraints of business goals and technical capabilities.

I agree with Joe’s comments above. You write:

“In Web design, the task is trivial: visitors seek information. Until I realized that was the only task for Web visitors, I kept struggling….”

This really needlessly oversimplifies things. You seem to be conflating navigation with interaction. Many web applications, say, blogging tools, are not primarily information-retrieval tools but rather information-creation tools. Just because that word-processing environment lacks most of the interaction patterns available in Microsoft Word does not reduce it to just something you use to “seek” information.

As an aside, your roots outside the web show loud and clear here by your total lack of links to other information! Any examples of what you’re talking about you’d like us to look at? How about a link to JJG’s diagram (do people really call it the ‘pancake diagram’?)

The evolution will not be televised.

I think the situation you outline has a lot to do with the “heritage” of folks working on the web. I also come from an applications background and at first found that some information architecture writings, techniques, and ideas were a bit difficult to apply directly to the design of web applications. At my first intranet conference, I found myself surrounded by folks with library science degrees.

Time for us to break down the walls.

Building sites and applications for the web has lead me to a couple of conclusions. First, users have task goals when using an information space, so we do well to plan for those goals. For example, someone looking at product overviews on a technology company web site is probably considering a purchase, so offering the ability for further contact or additional information is a way of meeting the task needs of the user. Don’t make them travel back to a separate area to find out how to complete their task. Of course, I mean offering them a convenient option as they gather more information, not forcing them into “registration” before giving them the information.

The second conclusion is that the web has steered us toward the types of applications that really require loads of information to use. If, for example, if I wish to use an online mechanism to request traffic school to deal with a speeding ticket, I will need a variety of information along the way, such as cost, school locations, deadlines, and alternatives. (I wish I knew less about this particular example.)

I think it’s time to break down the walls between information and interaction. Many applications are information spaces. People looking for information usually are trying to accomplish something. Successfully meeting the needs of users will increasingly demand a hybrid approach that marries the best techniques of applications with appropriate information and navigation.

There are currently examples at the edges of this idea. Most online buying sites, such as Amazon, are applications that are information-rich. Some information sites dip their toe into the applications pool by offering a single question about the usefulness of the information on the page. And wikis are definitely somewhere on the continuum.

Given this convergence, we probably all need to evolve our skills to a new hybrid approach that embraces the relevant parts of multiple disciplines.

Thanks Joe for the complimentary remarks. I don’t disagree with any of your observations—at the highest level, design for the Web is identical to design of rich applications. I would say that, at the level you are referring to, design in general (graphic, architecture, you name it) is founded on the underlying principles you list.

My observations are about the efforts required when we, as designers, scratch below that highest level. At the lower level of engagement, I’m referring to the effort for Web design that differs dramatically from the effort for rich application design. They are different media and hence have different aesthetics—perhaps analagous to the difference between designing a product (industrial design) vs. designing a stage play (choreography). At this lower level, they diverge dramatically from their software design roots.

When I limit my view of online resources only to information spaces, not distributed applications, these differences become even more apparent. Again, what tasks are involved in searching for an answer to a question? Aside from the micro tasks of screen / navigation design, the macro task analysis is trivial.

We are in agreement that as companies deliver rich online experiences extending beyond information navigation or content delivery, user experience professionals must rely on the same tools, processes, and talents they have been using in the enterprise world.

I agree with Joe ( mainly on last sentence, “I disagree that designing applications for the Web is fundamentally different than designing information sites” ), but I can say you wrote an interesting article about the meaning of using design methodologies ( mostly user centered ) into the developing of RIAs, Web apps, and informative environments.

The “link” with Architecture maybe is not random…if you think the user moves into an informative space and has to interact with information and data (our objects, steps, walls, gardens) to reach what he needs.

Have a nice time,

— dott. daniele galiffa multimedia designer and developer Macromedia FlashMX Developer Certified daniele@mentegrafica.it

Good article. I completely and utterly agree that designing information-rich sites (those with practically no interactive elements, like big business/government sites) is very different from designing interaction-rich applications, though have had many an argument about this (someone once suggested to me that I should conduct a hierarchical task analysis to determine the navigation for a big intranet - duh!).

I’m going to go so far as to insult a bunch of people and suggest that if you haven’t realised this, then you perhaps haven’t done hard enough projects (big, ugly, 50,000 page content sites; complex interactive business applications), and thought deeply enough about what you are doing.

To me this is fundamental and the two require quite different approaches to a project and different skillsets (though a person can have the skillsets for both). It is entirely different coming up with an elegant information structure that will allow people to find what they want and what they didn’t know they want; compared to an elegant interaction that allows a complex task to be completed smoothly.

Thanks for writing such a thought-provoking article.

Thought-provoking article. I too, though, blanched at:

“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.”

While a great deal of interaction on the web is information-seeking at its base level, the fact that they are looking for information doesn’t define their activity.

If I want to know if anything good is on TV tonight, all I’m doing is seeking information. But to say I’m seeking information doesn’t tell you anything about how to help me do it.

If you’ve defined this as a possible (or likely) task, are you not able to better structure your pages to enable me to find tonight’s TV schedules (and then maybe tomorrow’s schedules from there, or tonight’s radio schedules)?

Although I can see how in very large sites, where there is fundamentally just a library-style resource, this doesn’t work: it’s a taxonomy issue. But in other cases, how does not defining the task help you do it better?

The far most gui-lvin promises of Web releases maintain their connectivity by an appeal mostly governed by WMS collaboratives. I found this article far more useful than the usual IA ground bareholders. Thanks!

Andrew: You seem to be conflating navigation with interaction. Many web applications, say, blogging tools, are not primarily information-retrieval tools but rather information-creation tools.

I think you oversimplified things with this example. A blogging application has two interfaces, for two users: consumers and producers.

The consumer of a blog (i’m ruling out RSS/atom syndication for now) needs to find the blog, be able to quickly skim entries in it (particularly to note what they’ve already read) and still be comfortable reading in detail the content they want to read, and have a simple interface for leaving a comment or to quickly find the last comment they wrote to see any replies to it.

The producer of a blog has to have tools to create new entries, edit them, manage them, perhaps tag them (to contribute to the metadata by which the blog user finds the ones worth reading to them), manage comments to weed out spam and junk, etc.

The producer of a blog sees a very different application from the consumer. There are two different applications that happen to work on the same information space.

Increasingly, THAT is what the web is all about. one (increasingly large) data set and multiple applications for seeing and manipulating it.

Leo, this is an important article. I wish I’d read it a few years ago.

To me, this distinction is most important when pitching a project. I’ve made the mistake in the past of proposing the same UX methodology for application and information sites. I’d have a hard time selling personas and goals to a brochureware client, and then I’d have a hard time trying to use that methodology during the project. In the end, it was useful, but my insistence on it means that it took time away from information architecture, sitemapping, and other tasks that are more relevant to information-focused sites. You do need the same set of tools for both. But your emphasis needs to change dramatically. The bulk of the work will be in different areas. I’ve learned this lesson the hard way. It’s very humbling to fall flat on your face, because the methodology you struggled to sell the client on proves to be only marginally useful, while more important UX techniques were under utilized. So the difference might be a matter of degrees, but even then, it is significant.

Join the Discussion

Asterisks (*) indicate required information.