Calibration: What process means to us and others

To most people, including us:

Fine distinctions are unnecessary here, so we use the terms “process,” “lifecycle,” and “lifecycle process” more or less interchangeably. Here we introduce a lifecycle template, a skeleton representation of a basic lifecycle that you get to tailor to your needs by instantiating it for each project.

In your instantiation you get to determine your own process, choosing which activities to do and which techniques to use in doing them, as well as how much and how often to do each activity, and (perhaps most importantly) when to stop. Here, and in the other process chapters (Chapters 3 through 19), we offer guidelines on how to make these decisions.

What is a process?

A process is a guiding structure that helps both novices and experts deal with the complex details of a project. Process acts as scaffolding, especially for novice practitioners, to ensure that they are on track to a quality product and on the path to becoming experts. Process acts as a checklist for experts to make sure they do not miss any important aspects of the problem in the heat of productivity. A process helps designers answer questions such as “Where are we now?” and “What can/should we do next?”

A process brings to the table organizational memory from similar previous efforts by incorporating lessons learned in the past. In other words, process provides a repeatable formula to create a quality product. Process also alleviates risk by externalizing the state of development for observation, measurement, analysis, and control—otherwise, communication among the project roles about what they are doing is difficult because they do not have a shared concept of what they should be doing.

Why do we need a process?

Following a process is the solution recognized by software engineering folks long ago and something in which they invest enormous resources (Paulk et al., 1993) in defining, verifying, and following. On the UX side, Wixon and Whiteside were way ahead of their time while at Digital Equipment Corp in the 1980s and put it this way (Wixon & Whiteside, 1985), as quoted in Macleod et al. (1997):

 Building usability into a system requires more than knowledge of what is good. It requires more than an empirical method for discovering problems and solutions. It requires more than support from upper management and an openness on the part of all system developers. It even requires more than money and time. Building usability into a product requires an explicit engineering process. That engineering process is not logically different than any other engineering process. It involves empirical definition, specification of levels to be achieved, appropriate methods, early delivery of a functional system, and the willingness to change that system. Together these principles convert usability from a “last minute add on” to an integral part of product development. Only when usability engineering is as much part of software development as scheduling can we expect to regularly produce products in which usability is more than an advertising claim.

Without guidance from an interaction design process, practitioners are forced to make it up as they go along. If this sounds familiar to you, you are not alone. An approach without a process will be idiosyncratic; practitioners will emphasize their own favorite process activities while other important process activities fall through the cracks. What they do is dictated and limited by their own experience. They will try to apply the activities and techniques they know as much as possible; they have hammers and everything looks like nails.

As Holtzblatt (1999) puts it, following a process for product development can work against “the relentless drive of an organization to ship ‘something’ by a given date.” Other excuses for not following a proven approach included “we do not have time to do the whole method, so we do not do any of it,” “it does not fit well with our existing methods, that we are used to,” “can our designers really be trained to do this?,” and “do these methods transfer well to real-world project groups?” In this and the coming chapters, we hope that we can shed some light on answers.

A process is not necessarily rigid

Remember that a process does not necessarily imply a rigid structure or even a linear one. A process can be as lightweight or heavyweight as appropriate. In other words, even an incremental and iterative lifecycle approach in the software engineering world (such as an Agile methodology) is still a process.

Lest it still sounds inflexible, we should add that experts with lots of experience can interpret a process and take appropriate shortcuts and other creative liberties with it—and we encourage that throughout the book.

Analyze: Understanding the business domain, user work, and user needs

The left-most of the four basic activity boxes in Figure 2-2 represents the analysis process activity. Among the many possible sub-activities to support analysis are contextual inquiry (Chapter 3) and contextual analysis (Chapter 4) for studying customer and user work practice in situ, from which we can infer user needs for a new system design.

Extracting requirements (Chapter 5) from contextual data is another analysis sub-activity. The requirements, if you choose to use them, are interaction design requirements, inputs driving the design process and helping to determine its features and the look, feel, and behavior of the interaction design. These requirements are used as a checklist to ensure that they are covered in the design, even before any UX evaluation.

Finally, synthesizing design-informing models is yet another possible analysis sub-activity. Design-informing models (Chapter 6) are abstractions of different dimensions of the work activity and design space. If you choose to use them, these include models describing how work gets done, how different roles in the work domain interact, the artifacts that are created, and so on.

Design: Creating conceptual design, interaction behavior, and look and feel

The upper-most box in Figure 2-2 represents the process activity for design, including redesign for the next version. Among the possible sub-activities to support design are design ideation and sketching (Chapter 7), where the team does creative design thinking, brainstorming, and sketching of new design ideas. Design ideation leads to the representation of mental models, conceptual design, and design storyboards. During the exploration of large numbers of design candidates, it can include physical mockups of product design ideas.

Design production is a design sub-activity involving the details of applying requirements, design-informing models, and envisioned design-informing models to drive and inform the emerging interaction design. Design production entails prototyping and iteration of the conceptual design, intermediate designs, and detailed designs.

Prototype: Realizing design alternatives

The right-most of the four basic activity boxes in Figure 2-2 represents the prototyping process activity. Prototype building is often done in parallel with, and in conjunction with, design. As designs evolve in designers’ minds, they produce various kinds of prototypes as external design representations. Because prototypes are made for many different purposes, there are many kinds of prototypes, including horizontal, vertical, T, and local. Prototypes are made at many different levels of fidelity, including low fidelity (especially paper prototypes), medium fidelity, and high fidelity (programmed functional prototypes), and “visual comps” for pixel-perfect look and feel.

Evaluate: Verifying and refining the interaction design

The process activity box at the bottom of Figure 2-2 represents the UX evaluation to refine an interaction design. For evaluation to refine, you can employ rapid evaluation methods (Chapter 13) or fully rigorous methods (Chapters 12 and 14 through 17). This evaluation is where we see if we achieved the UX targets and metrics to ensure that the design “meets usability and business goals” (ISO 13407, 1999).

Flow not always orderly

The depiction of UX process activities in distinct boxes, as in Figure 2-2, is a convenient way to highlight each activity for discussion and for mapping to chapters in this book. These process activities, however, do not in practice have such clear-cut boundaries; there can be significant overlap. For example, most of the boxes have their own kind of evaluation, if only to evaluate the transition criterion at the exit point of each activity in the decision whether to iterate or move on.

Similarly, prototyping appears in many forms in other boxes, too. For example, the design activity entails lots of different kinds of prototypes, including sketches, which can be thought of as a kind of quick and dirty prototype to support rapid and frequent design idea exploration. In this same vein there can be a little design occurring within the analysis activity, and so on.

Managing the process with activity transition criteria

The primary objective of the overall lifecycle process is to keep moving forward and eventually to complete the design process and make the transition to production. However, for the work in a project to flow among the UX process activities, the team must be able to decide:

The answers depend on the transition criterion at the end of each process activity. There is no formula for determining transition criteria; they are generally based on whether designers have met the goals and objectives for the current iteration of that activity. Therefore, it is the job of the team, especially the project manager, to articulate those goals as transition criterion for each process activity and to decide when they are met.

For example, in the analysis activity, designers must ask themselves if they have acquired enough understanding of the work domain and user needs, usage context, workflow, and so on. Another component of any transition criterion is based on whether you have adequate resources remaining to continue. Resources limits, especially time and budget, can trump any other criteria for stopping a process activity or terminating the whole process, regardless of meeting goals and objectives.

Note in Figure 2-2 that the transition criterion coming out of each UX process activity box is a multipath exit point with three options: move forward to the next process activity, iterate some more within the current activity, or move back to a previous process activity.

The decision of where to go next after a given process activity depends on the assessed quality of the product and/or work products of the current activity and a determination of what next activity is most appropriate. For example, after an initial prototyping activity, a usability inspection might indicate that the design is ready for prototyping at a higher fidelity or that it is necessary to go back to design to fix discovered problems.

Knowing when you need inter-activity iteration depends on whether you need to pick up more information to drive or inform the design. When some of your inputs are missing or not quite right, you must revisit the corresponding process activity. However, this kind of inter-activity iteration does not mean you have to redo the whole activity; you just need to do a little additional work to get what you need.

Knowing when to stop iteration and proceed to production lies in a key process management mechanism. When UX targets (Chapter 10), often based on evaluation of user performance or satisfaction, have been employed in your process, project managers can compare evaluation results with target values and decide when to stop iterating (Genov, 2005).

Why do we even need iteration?

 Iteration is a little like the doctrine of original sin in interaction design: Most interaction designs are born bad and the design teams spent the rest of their lifecycles in an iterative struggle for redemption.

– Ford Perfect

Some people may question the need for iteration. Is not that just for novice designers who cannot get it right the first time? What about expert designers carefully applying complete knowledge of design guidelines and style standards? For any nontrivial interaction design, the UX process must be, and always will need to be, iterative. The design domain is so vast and complex that there are essentially infinite design choices along many dimensions, affected by large numbers of contextual variables.

To be sure, expert designers can create a good starting point, but because it is fundamentally impossible to get it all just right the first time, we need to use the artillery approach (Figure 2-3): Ready, Fire, Aim. We need to fire off our best shot, see how it missed the mark, and make corrections to home in on the target.

Iteration is not enough

 The road to wisdom? Well, it’s plain and simple to express: Err and err and err again but less and less and less.

– Piet Hein, Danish poet

So, if we must always iterate, is there any motivation for trying hard to get the first design right? Why not avoid the effort upfront and let this marvel of iteration evolve it into perfection? Again, the answer is easy. You cannot just test your way to a quality user experience, you have to design for it. Iterative testing and redesign alone will not necessarily get you to a good design at the end of the day.

As Wyatt Earp once said, “Take an extra second to aim.” Large interactive systems take a lot of time and money to develop; you might as well put a little more into it up front to make it right. Without an honest and earnest upfront analysis and design effort, the process tilts too heavily toward just evaluation and becomes a unidimensional diagnostic-oriented process.

To use a truly geeky example, consider a program traversing an n-dimensional surface, seeking a solution to a numerical analysis problem. If the search starts with the wrong “seed” or initial point (i.e., an initial solution that is too far from the actual solution), the algorithm might stop at a local optimum that is in a part of the search space, such as a saddle point, so remote from the optimal solution, if there is one, that you can never migrate out by any amount of iteration to get at a much better globally optimal solution. Similarly, in iterative interaction design, you can home in on the best details of a less-than-best design—honing a paring knife when you really need a butcher knife. Fixing the details of the bad design may never reveal the path to a completely new and better overall design.

So, the answer is about balance of all four process activities of Figure 2-1—analyze, design, implement, and evaluate—for a given amount of resources.

Start iteration early

The earlier the interaction design iteration begins, the better; there is no time to steer the ship when it is close to the dock. But the software implementation does not have to keep up with this iteration; instead we use interaction design prototypes, and there is no reason any production code should be committed to the interaction design until late in its lifecycle. Nevertheless, because the two roles cannot work in isolation, the software engineering people should be aware of the progression of the interaction design to ensure that their software architecture and design can support the interaction features on the user interface when it does come time to implement.

Typically, early cycles of iteration are devoted to establishing the basic underlying essentials of the design, including look and feel, and behavior, before getting into design details and their refinement. Project managers need to allow time for this explicitly in the schedule. It is an investment that pays generous dividends on everything that happens after that.

The rest of the process-related part of this book is mainly about iterating the activities in the diagram of Figure 2-2, plus a few other things in important supporting roles.

Complex interaction, complex work domain

In the upper right-hand quadrant of Figure 2-5 we show the interaction-complex and domain-complex systems, which are usually large and complicated. An example of a complex interaction is an air traffic controller deciding the landing orders for an incoming airliner. An air traffic control system also has enormous domain complexity, with workflow and collaboration among a large number of work roles and user types. Another defining example for this quadrant is a large system for the Social Security Administration.

Systems appearing in this quadrant are often associated with the greatest need to manage risk. Such projects will usually entail doing all the process activity boxes in detail, along with lots of iteration. These are the development projects with the greatest compliance requirements, the most weight given to traceability, and the highest importance of error avoidance.

For example, in mission-critical systems, such as for air traffic control or for military weapons control, there is great user pressure for error avoidance. When you cannot get these things wrong and the cost of failure is unacceptable, you need the most rigorous process, the full process spelled out in great detail in Chapters 3 through 18.

Because of their sheer size and need for rigorous processes, domain-complex and interaction-complex systems are typically among the most difficult and expensive to design and develop. A decidedly engineering approach to formal requirements can be very important to help designers touch all the bases and fill in all the blanks so that no functions or features are forgotten.

This is the kind of system for which design is most likely to need full lab-based user experience evaluation and iteration to produce a well-considered and coherent overall design. This is about the design of serious systems; this sector within the system complexity space has little, if anything, to do with emotional impact factors such as aesthetics, fun, or joy of use.

For large domain-complex systems, such as military weapons systems, you are most likely to encounter resistance to innovation. Radical designs are not always welcome; conformity can be thought more important. User and operators, in some cases, commit operations to habit and perform tasks with learned behavior even if there are better ways. This might be an opportunity for you to champion change and fight against the “this is not how we do it” syndrome, but you must approach this campaign with caution.

Gaming applications can be in this quadrant but they also can span both axes throughout the space.

Simple interaction, complex work domain

In the lower right-hand quadrant of Figure 2-5 we show interaction-simple and domain-complex systems. In this quadrant, user tasks are relatively simple and easy to understand. The key effort for users in this quadrant is understanding the domain and its often esoteric work practice. Once that is understood, the interaction is relatively straightforward for users. Tax preparation software for average households is a good example because the underlying domain is complex but the data entry into forms can be simplified to a step-by-step process.

In the UX process, interaction simplicity means that less attention to tasks descriptions is needed, but the domain complexity calls for more attention to contextual inquiry and analysis, modeling, and requirements for insight into internal system complexity and workflow among multiple work roles. Physical modeling and the social model of Chapter 6 become more important to gain access to the essentials of how people and information interact within the system.

Simple interaction, simple work domain

The simplest quadrant is in the lower left-hand corner of Figure 2-5, where both interaction and work domain are simplest. This quadrant contains smaller Websites, certain interactive applications, and commercial products. Just because this is the simple-simple quadrant, however, does not mean that the products are simple; the products of this quadrant can be very sophisticated.

Although emotional impact factors do not apply to every system or product in this quadrant, this sector within the system complexity space has the most to do with emotional impact factors such as aesthetics or fun or joy of use. This quadrant also represents projects that are design driven, where the UX process is all about design rather than user research or user models.

There is an abundance of relatively simple systems in the world. Some, but not all, commercial software products are domain-simple and interaction-simple, at least relative to large systems of other types. An example, shown in Figure 2-5, is a Website for ordering flowers. Interaction with this Website is very simple; just one main task involving a few choices and the job is done. Work domain complexity of a Website for buying flowers is also relatively simple because it involves only one user at a time and the workflow is almost trivial.

Because of the simplicity in the work domain and interaction in this quadrant, good choices for a UX process lean toward agile approaches with a focus on design and special rapid methods for evaluation. That translates to a low level of rigor; leaving out some process activities altogether and using lightweight or specialized techniques for others.

The best designers for expert users in this case might be “dual experts,” experts in HCI/UX and in the work domain. An example is a designer of Adobe Lightroom who is also deeply involved in photography as a personal hobby.

This quadrant is also where you will see innovative commercial product development, such as for an iPhone or a personal mp3 music player, and corresponding emotional impact issues and, where appropriate (e.g., for an mp3 personal music player but not for a florist’s Website), phenomenological aspects of interaction.

These products represent the least need for a complete rigorous lifecycle process. Designers of systems in this quadrant need not expend resources on upfront user research and analysis or requirements gathering. They can forego most of the modeling of Chapter 6 except, perhaps, specific inquiry about users and their activities, with a special interest in user personas.

Although commercial product design certainly can benefit from thorough contextual inquiry, for example, some successful products were essentially “invented” first and then marketed. The Apple iPad is a good example; the designers did not begin within a field study of existing usage patterns. They dreamed up a product that was so good that people who thought they would never be interested in such a product ended up fervently coveting one.

Projects in this quadrant are far less engineering oriented; design will be based almost entirely on a design-thinking approach. Designers are free to focus on imaginative design thinking, ideation, and sketching to make the user experience the best it can be. Processes for this type of system are usually faced with low risks, which means designers can put innovation over conformity—for example, the iPod over previous music players—and are free to envision radically new design ideas.

Early prototyping will center on multiple and disposable sketches for exploring design ideas. Later, low-fidelity prototypes will include paper prototypes and physical mockups. Subsequent evaluation will be about using rapid methods to get the conceptual design right and not being very concerned with user performance or usability problems.

Complex interaction, simple work domain

In the upper left-hand quadrant of Figure 2-5 we show interaction-complex and domain-simple systems. It is typical of an interaction-complex system to have a large volume of functionality resulting in a large number and broad scope of complex user tasks. A digital watch is an example. Its interaction complexity stems from a large variety of modal settings using overloaded and unlabeled push buttons. The domain, however, is still simple, being about “what time is it?” Workflow is trivial; there is one work role and a simple system ecology.

Attention in this quadrant is needed for interaction design—myriad tasks, screen layouts, user actions, even metaphors. Rigorous formative evaluation is needed for conceptual design and detailed interaction. The focus of modeling will be on tasks—task structure and task interaction models—and perhaps the artifact model, but not much attention will be given to work roles, workflow, or most of the other models of Chapter 6.

For simple work domains, regardless of interaction complexity, contextual inquiry and contextual analysis rarely result in learning something totally new that can make a difference in informing design. Rather, even more than for a simple interaction case, complex interaction requires a focus on ideation and sketching, as well as attention to emotional impact factors.

The commercial product perspective within the system complexity space

“Commercial products” is a good label for the area that spans the left-hand side of the system complexity space diagram in Figure 2-5, where you find relatively low domain complexity but variable interaction complexity. The more interaction complexity, the more sophisticated users can be.

Gradations within the system complexity space

Many systems and design projects fall across quadrants within the system complexity space. Websites, for example, can belong to multiple quadrants, depending on whether they are for an intranet system for a large organization, a very large e-commerce site, or just a small site for sharing photographs. Products such as a printer or a camera are low in domain complexity but can have medium interaction complexity.

One good illustration of complexity vs. process rigor is seen in systems for managing libraries, shown in the middle of the work domain complexity scale of Figure 2-5, near the bottom. Typical library systems have low interaction complexity because the scope of tasks and activities for any one user is fairly circumscribed and straightforward and the complexity of any one user task is low. Therefore, for a library system, for example, you do not need to model tasks too much.

However, a full library system has considerable domain complexity. The work practice of library systems can be esoteric and most UX designers will not be knowledgeable in this work domain. For example, special training is needed to handle the surprisingly important small details in cataloging procedures. Therefore, a rigorous approach to contextual inquiry and analysis may be warranted.

Because of the high work domain complexity, there is a need for thorough contextual data modeling to explain how things work in that domain. As an example, the overall workflow entails book records connected in a network, including cataloguing, circulation tracking, searching, and physical shelf location. A full flow model may be necessary to understand the flow of information among the subsystems.

Healthcare systems are another example of projects that cross system complexity space quadrants. Large healthcare systems that integrate medical instrumentation, health record databases, and patient accounting are another example of systems with somewhat complex work domains.

The healthcare domain is also saddled with more than its share of regulation, paperwork, and compliance issues, plus legal and ethical requirements—all of which lead to high work domain complexity, but not as high as air traffic control, for example. Machines in a patient’s room have a fairly broad scope of tasks and activities, giving them relatively high interaction complexity.

We refer to the system complexity space throughout the rest of the process chapters in discussions about how much process is needed. For simplicity we will often state it as a tradeoff between systems with complex work domains, which need the full rigorous UX process and systems with relatively simple work domains, which need less rigor but perhaps more attention to design thinking and emotional impact.

Since simple work domains correspond roughly to the left-hand side of the system complexity space of Figure 2-5, where most commercial products are found, we will often use the term “commercial products” as a contrast to the complex domain systems, even though it is sometimes possible for a commercial product to have some complexity in the work or play domain.