How can state diagrams help designers?

A state diagram (also known as a state-transition diagram or state model) may sound like an engineering buzzword from the 1980s, but it is a powerful tool that UX/UI designers can use in their projects. In a UX/UI design project, UX focuses on the journey, while UI focuses on states and transitions between them. A state diagram is highly flexible, so you can adapt it to your needs. As a bonus, developers can easily understand it. Let’s look at what it is and how you can use it. (user experience and user interface) (user experience) (user interface)

What is a state diagram?

A state diagram is a visualisation tool “used to describe and analyse the different possible states of an entity within a system” (Business Analyst Body of Knowledge, v3, 2015). An entity can be any object within a system, depending on the system you are designing or analysing. In a design system, the entity is already clearly defined: it is called a component, such as a colour, button, header, table or page.

A state is also a familiar concept in UI design: for example, a button can have a pressed state and a default state. Not all components have different states; a primary colour, for instance, typically has no states, though the components that use it may do. These entities can have states that “do” something either on their own or as the result of a user action. A basket in an online shop can be empty or not empty, a form field can be active or inactive, and so on. More complex components can also have states: a search results list can be empty, and may behave differently in this state from when it contains results. (user interface)

A component with multiple states may move through them in a predefined sequence, and in most cases the transition from one state to another follows certain rules. For example, in an online shop an empty basket cannot have the “paid” state; it must first contain something. An inactive button cannot be pressed; it must first become active. So when a component has several states, not every transition from one state to another is valid.

In a state diagram, we use boxes to represent states and arrows to represent valid transitions between them. State diagrams are, in a sense, complementary to activity diagrams: in an activity diagram, the boxes represent activities (transitions) and the arrows show states.

Let’s look at an example. We worked on the design for a document management system implementation project for a pharmaceutical company. In this system, a document could have the following states:

• Edit: from the moment a user creates the document, they can edit it. Until the document owner sends it for approval, it is considered to be under editing.
• Waiting for approval: In this state, the document cannot be edited and is with the managers, who can either approve or reject it. Once approved, it moves to the approved phase. Once rejected, it returns to editing.
• Approved, waiting for signature: When all approvers have approved the document, it goes to a further management level for signing. Signatories can still reject it, in which case it returns to editing. Once all signatures have been collected, it moves to the signed state.
• Signed: All signatories have signed the document. It can be distributed internally or sent back to the vendor, depending on the nature of the document. It can no longer be edited; it is a “final” version.
• Invalid: If a new version of the same document receives all signatures—for example, an internal holiday policy—the previous version becomes invalid.

Let’s see what these steps look like in a state diagram:

How can we use a state diagram?

All visualisation methods are recommendations rather than rules. We can adapt them to our needs. No teacher is standing behind you to check how precisely you use a state diagram. Business analysts love to standardise their tools, but just because your language has a formal grammar book does not mean you cannot say what you want, in the way you want. Let me show you what I mean.

A state diagram in the format above may seem useful at first, but it is difficult to add other information to it. So first, let’s make it one-dimensional and flatten it. This means placing the states in a single row—it may result in too many arrows around them, but that is the trade-off we make.

We can now add another dimension to the diagram, turning it into a matrix. I recommend adding components along the other dimension, so we can show how each component looks in every state. You can simply add a description, or add visual versions to the matrix—it depends on what is easier to understand and create. I recommend including only the components that change according to the states, rather than every component, to avoid making the matrix too large and unusable.

We can also add functionalities along the other dimension and show which user groups have permission to access them in each state.

This gives us a user rights matrix, and developers will be extremely happy. Another benefit of this user rights versus state matrix is that there are no gaps: since the matrix contains every function and every state, and we have filled in every cell, there can be no special case we have not considered.

The good news is that the two previous matrices can also be combined: states, key components and permissions can all be included in one matrix.

How do state diagrams help design?

I believe state diagrams are natural tools in the UI design process. In UX, we focus on the customer journey, which is an activity-oriented approach. Once we need to design the final screens, we need to shift to a state-oriented approach: building UI components and defining how each screen should behave. People carry out processes; screens have states. Once we have defined the journeys and screen flows, we need to distil the states of these components. In some cases, these states are straightforward, such as the active and inactive states of a button. For more complex components or processes, however, they are far from straightforward. You therefore need a good tool to collect, describe and visualise these states: the state diagram. (user interface) (user experience)

A state diagram is also a quality-control tool: once you have identified all possible states of the main components, you can see whether you have considered every state of the smaller components. Used in this way, a state diagram is a double-checking tool—a framework that needs to be completed.

State diagrams also help when communicating with developers, as they tend to look for gaps in process-oriented designs. Once you have defined every state and every component in each state, there are no gaps—and a happy developer is half the battle.