Applying Lessons from UML to UX

Defining Use Cases

In a conventional UX design process, where use cases describe requirements, the use cases can be a starting point for a UX designer to explore interaction scenarios and identify how different personas would interact with a system. It’s important to note that, in use cases, an actor isn’t necessarily a persona. In use cases, an actor could be anyone or anything that interacts with the system—thus, it could be a human being or another system. Human actors are typically named for the roles they play.

A basic use case might simply illustrate an actor’s involvement in the use case. But use-case diagrams can show more detailed types of relationships, which you can apply equally well to user journeys. These include the following:

• generalization between use cases—Sometimes, several use cases might differ only in minor details. Generalizing a use case abstracts the common features, which another use case can then inherit.
• include relationships—One use case can include the functionality of another use case.
• extend relationships—A use case can optionally extend another use case—for instance, where multiple payment types are available.

People frequently confuse include and extend relationships. The key to differentiating them is understanding that include means the included use case always takes place, whereas extend is an optional relationship. You can apply these same principles to user journeys. Breaking user journeys down into their component parts, then referring to these parts and reusing them, provides a UX designer with a much greater degree of control, for less effort than is typically possible—particularly if you can link the user journeys to a prototype.

Although user journeys can have a range of formats, let’s look at a simple example that describes making an online payment on a credit-card account. A simple user journey might cover a user’s progression from signing in to making payment, as Table 1 shows. Figure 2 illustrates this same simple use case in the form of a diagram.

Table 1—User goal: To make a payment on a credit-card account

Step	User	System	Potential Issues
1	Clicks Sign In.	Displays sign-in form.	Login server may be down.
2	Provides account details.	Checks details. Displays account overview screen.	User may forget username or password.
3	Clicks Make Payment.	Displays payment form.
4	Enters debit card details.	Checks payment details.	Payment details may be unavailable or wrong.
5	Clicks OK to submit payment.	Confirms successful payment to user.

But we know that, in the real world, we would want to do a lot more with this user journey. Our system would have a lot of other features in addition to making payments. So, first, let’s separate out the process of signing in. The diagram in Figure 3 shows that a user can sign in independently of making a payment, but making a payment requires the user to sign in.

Separating out the sign-in process lets us map the user journey in more detail. As Table 2 shows, the description of the user journey now covers the handling of problems a user might encounter when signing in, making it a more complete and comprehensive piece of work, which gives a UX designer greater control over the details of the ultimate implementation.

Table 2—A more detailed sign-in user journey

Step	User	System	Potential Issues
1	Clicks Sign In.	Displays sign-in form.	Login server may be down.
2	Provides account details.
2.1	Types user name.		User may forget user name.
2.1.1	Clicks Forgot user name link.
2.1.2	Types email address.
2.1.3	Clicks OK.	Verifies email address, then sends user name in email message.	Application may not know user’s email address.
2.2	Types password.		User may forget password.
2.2.1	Clicks Forgot password link.
2.2.2	Types email address.
2.2.3	Clicks OK.	Verifies email address, then sends password reset instructions.	Application may not know user’s email address.
3	Clicks OK.	Verifies user’s information, then displays Web page or screen that appears when user first signs in to application.

Breaking out this piece of functionality into a separate user journey lets us reuse this use case in multiple contexts, and if necessary, describe its error handling. In principle, we could reuse this use case in any application. We could, alternatively, write out the same set of instructions every time we design an application. But by modularizing our user journeys, we can both save ourselves considerable effort and increase the reusability of our design artifacts. This, in turn, gives us greater control over how development teams interpret and implement our UX designs. Plus, it potentially makes their implementation of that piece of functionality reusable, too.

As Figure 4 shows, we can use an extend relationship to show how a system handles multiple card-payment types.

Each payment type would then have its own separate user journey, which, in turn, would let us provide more detail and make our user journeys more reusable—not only within one project, but across projects.

In Summary

Documenting our designs can be somewhat hit and miss, with design artifacts that cover only a small portion of a system’s possible interactions. Creating user journeys is a valuable part of the analysis and design process, but it can be time?consuming. Drawing on UML notation

• enables a UX designer to provide a visual overview of a system’s functionality
• promotes closer collaboration and communication with software engineers
• promotes more rapid development through reuse

In principle, there is no reason why we could not further apply UML concepts to UX design. For instance, we could apply the same approach to personas, creating a base persona that captures a generic user and other personas that add to the base persona using an extend relationship.