I recently needed to show how the pages of a log-in process interacted.  I started writing a process flow, then switched to a system flow, but in both cases was fighting the model—I wanted to show both what the user was doing and the system decisions.  I also wanted to make it clear which pages were used when logging in. Then I remembered the User Interface Flow.  It worked like a champ, conveying all the information I wanted to convey really well.

 A User Interface Flow shows the pages of interest for a user interface (UI), the navigation between the pages, and the underling system decisions that impact navigation, using these symbols:

Here’s a partial example for a log in process:

Like most models, this one gives you leeway. I’ve chosen to analyze the pages and interactions of interest to me.  For example, every page might have “contact us” and “privacy policy” page links.  Showing those interactions for every page would obscure the information I’m trying to convey.  Also, I’ve labeled all of the UI triggers. That’s a choice you can make—if the trigger is obvious you don’t have to label the line. I could have left off the “Select Forgot Password” label; some might even argue that all of the triggers are obvious.  But, since my example is fairly simple and adding them didn’t cause undue clutter, I chose to include them to maximize reader understanding.

Notice that the decision shape is used only to describe system decisions. The fact that the user can make different decisions about what to do on the log-in page is shown by different interaction choices coming out of the  page.  When applicable, you can create decision trees or tables to further analyze and explain the system decision.

If you’re trying to model a UI with a process or system flow and feel it just isn’t working, the User Interface Flow just might be the answer for you.