Flow chart symbols template via DePaul University

Creating Excellent UX Flow Charts

Illustrate complex processes by including use cases, actions, and life cycles

Flow charts remain my favorite artifact in the design process. With increasingly complex apps, flow charts help to model fluid, conversational experiences.

To that end, they answer two essential questions:

• When do we show specific bits of information?
• How do we respond to a user behavior?

Flow charts depict structures that are grounded in time and choice, the very same elements of a conversation.

I first wrote about flow charts in Communicating Design, a book that describes the working documents created during the design process and that maybe you should pick up.

Communicating Design: Developing Web Site Documentation for Design and Planning, by Dan Brown

The book describes the essential elements of flow charts and explains how to level-up your flow charting skills. It also shows how to use flow charts to facilitate conversations with clients. It’s a fabulous piece of work, really.

Pages 145–145 from Communicating Design’s chapter on Flow Charts

Flow charts, like any deliverable in the design process, is an excuse to talk to your team. As much as we like complaining about meetings and formal deliverables, the truth is that design work would come to a dead stop without (a) conversations and (b) pictures.

One thing I love about flow charts is that they offer tremendous flexibility. So, you can use a vernacular that’s appropriate for the challenges you face and their accompanying solutions.

In recent projects, I’ve used new techniques that build on the foundation in Communicating Design:

1. Connecting flows to use cases: Comparing flow charts to your inventory of user needs.
2. Showing menus and user actions: Embedding user choices into the diagram.
3. Showing object lifecycles: Making explicit the impact of user choices on the virtual objects.

Connecting flows to use cases

For nearly all my projects of the last several years, I’ve compiled a list of use cases. I’m in the third decade of my UX career, and I’m probably using that term wrong. ¯\_(ツ)_/¯

By use case, I mean a sentence that describes a single intention for at least one type of user. Rendered as imperative statements, they aim to be agnostic of the system. For example, “log in” would never be a use case, but invite people to event would be.

Sample use case list for Events application. Use cases written with imperative mood and generally in the first person, as if the user were the narrator.

It’s a simple tool to represent user needs. The use case list is a crucial input to the flow chart: it defines the scope of the application.

The whole set acts as a checklist to ensure the flow addresses all the user needs. Every use case gets an identifier and I can annotate the flow with the use case ID numbers to show where it meets each user need.

A simple flow chart with small flags on each box showing identifies for use cases.

It gives me and the team a visual way to see whether we’ve missed anything. Through each iteration, I can interrogate the flow with the use cases asking questions like, “OK, how would users invite people to the event?”

Including menus

In many applications, users navigate to an area of the app to perform a function. To show that a screen is a hub from which users may spoke out to different functions, I use this convention:

A flow chart with menu items embedded.

Note that I minimize connecting lines, pointing to a dotted rectangle that encompasses all the options in the menu.

By embodying the menu item in the flow, I can show additional processes that trigger from clicking on it. So I close the event and in addition to taking me to the “launched event” screen, the system sends a notification to key stakeholders.

When you expose menu items in the flow, you can show what else the menu triggers.

Showing object life cycles

Now we’re going to get into some deep information architecture. Ready?

The flows we create are designed to make changes to digital objects. Digital objects are virtual representations of things from the real world. A digital object is discrete and has characteristics that users can manipulate.

An event in the real world is represented by “event” in the app you’re designing. People can RSVP for the event. Admins can edit the event. The event is an instance of a certain template (content type) which has properties (characteristics) and methods (actions we can perform on the object).

A series of states for an event.

Objects may have a life cycle, implied and enforced by the application. Like a document that goes through drafts and approvals and then becomes final. We call each step in the life cycle a state. There’s a clear connection between the actions users take and the state of the object.

Moreover, the state of a digital object can affect the user’s experience. That is, the current state of the object affects how the object appears in the UI and what users can do with it.

Actions users can take on an event at each stage of its life cycle.

Let’s say multiple people can sign up to an event. The status of the event might change based on how many people sign up, or if certain people sign up. By diagramming the lifecycle of the event next to the flow we can show the interaction between the user’s actions and changes to the digital object.

To reflect the interaction between the user experience and the object’s life cycle, I’ve used two techniques:

Give the life cycle a swim lane

Essentially, the diagram includes a timeline of the object, from its inception or instantiation until its destruction. The timeline sort of floats behind the screens and paths of the flow chart. When users take an action that affects the state of the object, the flow chart points to the timeline, indicating the nature of the change.

A flow chart showing how screens interact with the object’s life cycle, marked by orange flags.

Embed state changes on flow

When there’s a single object that may make multiple changes depending on the actions, a simple timeline may be insufficient. (Or it may be too difficult to wrap your head around.) I’ll annotate screens with a flag indicating a state change. This doesn’t reveal the dependencies between object state and user experience as well as giving the life cycle a swim lane.

Orange flags appearing on the screens themselves to show how the data object’s state changes based on user interactions.

Conversations Matter

Any deliverable I create these days is a catalyst for conversation, and flow charts are among the most useful, yielding insights about both the overall process and tiny details. My client stakeholders participate in processes for so long, they’ve never had to externalize it, much less translate it to a set of screens.

Flow charts let us keep track of the multivariate issues in modern business processes, visualize the dependencies, and begin to imagine the user experience. Even the most basic flow chart will encourage your team to talk about both the complete landscape as well as the details of each step. And yet, with our work being more collaborative and dealing with more complex domains, our work products must continually be challenged and updated to remain useful.

Thanks for reading! I wrote a whole book on the design discovery process. You should check it out!

You can download a sample chapter from A Book Apart. The book puts techniques like stakeholder interviews into context, explaining how an entire discovery phase comes together. If you pick up a copy, all my dreams will come true!

Need help doing discovery for your digital product? EightShapes can advise or drive projects to get you to a product definition and vision. Find out more at eightshapes.com. Please get in touch!