Interaction Design’s Role in Application Design
Since interaction design plays such a central role in the design of application user experiences, there is much that it encompasses. Good interaction design
- effectively communicates the scope and nature of an application’s functionality through its primary contexts for interaction, as well as its menus or navigation system
- defines and clearly presents both simple and complex workflows and, thus, facilitates users’ tasks
- provides easily discernible opportunities for interactivity through visible affordances, or interactive elements
- defines user interactions that are consistent with best practices or highly intuitable—and, thus, easy to learn—and easy to use
- specifies behaviors that clearly communicate an application’s responses to user interactions
- informs users about system state changes
- actively prevents user error
Supporting Roles in Application Design
Although information architecture,
visual interface design, information design, and user assistance design are also essential aspects of user experience design,
all serve supporting roles in the design of applications—that is, they are the
means by which designers facilitate interactions, as follows:
- information architecture—An application’s information architecture defines its overall structure, with the goal of supporting findability and usability; provides the basis for the application’s menus or navigation system; verbally communicates the application’s structure through the labeling of its menus or navigation system; and ensures users can easily navigate to related functionality and information from their current context.
- visual interface design—An application’s visual interface design visually expresses its hierarchies, groupings, workflows, and affordances—thus, showing users how to interact with the application through effective visual communication; provides iconic representations of the application’s objects and actions; and ensures its user interface is both aesthetically pleasing and accessible to people with color-deficient or low vision.
- information design—An application’s information design visually expresses the information the application provides to users—often through charts, graphs, information visualizations, and tabular reports. Another role for an application’s information design is to clearly communicate what information users need to provide to accomplish their tasks—typically, by filling out Web forms or editing options in dialog boxes.
- user assistance design—An application’s user assistance design verbally communicates how users can interact with it—telling users both what to do and how to do it. Interactive user assistance communicates what users should do next when filling out forms. More traditional Help systems should communicate the concepts users must understand to use an application effectively, as well as provide step-by-step instructions for specific tasks.
In application design, the designers who are responsible for information architecture, visual interface design, information design, and user assistance design may be either different people who are specialists in particular aspects of UX design or UX designers who are capable of fulfilling all of these roles.
Now that I've described interaction design’s role in application design and how information architecture, visual interface design, information design, and user assistance design support interaction design, let’s begin our exploration of the essence of interaction design with the design of virtual contexts for interaction.
Designing Virtual Contexts for Interaction
An application’s primary context for interaction should effectively communicate the scope and nature of its functionality—that is, what type of application it is. The virtual contexts that would be most appropriate for an application you’re designing depend primarily on the application’s type—and to some extent, on the platform for which you’re designing it. An application’s purpose, features, and the nature of its user experience determine its type, while its overall structure and characteristic frameworks, patterns, affordances, and behaviors express its type. Each virtual context comprises a single screen, Web page, or window. The platform on which an application runs and the size and resolution of its display—otherwise known as an application’s form factor—constrain the screen real estate that is available for each of an application’s virtual contexts.
Designing an Application’s Primary Context
When designing an application, it is important to initially concentrate on the big picture and make high-level design decisions, including what the application’s primary context for interaction should be. By focusing on users’ goals when designing an application’s primary context for interaction, you can establish a sound foundation on which to construct the entire application. Designing the overall structure for an application’s primary context for interaction is a key part of establishing what I call a conceptual model in my column “Design Is a Process, Not a Methodology”—or what Alan Cooper, Robert Reimann, and David Cronin refer to as a Design Framework, in About Face 3.
“The Design Framework defines the overall structure of the users’ experience, from the arrangement of functional elements on the screen, to interactive behaviors and underlying organizing principles, to the visual and form language used to express data, concepts, functionality, and brand identity. … The Design Framework is made up of an interaction framework, a visual design framework, and sometimes an industrial design framework.”—Alan Cooper, Robert Reimann, and David Cronin
As Kim Goodwin says in Designing for the Digital Age, visualizing concrete solutions “begins with defining the framework of the design: the supporting structures and underlying concepts upon which every detail depends.”
A Confusion of Terms
In the software development community within which most UX professionals work, there has been a proliferation of both definitions for and variants of the term framework.
Proponents of object-oriented software development originally adopted the term framework in the early 1990s. The book Design Patterns: Elements of Reusable Object-Oriented Software provides the following definition:
“A framework is a set of cooperating classes that make up a reusable design for a specific class of software. … You customize a framework to a particular application by creating application-specific subclasses of abstract classes from the framework. The framework dictates the architecture of your application … so that you … can concentrate on the specifics of your application. The framework captures the design decisions that are common to its application domain. Frameworks thus emphasize design reuse over code reuse…. … Not only can you build applications faster [with frameworks], but the applications have similar structures. They are easier to maintain, and they seem more consistent to their users.”—Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides—also known as The Gang of Four
In addition to such generic software frameworks, application frameworks that let developers implement applications that have standard user interfaces for particular operating systems became popular with the advent of Graphic User Interfaces (GUIs). Current examples include Cocoa for Mac OS X and Microsoft Foundation Classes (MFC).
Today, there is a multiplicity of Web application frameworks that support the development of dynamic Web sites and Web applications and are based on programming languages such as Java—for example, Google Web Toolkit (GWT)—Perl, PHP, Python, and Ruby. JavaScript frameworks include JQuery, MooTools, Prototype, script.aculo.us, SWFObject, Yahoo! User Interface Library (YUI), and many others.
In About Face 3, Alan Cooper, Robert Reimann, and David Cronin use the terms Design Framework, interaction framework, visual design framework, and industrial design framework. However, I’ve long been accustomed to using the term framework to refer to a software framework, so I prefer to use the term conceptual model rather than Design Framework. With the omission of the word design from interaction framework, their terms lack parallelism. They define an interaction framework, as follows:
“The interaction framework defines not only the high-level structure of screen layouts but also the flow, behavior, and organization of the product.”—Alan Cooper, Robert Reimann, and David Cronin
In their recent book Web Anatomy: Interaction Design Frameworks That Work, Robert Hoekman, Jr., and Jared Spool use the term framework in a more traditional sense, but with a focus on interaction design:
“Patterns, components, and interaction design frameworks each play a different, essential role in a team’s reuse strategy. … Whereas a design pattern is a common solution to a recurring problem, an interaction design framework is a set of design patterns plus other elements and information, used together to guide the design of a complete system or site context. … A framework … offers guidelines for the design of whole contexts. … Frameworks describe entire subsystems of patterns. … Frameworks are at a high level of abstraction. … Frameworks are the larger anatomical systems that help designers choose which patterns to use….”—Robert Hoekman, Jr., and Jared Spool
So, from two thought leaders in the UX community, we have two very similar terms—interaction framework and interaction design framework—with very different meanings. And, with people’s tendency to abbreviate long terms—which, in fact, Kim Goodwin does in her book Designing for the Digital Age when she describes a framework—we probably have people in different roles on multidisciplinary product teams using the term framework in very different ways.
Application Genres and Their Virtual Contexts
There are three basic genres of applications. (When describing iPhone apps, Apple calls these genres application styles.) An application’s genre depends on its purpose, the tasks it supports and/or the information it provides, and its user experience—including both behavioral and visual characteristics. Some applications combine application genres. For each application genre, there are different types of virtual contexts within which users typically work or play. The three application genres are as follows:
- productivity applications—This genre of applications enables users to accomplish their work and supports complex tasks like creating, editing, analyzing, or organizing information—such as documents, presentations, graphics, photos, videos, spreadsheets, databases; communicating via email, instant messengers, or social networking services; maintaining a personal calendar; searching; getting directions; shopping; or doing online banking. Virtual contexts for productivity applications focus on users’ tasks, often present detailed textual and visual information, and usually offer their functionality through fairly standard user interfaces.
- utility applications—These applications let users either perform simple tasks that require only minimal user input or quickly look up specific types of information. Examples of utility applications include control panels, desktop widgets, and many mobile apps—for example, apps that provide current weather or traffic conditions, stock prices, or sports scores. Virtual contexts for utility applications display information in highly visual, easy-to-scan formats and let users easily modify simple settings.
- immersive applications—This genre encompasses virtual worlds, personal computer games, online multiplayer games, ereaders, media players, and even virtual tools—for example, media capture tools that let users take photos or record video or sound. Immersive applications focus on users’ experience of primarily visual content—whether they’re playing games, watching media, taking photos using their phone’s camera, or using other simple tools. They present their capabilities via richly rendered, highly detailed, often full-screen virtual environments or objects that emulate their real-world counterparts.
Presentation of Applications’ Virtual Contexts
A key factor in designing an application’s primary context for interaction is deciding how best to present the functionality and information the application provides. What should its overall structure be? To what do you want to draw users’ attention? How do you want users to respond? These decisions are wholly dependent on the goals and needs of users and the kinds of tasks they can perform using an application. In About Face 3, Cooper, Reimann, and Cronin refer to an application’s presentation as its posture, but that term doesn’t resonate with me.
An application’s presentation encompasses the structure, hierarchy, look, and affordances of each virtual context within the application. Presentation also communicates a great deal about what users can do with an application, as well as how they should relate to the application.
The nature of particular features in an application and the virtual contexts in which they reside may require presentations that differ significantly from that of the application’s primary context. So, consider the desirable similarities and necessary differences between the presentations of the various contexts within an application, keeping in mind the purpose of each context.
Presentation Patterns for Contexts by Application Genre
Some familiar presentation patterns for virtual contexts of interaction occur in numerous applications, on various platforms. Applications that run on specific platforms and belong to specific genres tend to employ particular presentation patterns. A single application’s complexity can range from just one context and one presentation pattern to any number of contexts and the use of several different presentation patterns.
Here are some common presentation patterns for applications’ virtual contexts in each of the following application genres:
- productivity applications
- simple list
- tabular list
- columnar list
- grid
- master and detail
- detailed data
- canvas
- canvas and palettes
- worksheet
- dashboard
- utility applications
- control panel
- dialogue
- wizard
- tabular list
- grid
- master and detail
- detailed data
- immersive applications
- virtual world
- browser
- ereader
- media player
- virtual object/tool
Presentation Patterns for Productivity Applications
Productivity applications let users accomplish tasks that are important to them, and their functionality tends to be complex; therefore, they usually consist of multiple contexts for interaction. Today, productivity applications on desktop computers and the Web share similar capabilities and presentation patterns. However, the presentation patterns for productivity applications on mobile devices are somewhat limited, because of their small screens. Productivity applications generally employ standard user interface elements, and many organize data in hierarchical structures that progress from the general to the specific. In mobile apps, this typically means starting with simple lists and progressing to detailed data users can view or edit, displaying only one level in the hierarchy per context. What are some examples of presentation patterns for productivity applications?
Simple List
Many desktop, Web, and, especially, mobile productivity applications present data as simple lists that comprise a single column of data. For example, email applications, instant messengers, and mobile devices provide lists of contacts. Skype’s primary context is a list of contacts, as shown in Figure 1.

I designed the Address Book page shown in Figure 2—another simple list—for the scanR mobile Web application. Figure 3 shows a simple list of contacts in the iPhone Contacts app. As is usual in iPhone productivity apps, tapping an item in the list lets a user drill down to a detailed data view—in this case, the detailed data for a contact.


The Inbox in iPhone Mail, shown in Figure 4, is another example of a simple list that lets users drill down to detailed data.

Even activity streams—to which users can add microblog posts—take the form of simple lists. The Twitter Web application, shown in Figure 5, provides another example of an application whose primary context is a simple list.

Search results pages offer another common example of the simple list. Figure 6 shows iPad Search; Figure 7, a search results page on Bing.


Tabular List
Desktop, Web, and, occasionally, mobile productivity applications present data in tabular lists, comprising multiple columns of data. Each column in a tabular list has a header, and it is often possible to sort such a list by clicking a column header. Displaying reports and the contents of file systems are two common uses of tabular lists. Figure 8 shows a Google Analytics report on the Top Content on UXmatters that combines a sortable tabular list with a graph.

In Movable Type, the Manage Entries page displays a tabular list, with a few filters to the right, as shown in Figure 9.

Figure 10 shows the tabular list view of the Mac OS X Finder, which is sortable.

For the scanR mobile Web application, I designed a tabular list that displays the contents of a folder, as shown in Figure 11.

Columnar List
Columnar lists display hierarchies, with each level of the hierarchy displayed in a column, from left to right, so users can easily start browsing at any level in the hierarchy. Figure 12 shows the columnar list view of the Mac OS X Finder. Columnar lists typically provide alternative views of data that might also appear in hierarchical lists, tabular lists, grids, or Cover Flows.

Grid
Grid presentations comprise rows and columns of items and take many different forms—from the Mac OS X Finder’s grid view, shown in Figure 13; to the iPhone home screen’s grid presentation of application icons, in Figure 14; to iPhoto’s presentation of photos in a grid, as shown in Figure 15; to the grids of the monthly view in Google Calendar and the daily view in iPad Calendar, shown in Figures 16 and 17, respectively. Applications’ primary contexts of interaction sometimes employ grid presentations.





Master and Detail
Applications’ primary contexts for interaction often employ master-and-detail presentations. They comprise one or two master panes or areas—which, in the latter case, may appear either side by side or sequentially—and a detail pane or area. A master pane contains items at an upper level of an application’s hierarchy, which may be in a simple list, a hierarchical list in the form of a tree view or drawers, a tabular list, thumbnails, or a set of filters. The master pane can reside on the left side, at the top, or on the right side of a window, page, or screen. The detail pane contains detailed data, or content, which might include text, lists, tables, charts, graphs, diagrams, images, Web forms, or property sheets. Placing the master pane above the detail pane allows the master pane to accommodate list items with longer labels and, especially, tabular lists.
There are many different variants of the master-and-detail presentation. For example, the similar 3-pane, master-and-detail views of Mac Mail, shown in Figure 18, and Yahoo! Mail, shown in Figure 19, display the applications’ entire hierarchy through a simple list of mailboxes, a tabular list of messages, and a detailed data pane that contains the message that is currently selected in the tabular list. iPad Mail has a 2-pane, master-and-detail presentation, as shown in Figure 20.



Figure 21 shows the Cover Flow view of the Mac OS X Finder. The Cover Flow is in the top pane and provides an animated, 3D user interface that can successively display previews of documents. A tabular list of files resides in the bottom pane. A user can select a file in the list to display it in the Cover Flow.

The Google search results page, shown in Figure 22, has a column of filters on the left—in the master pane that controls the display of Web search results in the simple list on the right.

Zillow, shown in Figure 23, also has a column of filters on the left, which control the display of search results in the map and the simple list on the right.

iPad Contacts displays a user’s contacts in a virtual address book, shown in Figure 24. A user can tap a contact in the simple list on the left to display the contact’s detailed data on the right.

Figure 25 shows iPad Notes, which displays a simple list of notes on the left and a notepad on the right. Tapping a note in the list displays its detailed data on the notepad.

iPhone Calendar’s master-and-detail presentation displays a calendar in a List, Day, or Month view at the top and the detailed data for a selected event at the bottom, as shown in Figure 26.

When a productivity application has sufficient available screen real estate to accommodate a master-and-detail presentation, its use of adjacent panes to navigate the application’s hierarchy provides highly efficient workflows within the scope of a single virtual context.
Detailed Data
Most productivity applications display detailed data in a separate window—as Mac Mail does—or on a subordinate page or screen—like iPhone Mail. Figure 27 shows the window that appears when a user clicks a message in the Inbox’s master list in Mac Mail; Figure 28, the corresponding screen in iPhone Mail.


Figure 29 shows the detailed data that appears when a user taps a contact’s name in iPhone Contacts’ simple list of contacts.

iPhone Maps presents detailed data in the form of maps, as shown in Figure 30, and directions.

Canvas
Simple productivity applications often employ canvas presentations that comprise a single window, page, or screen. Such applications support the creation and editing of simple documents such as notes and email messages. Figures 31 shows iPad Notes. Figures 32, 33, and 34 show the screens for composing email messages in Mac Mail, iPhone Mail, and iPad Mail, respectively.




Canvas and Palettes
In applications with canvas-and-palette presentations, the canvas is the space in which users create content, while the palettes provide tools that let them format and style the content. Many applications’ primary contexts of interaction employ master-and-detail presentations. In fact, a lot of the applications UX professionals use daily in their work have presentations comprising a canvas and palettes, including Dreamweaver, which is shown in Figure 35, Microsoft Word, InDesign, Visio, OmniGraffle Professional, Photoshop, Illustrator, Fireworks, Keynote, and PowerPoint.

In Movable Type, the canvas area on the Edit Entry page, shown in Figure 36, lets users create blog posts, and the palettes on the right let them set publishing parameters and define metadata for a blog post.

Worksheet
Spreadsheet applications simulate the presentation of the paper accounting worksheets people used in the days before personal computers. A worksheet comprises rows and columns of cells that form a grid. Each cell in a worksheet can contain either text, a numeric value, or a formula. Excel and other similar applications let users create spreadsheets. Figure 37 shows a worksheet in Excel.

Dashboard
Dashboards provide an overview of information that is essential to completing the tasks users perform using an application and let users drill down to view or edit more detailed information. Much of the information on dashboards takes the form of lists, charts, graphs, information visualizations, and tables.
Stephen Few, author of Information Dashboard Design, has defined a dashboard, as follows:
“A dashboard is a visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance.”—Stephen Few
For more detailed information about dashboard design, read my review of his excellent book.
Figure 38 shows the Google Analytics Dashboard; Figure 39, a Dashboard I designed for the GetJar Developer Zone.

