When Visual Models are Better than Textual Requirements (Part III: User Flow Diagrams)

Let’s face it, textual requirements are not great at clarifying the sequence of interactions a user has to go through as they try to accomplish a task or achieve desired outcome. Use cases can be a little better, describing the steps that demonstrate all interactions the user has with the system. Take for example Scott Sehlhorst’s example of an online purchase, in which the normal flow goes like this:

1. The user will indicate that she wants to order the items that have already been selected.
2. The system will present the billing and shipping information that the user previously stored.
3. The user will confirm that the existing billing and shipping information should be used for this order.
4. The user will confirm that the order information is accurate.

5. […]

Still, when you’re trying to convey to business and technical stakeholders the journey the user will have to go through to accomplish a goal like making an online purchase, a visual representation describing the specific sequence of action leading the customer to the desired outcome is going to be much better. As explained in this article from Signal v. Noise, 

Flows written down into stories or paragraphs are hard to reference and they don’t easily decompose into checklists for design and review.

The article shows how to create one of my favorite visual representations: the user flow diagram. Below is my adapted version of the main component of this type of diagram:

Shorthand to represent steps in an interaction between user and system.

Sometimes, users may choose different actions as their next step, in which case we can use a modified version, like this:

Alternative notation for more complex flows

Let’s take a look at the online purchase use case described using this notation (in the scenario depicted, a registered customer has logged in, added products to a shopping cart, and is ready to start checkout):

Don’t you find it much easier to visualize the different scenarios that need to be accounted for using this type of diagram compared to textual requirements or even a use case?

For example, when the customer is looking at the “updated shopping cart”, in this diagram it’s easier to identify all the potential steps he/she would want to take from there:

  • Change their mind about a product or quantity, and update the shopping cart.
  • Proceed to checkout.
  • Decide to continue shopping.

Now you can account for all these actions that users may want (or need) to take in your textual requirements, use cases, user stories, wireframes, or other artifacts that may be used to produce a shared understanding of what needs to be built. Through conversations with business stakeholders (and ideally end-users as well), you may identify additional paths that should be available to improve the overall user experience:

From “Form with fields to enter new billing and/or shipping information”:

  • Optionally save the new information in the customer’s permanent records (if this is meant to be the new default for the customer as opposed to a temporary choice).

From “Order details”

  • Quickly edit products or quantities in the cart, or billing or shipping information, without having to go back multiple steps.

Note that these additional requirements could be considered “nice to have”, and simply added to the backlog for future consideration. Still, as with the relationship map described in the last article, this kind of  visual representation increases the opportunities to identify f potential improvements to the workflow.

The main difference between the user flow diagram described here and a relationship map or swimlane diagram is that the user flow places more emphasis on the user journey, highlighting all the steps required by a user to accomplish a task or a achieve a desired outcome. For that reason, they are particularly useful when you’re trying to identify and communicate requirements for customer-facing applications, since in this case providing an optimized user experience through a more pleasant sequence of interactions with the system can become key to ensuring better business results through improved customer satisfaction, loyalty, and retention.

This is Part III of a series. Read also Parts I – State Diagrams and II – Relationship Maps.