Elastic Users, Actors, and Roles

In About Face 2.0, Alan Cooper describes the elastic user as an ill-defined user who’s characteristics change to suit the needs of the developer – sometimes an expert and sometimes a novice. However, some of the otherwise good techniques for managing actors and use cases exacerbate this problem instead of alleviating it. How should we manage use cases while still getting the benefits of Cooper’s insight?

Traditional Use Case Actors

In our previous article on actor hierarchies, we showed a method of classifying users based upon their roles. For example, a simple hierarchy for people who drive cars could look like the following:

When defining use cases, you identify the primary actor of the use case. Secondary actors represent other participants of the use case, not other people who can act as primary actors. This introduces a problem with keeping track of all of the users who can perform a use case.

Action-based Roles

In More About Software Requirements, Karl Wiegers proposes the notion of having action-specific roles.

In Karl’s example, he presents a use case of “Request Chemicals”, with a set of users who may want to request these chemicals:

• Chemist
• Chemical Technician
• Stockroom Staff
• Lab Manager

Each of these four user classes can request chemicals from the stockroom. Karl proposes identifying the users above as user classes, with an actor role of Chemical Requester. This way, you can define a single use case, with a single primary actor – the person requesting the chemicals, regardless of what user class the actor is in.

This solution is designed for situations where more than one person could act as the primary actor. When designing for organizations that have more rigidly defined roles, this is probably most common in manager-subordinate situations. Subordinates will always do thing X, and their managers will occasionally do it.

The problem is that it treats the unequal users as being equivalent – making the elastic user problem worse.

Solving Both Problems At Once

There is an approach that will effectively address both problems. It builds on our initial attempts to combine interaction design and structured requirements approaches.

The first step in validating a solution to these problems is to make sure we are supporting the primary reasons, or goals of writing use cases. The three highest priority goals are around communicating the intent of what the system has to enable users to do. The reason for consolidating use cases to improve the efficiency of communication when all of the users have to do the same thing. So we want to make sure our approach uses a single use case.

The second step is in recognizing and addressing, rather than side-stepping a misunderstanding of use cases. A formal use case includes both primary and secondary actors. In our How to Read a Formal Use Case article, we clarify that the primary actor is not the most important actor (with secondary actors being other subjects), but rather that the primary actor is the subject and the secondary actors are other participants (like the system).

While it might be confusing at first, there is nothing to prevent us from having multiple primary actors. The naming is a little unfortunate and misleading (“Primary Actor”), but there is no reason that there can’t be multiple primary actors. Each primary actor is one of the subjects who can be following the use case. The Secondary Actors term is unaffected – it still represents the other participants in the use case.

When defining these actors, we should not use action-based roles, as Karl suggests. We should keep the user-role-based roles (chemical technician, stockroom staff, etc). To prevent the elastic-user problem, we should define personas that represent members of the user-roles.

The key to this approach is remembering that a given use case describes what users must do, not how users will do it. It is imperative that we avoid design cues in the use cases. One benefit of persona development is that you provide guidance to designers and developers in how they choose to implement to support a use case.

When Different Users Do It Differently

As a quick “what about…?” question – what if the different users have different things they want (e.g. – it is not an identical use case)? Variations in the use case should be handled as alternate flows through the use case, with the most common mechanism being the normal flow.

This is a slightly orthogonal problem – using action-based roles does not address this, nor does persona development. It can be a problem to keep track of which users use which flows. If the use cases are sufficiently different for different users, then the right answer may be to make separate use cases. And if you implement different flows in different releases, that introduces another problem. Neither of which is made worse or otherwise addressed by this approach. We’ll leave that topic for a different article.

From the Implementer’s View

With this approach, the developer and designer will see the following:

1. A use case, such as “Request Chemicals”.
2. A list of the primary actors, or subjects, of the use case (chemical technician, stockroom staff, etc).
3. For each user-role based actor in the list, there will be at least one persona that represents the relevant user population.

The designer can then design implementations of the use case that will be good designs for the persona that represent the primary actors of the use case. The designer may need to make trade-offs between expert and novice interfaces – but it is no longer arbitrary, it is explicit.

Summary

There is a challenge in designing user interfaces that incorporate the (personal) needs of the people who will be using the system. Personas are very effective tools for conveying an understanding of user populations that will result in good design decisions. We can associate those personas with the groups they represent through user-role based actor definitions. And we can map those actors to the use cases they perform. Allowing for multiple primary users of a use case, we avoid the need to duplicate use cases when multiple actors may perform the same use case – without undermining our solution to the elastic user problem.