For many years I've been using an evolved version of Jesse James Garrett's Visvocab diagramming style for documenting information architecture and interaction design concepts.

interaction flow for a a moderately complex feature

Today though we're doing a lot more in-page transformations in lieu of navigating to individual pages: things like accordion views, light-boxes, overlays, AJAX inclusions on demand, etc. JJG's Visvocab is coming up to being 10 years old, and thus wasn't designed to cater to all the new interaction modes we have today.

What diagramming style or notation do you use to map out your interaction flows?

  • 1
    woo interesting! would you think that a flow diagram is an appropraite tool to show things like accordion views, light-boxes, overlays, AJAX inclusions on demand, etc. would an interactive prototype be more helpful? Nov 30, 2011 at 8:15
  • For me, the interaction flow comes before the prototype. If you look closely at the diagram you can see that instead of a single box representing a whole page, I sometimes have a stack of boxes - each is a chunk/object. This approach lets me play around with whether I'll have terms & conditions on the same page, or separated into it's own page (for example). It is so much easier to work out the full process flow at this abstract level, before we get into wireframes and prototypes.
    – Erics
    Nov 30, 2011 at 9:50
  • To your question though: it isn't about the particular elements or widgets, it's about the flow. For example: an order system might have a 3 step wizard including a confirmation step, terminating on an Order Confirmed view ... which could implemented as a separate page, or be done as a lightbox overlaying the previous screen.
    – Erics
    Nov 30, 2011 at 9:54
  • 1
    This should be a comment rather than answer
    – DA01
    Dec 1, 2011 at 3:39

9 Answers 9


For starters I recommend looking at this excellent article from UX Matters which talks about how to extend Jesse James Garret’s visual vocabulary to reflect rich interactive applications which recommends highlighting the interactions as synchronous (requiring a page load)and asynchronous (happening within the page). To quote the article

For user interactions that do not require a page reload, asynchronous interactions—whether implemented in JavaScript, CSS, Ajax, or another RIA technology—use an arrow with a dotted line like that shown in Figure 3.

Figure 3—Arrow representing an asynchronous state change

enter image description here

Synchronous State Changes For user interactions that require an entire page to reload, synchronous interactions, use a single-line arrow, as shown in Figure 4. This is the standard arrow Jesse James Garrett uses in his visual vocabulary.

enter image description here

The article further gives an example of how the visual vocabulary could be extended and used to show a login process for a site.

enter image description here

That said, I generally find it useful to create interactive prototypes using axure which allow users to walk through the different interactions and I use an interaction flow diagram to highlight key interactions in the page which will be of interest to the development team. Other options which we have exploreed are

  1. Creating a walk through video of the interactions to show clients the different functionalities
  2. Doing a live product demo to show the different use cases and documenting the important work flows
  3. Creating story boards for important user flows to show the different interactions
  4. Treating it like a flow design where I use flow charts to map out the flows.

Here are some articles which you might find interesting

Interactive Wireframes: Documenting RIAs

Stop designing pages and start designing flows

Wireframes and Interaction Design Documents


This is a good question. I've been wandering if there is a better way to document interactions for over a year now and have been trialling a few different things. I've taken inspiration from a lot of different places and below are the different types of methods I've created/trialled in the past with some success. The images below show interaction with an image gallery for a retail tablet app.

Abstract diagrams

Interaction Diagram

The grey panels represent a state (not differentiating between a page reload and asynchronous loading.) Only the elements that are involved in this interaction are illustrated and each interaction is depicted with a symbol to explain what input is used or in this case, gesture.

State Diagrams

Another attempt was using some inspiration from state diagrams.

State diagram

I like this method because it's more methodical so quicker to create, but the downside is it takes more time to digest. I'm yet to try it with more elements, at the moment it only concentrates on the interaction with one element.

From this I've now been wondering if it's possible to draw some inspiration from how acceptance criteria is written within an agile team. Using the same example as the image zoom it would look a little like:


Scenario 1: Opening image gallery

GIVEN that product page is open
WHEN user taps on product image
THEN resize image to viewport
AND show thumbnails and close button

Scenario 2: Swiping between images

GIVEN that the image gallery is open
AND zoomed out
WHEN the user swipes left or right
THEN the next image slide into the viewport
AND the selected thumbnail will update to the image in view

Scenario 3: Zooming in and out of an image

GIVEN that the image gallery is open
AND zoomed out
WHEN the user double taps on an image
OR pinches out
THEN the image zooms in
AND the thumbnails disappear
WHEN the user pinches in
THEN the image zooms out
AND the thumbnails reappear

I find writing like this easier to read and write but you do have to create a lot of scenarios to cover all the interactions and you soon start repeating yourself.

Either way I don't think any of these methods are substitutes for talking with people in your team and accompanying prototypes or videos of certain interactions.


It depends on the project, but I tend to merge the user flow with whatever stage of design I'm at. For example, if I'm getting down the use cases, I put those into a flow. If I'm figuring out the sequence of screens, I use those to depict flow. If I'm in wireframing, I assemble the wireframes into a flow. This approach usually requires me to escort the team through the flow once but after that the documents make a one-stop place to get a sense of what is to be built and how it fits together.


Balsamiq and Axure have tools for diagraming ajax interactions. However, I simply write functional specification and diagram static states.

  • 1
    I wouldn't say Balsamiq Mockups (for desktop at least) has tools specifically for ajax interactions as such. But of course, being a little creative with color, arrows, opacity, multiple pages and linking you can get pretty far.
    – agib
    Dec 1, 2011 at 7:41

After two years I'm sure you have found your system. But I'd still like to mention this link I tripped over a few weeks ago.

The author uses a spacious template, integrating wireframes and work-flows. Every transition is annotated with a link to a video describing the transition between frames in detail.

Large Canvas Flows + with references


I think it depends on the particular project.

These days I tend to sketch flows with the UX team and Dev's and iterate the building process. When we're happy with a solution, we then get it documented as test cases for our Q&A teams.

  • For your sketch flows, have you developed an ad hoc notation to indicate which things are done via a lightbox vs a new page (etc) ?
    – Erics
    Dec 1, 2011 at 6:53
  • If we're going off of wireframes, it's usually drawn as a lightbox. Otherwise, we try to be informal and iterate through development so a lot of it is verbal.
    – DA01
    Dec 1, 2011 at 15:10

I don't think interaction design changes. Just the way it's implemented. Ajax may help you design something that doesn't need a new page, but you still need to understand the context of what the user is doing.

Now, this doesn't make your job easier, but more options on how to implement an interaction need, you have more ways to provide a solution.


Balsamiq for simple wireframes.

For Advanced UI flows, I prefer to use UI flow that is constructed from actual designs/screenshots (see attached). This greatly reduces any miscommunication with developers, as they are very clear on how to code the app.

enter image description here


This technique has helped my company to make a User-Interface-Flow document that is:

Fast to make, Fast to read, Full fidelity.


It helps quickly make an analysis of competitor's UI in which screens can be referenced precisely by the pdf page number.

There's an augmentation to this using powerpoint, which enables inter-linking in the UI flow document but we have not made a video for the quick way to do that yet!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.