Traditional requirement specifications can be enhanced with UX information in two main ways:

  • Feature requirements can be based on information collected during the user research phase. Here, user research complements market research data and other sources of product development information. Basing feature requirements on actual user data collected during research reduces the risk of investing resources in unwanted features and increases the likelihood of adding features that will drive sales.
  • UX-specific requirements can be added to the requirement specification. By adding UX requirements, UX becomes a priority alongside other product attributes and UX improvements are delivered when the product ships.

The development of UX requirements begins by looking for overlap between the business objectives defined in Phase 1 and user data collected in Phase 2. For example, a business objective for an accounts receivable contact center may be to reduce average call time by 15%. Field research at this center found that support staff spent an average of 20 seconds per call finding a customer’s record. A UX requirement to reduce seek time from 20 seconds to 5 seconds per call would make a significant contribution to the business objective and may be quite realistic from a UXE perspective. If this UX requirement can be implemented within technical and project constraints, then it is added to the product specification.

UX requirements may be qualitative or quantitative. Qualitative requirements are broad statements that inform the many design decisions that are made as a project progresses. For example, “The tourist information kiosk will be easy for first-time users to learn how to use.” Quantitative requirements are specific, for example, “Four out of five first-time users of the tourist information kiosk will be able to find directions to a specific restaurant within a minute” or “On first impression, users give the tourist information kiosk an average attractiveness rate of 4 on a scale of 1 to 5.” These quantitative requirements are validated during UX testing.

Qualitative requirements are useful to set the overall direction of the UXE design effort; however, quantitative requirements are essential to ensure that UX remains a priority as design deadlines approach. Which lead us to our next section, UX design.

Work products: UX requirements are typically included in with other product requirements in the requirement specification.

Phase 4: UX Design

UX design typically progresses in several iterations, with each iteration producing a model or prototype of increasing detail and granularity. In the simplest project, a sketch of the product’s user interface is produced and evaluated (using methods described in the next section (see p. 26). This is refined and reevaluated until it tests well. Then a more detailed physical or electronic version of the prototype is produced, evaluated, and revised until the UX requirements defined in Phase 3 are demonstrated. Finally, a full version is developed and tested.

Complex projects and products may require more levels of iteration and additional models. For example, if a new product requires a substantial change in the individual’s or organization’s workflow in order to realize productivity gains, work reengineering may be appropriate. Work reengineering is a re-conceptualization of work process that incorporates the (tentatively defined) new product, so that efficiencies of automation are realized, business goals are supported, and retraining is minimized. Work reengineering efforts are typically represented in a revised task profile that is validated by the users before detailed design begins.

For large, complex Web sites or applications, an information architecture blueprint is produced to represent the overall site structure without concern for the appearance of the page [115]. First, a high-level blueprint is developed, grouping areas of the site semantically. Next, task-level or page-level blueprints are developed. Users validate these before page-level design begins. The equivalent model in object-oriented software development projects is a content diagram on which the use cases that define user-system interaction are based.

Once high-level issues are resolved, detailed design can begin, typically with a low-fidelity prototype. For physical products these are constructed from foam, plastic, or wood, for software and Web sites they are often hand-drawn on paper and called mockups or wireframes. At this level, the focus is on getting the behavioral experience right by developing the structure and user interaction; aesthetic aspects are not yet considered. The low-fidelity prototype is refined and reevaluated until it tests well, at which point a high-fidelity prototype is produced.

High-fidelity prototypes for physical products have similar production quality to the final product, while for software and Web sites they are electronic. Core features are developed and tested and the prototype is revised until the behavioral UX requirements defined in Phase 3 are demonstrated. Once the overall structure of the product is defined, various aesthetic presentations can be designed and tested for visceral and sociocultural appeal. Finally, with a prototype refined to address critical issues in hand, the rest of product can be designed and tested.

Many design choices must be made when developing a complex product. Although user research can provide guidance about what features are needed and how they can be structured, research does not offer much insight about the fine details. To fill this gap, UX design incorporates design principles based on knowledge from perceptual, cognitive, and social psychology. Here are a few examples:

  • Research in perceptual psychology has shown that objects that share a contour are perceived as related and part of a whole (the Gestalt principle of good contour [61] or direction [136]). For example, separate blocks of text and graphics become associated in our perception if they are aligned along an invisible grid [76]. And the clean lines of an elegantly-designed product provide a satisfying unified appearance [68]. In fact, research shows that GUIs and Web sites with aligned text and graphics are preferred by users and easier to read [97; 130]. Other research has demonstrated that consumer products with good contour and a unified appearance are also preferred, being described as refined, elegant, simple, and deluxe-looking [134]. So products designed with good contour in mind provide an appealing visceral and behavioral experience.
  • Research in cognitive psychology has demonstrated that recall of information organized in a hierarchy is two to three times faster than information grouped in other ways [13]. This is because items on the top of the hierarchy (categories) act as recall cues for items low in the hierarchy [55]. Research has demonstrated that software [21] and Web sites [27; 67] organized hierarchically provide a better behavioral experience than those that do not.
  • Research in social psychology has demonstrated that praise is a powerful persuasive tool [56; 96]. Human-computer interaction research has shown that users who worked with a computer system that praised them were left in a better mood, felt more powerful, found the interaction more engaging, and liked the computer more than those who were not praised [40]. This finding is of particular importance for designers of e-learning and e-commerce products who can enhance their user’s sociocultural experience simply by including dialogue messages that contain the right kind of praise.

These are only a few examples of principles that can be used to guide design choices. There are many more, some based on psychological research and others based on design tradition and practical experience. One way to formalize design guidelines, particularly for GUIs and electronic documents, is to use a style guide. A style guide describes design guidelines, user interface controls, as well as screen layout conventions, and is an effective way to ensure UX consistency. Platform specific style guides are available for the development of desktop software on all major platforms including Windows XP [79], Windows Vista [80], Macintosh [4], UNIX [127], and Java [125]. These form a useful base to which you must add application specific details.

With the product prototype developed, we are ready for the final step in UXE lifecycle, UX evaluation.

Work products: Prototypes are the primary deliverable from this phase. These can be low-fidelity mockups or wireframes or high-fidelity functional models that implement core features. Work reengineering models and information architecture blueprints may also be useful, especially for more complex project or products.

Contents, User Experience Engineering (UXE) Essentials Series