TL;DR:User flows help digital teams get on the same page and view the user interface and interactions holistically. User flows are typically made up of screens and components, nodes and connectors and notes and links. Collaboration can take the form of comments and annotation sessions.
When building a digital product on a team of almost any size and composition, I've found it helpful to get a complete birds-eye view of the user's journey through the product. This kind of view is especially helpful during discussions between engineers, designers and product owners.
Everyone should be on the same page about how the how the user will interact with the product and how the product should behave.
In this case, just having a collection of screen mockups doesn't quite do the job. We want to see the connections between screens and how they interact with the user.
In a previous article I discussed interaction wireframes – wireframes that include additional details about parts of the interface (via markers) and connections between screens or parts of screens (via connecting arrow lines with labels).
Recently user flows, a more advanced form of this, have come into vogue. In this article I'd like to describe what user flows are and their benefits.
Ingredients of a user flow#
Here's an outline of a user flow:
And an example – an emoji picker application:
Notice the following ingredients:
- Screens and components
- Nodes and connectors
- Notes and links
Let's dive into each.
Screens and Components#
User flows are screen-centric. Everything revolves around whole screens that users see. We are really trying to see the product as it appears to the end-user.
Desktop and mobile screens might sit adjacent, if the experience is very similar. But in cases where the mobile experience differs significantly from desktop, it's probably better to use entirely separate flows for each.
Screens are high-fidelity mockups – they really look like the real thing. In the "bad old days", it might have been advisable to use lower-fidelity tools such as wireframes and even hand drawings. In some cases these are still useful.
User flows, in contrast, take advantage of more modern tools.
- Design tools (such as Figma), which make it easy to create high-fidelity components and quickly assemble them into full screens and
- Collaborative whiteboard tools (such as FigJam and Miro), which allow screens to be quickly assembled into flows, in a real-time collaborative visual space.
Designers can consume design systems or component libraries, assembling pre-built components (either internal to the organisation or off-the-shelf) into full screens. For example Figma has Figma components.
With component re-use, full fidelity mockups become more effective than wireframes. They look realistic and make it easy for engineers to implement the screens using the natural reusability of frameworks such as React, React Native or Angular.
Using a collaborative whiteboard, designers can more easily communicate designs to engineers, who can also participate in the design, by asking questions, attaching comments to specific parts of the flow and/or participating in annotation sessions.
Nodes and connectors#
Screens can be connected together using connectors – lines with directional arrows, indicating visually how the user "flows" through the application. Various kinds of nodes can be inserted between connected screens, to indicate user actions, system events and processes, conditionals and terminators.
User actions
In the example, I use green circles or ovals for user actions.
The text should be very short, 1-3 words maximum. It should describe a specific user activity, such as "click", "hover", "submit form", etc.
System events and processes
In the example, I use blue rectangles for system events and processes.
System events triggered by user interaction should be described in brief words or phrases and directly connected to the screen or another node.
Processes are second-order events that are triggered by events, not directly by interactions. I use blue rectangles for these also and connect them to the relevant event. If a process is long-running or a background process, relevant to the screen but not tied to a particular node, I just place it nearby.
Conditionals and terminators
In the example, I use purple rhombuses for conditionals, such as "if foo then bar else baz".
Conditionals are especially helpful for engineers, who need to understand the pre-conditions for a screen or component to be shown to the end-user.
Terminators indicate the start or end of a flow. I like to use a "person" or "stick figure" symbol for the start, to orient the viewers to the fact that a real person will be going through this flow. I like to use a simple gray circle to mark the end of a flow, with perhaps a link to a subsequent flow or to the main screen.
Optional: Notes and links#
Small notes can be added underneath screens and components to provide additional information such as intended user experience, edge cases and justifications. These might be simply pieces of text underneath a screen or they might be numbered or bulleted lists.
Helpful links can be added, pointing to resources such as documentation, tasks in the task tracker, other user flows, chat discussions or anything else that's relevant to the screen.
Collaboration with comments and annotations#
Team members can add comments to specific elements in the flow using, say, the Comment tool in FigJam.
Also the team might run annotation sessions. These are online meetings in which team members take some time to add online sticky notes to parts of the flow, communicating questions, accessibility issues, engineering issues or anything other relevant communication.
