User Strategies: Considerations for UX Analysis and Design

So far, I’ve not used the term strategy in my description of this model. Strategy is simply the collective term for the methods, outputs, and selection criteria in this model. Often, I find it useful to analyze each of these elements of strategy separately. But sometimes these elements can be so intertwined that it’s useful to refer to them collectively as user strategy or user strategy analysis.

To illustrate this way of modeling user strategy, let’s examine a narrative description of a user strategy to identify each strategy element. (This example is based on a classic study from the 1970s, which Kim Vicente summarized in his book titled Cognitive Work Analysis. I’ve adapted his wording here.)

Research discerned the following strategies from observations of air traffic controllers:

• When there are up to three aircraft, air traffic controllers—especially those who are experienced—tend to provide an optimal path for each aircraft.
• Another approach is to assign uniform speeds and flight paths to all aircraft.
• Creating waiting buffers is a common approach when there more than six aircraft.

Table 1 shows how we can represent that narrative description in terms of the three elements of user strategy:

Table 1—An example representing the three elements of user strategy

Method	Output	Selection Criteria
Calculate the optimal path for each aircraft.	High-quality landing path	1–3 aircraft—that is, a low work volume; a highly skilled ATC
Assign a uniform speed and flight path to all aircraft.	Medium-quality landing path	4–6 aircraft—that is, a medium work volume
Create waiting buffers.	Minimally acceptable landing path	More than 6 aircraft—that is, a high work volume

Examining these selection criteria, a reasonable inference is that air traffic controllers switch to a less effortful method as work volume increases, which is a coping mechanism we often see in situations where users must handle a variable volume of work. In terms of user strategy concepts, the selection criteria in this particular example focus on the choice of method, which, in turn, determines the output. This example shows one of the possible relationships between these three components of a user strategy. Other examples later in this article illustrate some of the other possible relationships.

The Nature of User Strategies

Success favors the prepared mind, as the saying goes. Being familiar with the diverse manifestations of user strategies can help you successfully analyze user strategies on a given project. The UX literature includes snippets of user strategy analysis from many domains. We can also practice user strategy analysis simply by reflecting on everyday user activities—anything from choosing a password to investing savings so we can spend our retirement traveling around the world.

One generalization about the nature of user strategy is that strategies occur at every scale. Depending on the project, you’ll need to look at the appropriate scale to discern different user strategies. At the largest scale, strategies differ among different groups of people. For example, engineers and field service technicians would take different approaches to troubleshooting equipment failures, each appropriate to their distinct job conditions. So, basing a design simply on user research with engineers would fail to support the preferred working style of field technicians.

At the next smaller scale, we sometimes see different strategies among different individuals in the same job or demographic category. For example, different people use different strategies for generating their computer passwords. To mention only two possible strategies: Some people prefer passwords that are easy to remember, while others prefer passwords that are easy to type. So, to understand the full range of users’ possible password-setting behavior, we’d need to study a broad sample of people and look for patterns or clusters among the password-setting behaviors we observed.

At the smallest scale, the same person might employ different strategies on different occasions. For example, depending on their opponent, good chess players choose the most appropriate strategy within their broad repertoire. Another example of the same person’s switching strategies is when people shift to a less effortful method as their volume of work increases, as we saw in the case of air traffic controllers.

I’ll briefly note a few other characteristics of user strategies that are useful to bear in mind when analyzing them:

• Sometimes users can easily describe the strategy they are using, while, in other cases, they are not even aware they are using a particular strategy.
• Sometimes users’ stated strategy is at odds with their observable behavior.
• Sometimes users’ behavior is opportunistic. That is, once a user starts to perform an activity, some condition arises that causes the user to divert from the original goal or method to pursue a new course of action.
• Generally, it is possible to explain the choice of method or target outcome using one or more of the following types of selection criteria:
  
  • what is most important to a person
  • the person’s competencies or resources
  • the level of difficulty or uncertainty in the situation
• It is sometimes useful to describe strategies in terms of general styles such as defensive versus offensive; conservative or safe versus risky. In other cases, it’s more useful to describe user strategies in terms of a specific method—for example, in air traffic control, the method of assigning a uniform speed and flight path to all aircraft.

How to Address User Strategies in Design

The last question I’ll address in this article is this: Given a description of some user strategies, how should I address them in a design? Let’s look at all of the options, in no particular order. One option is to focus a design on supporting a single method—likely the most popular method. This seems like a common approach from what I have seen. One reason for this is that a design team might be familiar with only one method of achieving the goals a product addresses. Even when a design team has a good understanding of multiple methods in use across a user population, it often makes practical business sense to simply choose the most popular method and focus resources on supporting that approach.

The second option is provide separate user interface elements to support each method or user audience. From a textbook UX point of view, this option might seem like the only right answer. Such a design delights users who perceive that you’ve provided parts of the design just for them. However, this type of design can be risky to undertake because, among other things, it relies on a depth of user understanding that is not always feasible to acquire. So, pursuing this ambitious option entails the risk that one’s reach exceeds one’s grasp.

The final option is pursuing a generalized and flexible design that can accommodate the range of user preferences, without optimizing for any single method. On a recent project, I tried this approach, being at my wit’s end after exhausting many other design options. This project involved enhancements to a middleware product. Middleware refers to software such as application servers and database engines that a professional IT staff administers for large enterprises. The goal for this product was to make it easier to troubleshoot performance problems that occur. From time to time, performance slows down inexplicably, and the IT staff needs to resolve the problem.

For this project, I conducted extensive user research, which revealed a broad range of user strategies—in this case, mainly in terms of the methods they used. In fact, there seemed to be as many strategies as there were users. To further complicate matters, observational studies suggested that people’s actual behavior did not always match the method they articulated.

Things were looking grim until I realized their diverse methods included a handful of common diagnostic questions. For example, many people sought, at some point in their diagnosis, to identify which application transactions were using the most CPU resources. Once I realized that users’ diverse strategies comprised some common building blocks, I abandoned my initial design plan for a rigid, flowchart-like interaction. Instead, the design provided a modular toolbox, in which each tool answered a specific diagnostic question—such as Which application transactions are using the most CPU resources? The design gave users the freedom to pursue their own strategy, in terms of which diagnostic questions they wanted to answer and in what order.

In Summary

In this article, I’ve shared some guidance on how best to deal with user strategies in UX analysis and design. This guidance is based on my own experience. The questions I’ve sought to address are:

• What is a useful way of including user strategy in UX analysis?
• What should one look for when observing and analyzing user strategies?
• How can information about user strategies guide design?

You can apply these ideas whether conducting formal user research or simply discussing or thinking about how you envision users will use a product user interface your team is designing.

Further Reading

If this article has whetted your appetite, I suggest you read Chapter 9, “Strategy Analysis,” in Cognitive Work Analysis by Kim Vincente. While he covers this topic from the perspective of his analysis framework for cognitive work, it’s still good reading for the general UX audience.

Unfortunately, there is nothing more I can recommend from the UX literature—though my familiarity with that literature is incomplete. I did peruse a handful of books about task analysis and found little on this topic. Often the term strategy did not even appear in the index. I have found most of what I’ve learned about this topic from reading serendipitously—usually, a useful nugget in an article whose focus was not strategy analysis.

When I’ve presented on this topic, people have asked me what cognitive psychology research has to offer on this topic. The literature on decision making from Daniel Kahnemen and his colleagues is certainly relevant and fascinating. However, this research looks at the topic from a different perspective, making it difficult to apply to the questions I’ve addressed here—specifically: How can UX analysis and design take into account the phenomenon that people start with the same goal, but take quite different courses of action, resulting in outputs and outcomes that vary widely, even if they all achieve the original goal? 

Reference

Vicente, Kim J. Cognitive Work Analysis: Toward Safe, Productive, and Healthy Computer-Based Work. Mahwah, NJ: Lawrence Erlbaum Associates, Inc., 1999.