Applying Lessons from UML to UX

By Peter Hornsby

Published: November 22, 2010

“Many people tend to look at programming styles and languages like religions: if you belong to one, you cannot belong to others. But this analogy is another fallacy.”—Niklaus Wirth

“Unified Modeling Language (UML) is probably the most widely used modeling language among software engineers.”

Software Engineering is typically much more formal than User Experience in they way they model an application before development begins. After pseudo code, the Unified Modeling Language (UML) is probably the most widely used modeling language among software engineers. It has developed from other object?based analysis and design languages over a period of many years and provides software engineers with a visual language that describes the design of a system at multiple levels.

Comparable UX design artifacts such as user journeys and personas can take a wide variety of forms. While this diversity can enable us to tailor our design artifacts to different circumstances, drawing features from modeling languages such as UML could promote better cross?functional work practices, increase a design’s reusability, and reduce the overall effort of developing software systems.

This article looks at how User Experience can use UML modeling techniques to enhance user journeys and promote better cross?disciplinary collaboration.

Use-Case Modeling

“Use cases are analysis artifacts rather than design artifacts, but product teams tend to refer to them throughout the life of a project, because use cases provide a quick way to understand what a system does.”

Most product teams that use UML begin by developing use cases, which provide a good overall view of a software system’s capabilities. Strictly speaking, use cases are analysis artifacts rather than design artifacts, but product teams tend to refer to them throughout the life of a project, because use cases provide a quick way to understand what a system does. Use cases support UX design by

  • providing a high-level view of a system’s functionality and boundaries
  • identifying user-interface requirements—as well as opportunities for further UX involvement on a project

Developers of use cases typically express them in two ways. First, they create a use-case diagram, which captures a use case—the sequence of actions a system carries out; the actor—the person or another system with which a system interacts; and the relationships between the two. A simple use-case diagram looks like that shown in Figure 1.

Figure 1—A simple use-case diagram

Simple use-case diagram

Second, they create a behavioral specification, which defines the interactions that take place within a particular use case in more detail. While it’s true that UML is in wide use among software developers and lets them capture a high degree of detail, it’s actually possible to write a behavioral specification at different levels of detail. From a UX designer’s perspective, it is better to keep behavioral specifications at a high level during the early stages of a project, without getting into too many of the details of a design. However, detailed design does sometimes occur early in a project. You can use different formats for a behavioral specification, including

  • a block of prose
  • a numbered sequence
  • a partitioned narrative that separates the actions of each party

What Distinguishes Use Cases and User Journeys?

“Both use cases and user journeys capture interactions with a system, but user journeys focus on the user experience.”

A use case isn’t that far removed from a user journey. Both use cases and user journeys capture interactions with a system, but user journeys focus on the user experience. In a poor design process, use cases might start to define the user experience. In such situations, the job of UX designers becomes more difficult, because the use cases then constitute a barrier they must overcome. (Similar problems can occur with poor implementations of agile development processes.)

To a certain extent this is understandable, because the purpose of a use case is to identify and start to describe interactions, and many people find it easier to describe how this would happen rather than leaving a requirement open ended. In a development process without sufficient UX involvement, overly specific requirements can then become carved in stone, with the result that a UX designer faces a major challenge in influencing the design direction. The only way to prevent such situations from arising is to agree up front that it’s the role of the UX designer to own UX design, and if such situations do arise, to push back as early as possible.

Defining Use Cases

“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.”

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.

 

Figure 2—Diagram of a credit-card payment use case

Diagram of a credit-card payment use case

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.

Figure 3—A use case with an include relationship

Use case with an include relationship

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.

Figure 4—A use case with include and extend relationships

Use case with include and extend relationships

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

“Creating user journeys is a valuable part of the analysis and design process, but it can be time?consuming.”

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.

2 Comments

Nice article. I’m fairly new to UX design, but I was recently discussing personas and thought that modeling the user flows might be possible with use cases.

You might have seen yUML? It’s a tool I created to make it easy to construct / generate use-case diagrams without the need for desktop tools.

Nice post. You may be interested in the UML online modeler called GenMyModel. It designs UML-compliant models in a Web browser and generates code.

Join the Discussion

Asterisks (*) indicate required information.