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.
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?
Balsamiq and Axure have tools for diagraming ajax interactions. However, I simply write functional specification and diagram static states.
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.
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.
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.
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.
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
Figure 3—Arrow representing an asynchronous state change
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.
The article further gives an example of how the visual vocabulary could be extended and used to show a login process for a site.
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
Here are some articles which you might find interesting
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.
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.
Another attempt was using some inspiration from state diagrams.
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.
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!