The User Experience

One of the first activities in the elaboration phase is to analyze the use case model and to identify the objects that will implement the behaviors described in the use cases. This activity is commonly called analysis, or more properly use case analysis. The activities of use case analysis begin with an examination of the use cases and the other requirements of the system. The analyst examines these documents and starts to identify objects that collaborate to deliver the functionality described by the requirements. For most client/server systems, this begins by identifying high-level objects that correspond to the system's entities, controllers, and boundary interfaces. These activities are described in more detail in Chapter 10. This chapter focuses on a new concept in modeling Web systems and introduces the user experience model to the Web application development process. The development of the UX model often happens in parallel with other analysis activities (see Chapter 6, Process).

The term user experience (UX) is receiving considerable attention in Web application development circles and is used to describe the team and the activities of those specialists responsible for keeping the user interface consistent with current paradigms and, most important, appropriate for the context in which the system is expected to run. The UX team is responsible for creating the look-and-feel of the application, determining principal navigational routes through the system's Web pages, and managing/organizing the structure of the content in the pages.

This group is responsible for developing the Web application's "emotion," which includes everything from the colors and fonts to the structure and positioning of the content, or information, on the screen to the navigational flows through the individual screens of information to any navigation to or use of external systems by the user. Some of this information is architecturally significant, whereas some is purely cosmetic. Because this book is about modeling Web-centric systems in UML and is not a book on art, we'll focus on the architecturally significant aspects of the user experience and how they connect with the rest of the software system. This isn't to say that the graphic arts, layout, and other artistic elements of the user interface aren't important; they remain a true art form and are less a science.

One specialist on the UX team is the information architect (IA),[1] whose focus extends the traditional user interface/human interaction (HI) skills and branches out to include the entirety of the "user experience." The IA is concerned with the information, content, of the screens, their organization, and their navigation. The IA brings some science to the user interface. In general, the IA is responsible for the overall layouts of the screens, the nature and limits of their content, and the flow of navigation through the application's screens.

[1] The Argus Center for Information Architecture is an excellent starting point for information on information architecture (http://argus-acia.com/index.html). Info.Design is another good resource for IA-related material (http://www.infodn.com/iares-print.shtml).

The user experience is driven and shaped by two philosophies: the art and the architecture. The IA must balance the technical constraints of Web-centric architectures with the artistic requirements that make the application aesthetically pleasing. The principal artifact the IA is responsible for is the UX guidelines document. This document, developed at about the same time as the initial use cases, defines the overall look-and-feel and provides a foundation of rules and regulations for defining new screens and flows.

The tools of the UX team's trade are visual. Prototyping is perhaps the primary activity. Prototypes can take many forms. Some of the earliest prototypes are simple hand-drawn pictures. As they progress, they may take the form of wire frames, typically created with a drawing tool, such as Visio or Adobe Illustrator. Combined with use case specifications, these prototypes are good for storyboards describing specific scenarios of flow through the system's screens. The prototypes are also good for understanding the structure of compartmentalized screens and can give stakeholders an early and tangible view of the system.

In Web applications, the user interface is almost always a set of Web pages, with each page containing static and dynamic content. Use case scenarios are typically executed across a number of Web pages. The navigational routes through these pages become an architecturally significant element of the system.