How do you document your interaction flows?

  • 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?

    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?

    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.

    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.

    This should be a comment rather than answer

  • 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:

    GIVEN, WHEN, THEN

    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.

    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.

  • 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) ?

    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.

  • 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.

    https://youtu.be/ykqIcO7btRg

    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!

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM