Flows are just as important to good interfaces as individual screens are. Customers don’t land on screens from out of nowhere. Specific sequences of actions lead customers through your app as they try to accomplish their tasks.

But as important as they are, flows are hard to communicate during the design process. Drawing out every state of a flow is too time-consuming. And drawings become instantly outdated as screens change. On the other extreme, flows written down into stories or paragraphs are hard to reference and they don’t easily decompose into checklists for design and review.

Working on 37signals Accounts has recently raised this issue of communicating flows for me. We have whole sets of flows that need to be properly designed, implemented, tested and retested. So I’ve scratched the itch with a simple shorthand.

Flows are made out of individual interactions. A screen offers some possibilities and the user chooses one. Then something happens, and the screen changes. It’s an ongoing conversation. Each moment in a flow is like a coin with two sides. The screen is showing something on one side, and the user is reacting on the other side. My flow diagrams illustrate this two-sided nature with a bar. Above the bar is what the user sees. Below the bar is what they do. An arrow connects the user’s action to a new screen with yet another action.

Here’s a simple and concrete example. To add a to-do item in Basecamp, first you go to a list. Then you click to “Add an item.” The form appears. You fill in the item content and submit the form, and if your submission is valid, the item appears and flashes yellow. Here’s a shorthand version of this flow:

The format is really fast to sketch, and it communicates the essentials of what needs to happen as I’m imagining it. For such simple examples, you don’t really need a shorthand. But for more complicated flows, especially of entirely undesigned sections of an app, the shorthand can illustrate a lot of behavior. Here’s a more complicated example for a log-in flow:

This log-in flow includes a few more notations. The dotted line separates alternate actions. There’s only one login screen, but there are multiple possible actions on that screen. The dotted appears above each additional action. Think of it as “or”. When there are multiple actions, the arrows point from an action to a new screen. Screens where the possible actions are uninteresting or out of scope simply have no bar below them. Like “Dashboard” in the diagram above.

You’ll also notice there are two arrows pointing out from “Submit email matching a user account” under the “Forgot password screen.” That’s because two different screens result from that action! You can think of the multiple arrows from an action as “and.” The updated login screen with “your email was sent” message is a result of that action, and the “forgot password email” is another result. Emails are screens because they participate in interface flows.

Here’s another complex flow. This one’s for sending and claiming invitations to create a user account:

Now don’t forget: all diagrams are destined for the garbage. The meaningful work is work that directly affects our customers in the form of screens they can see or code that functions. But we still need to communicate and manage our work along the way. This shorthand has met a bare minimum for me to get a flow out of my brain in order to move on to other things. I hope it’s useful for you too.