Typical task flows illustrate the user’s behaviour as they flow through a process, but they do a lousy job showing the behaviour’s context.
Working mostly with websites, my diagrams deal with what a user (1) does on a page (2) after being confronted with some kind of content (3). Good documentation should address the interaction between all three.
If we’re diagramming a search page, the task flow might have a box that says user enters search query. We know the user saw the search box, but we rarely mention this fact on the task flow.
The input user’s receive prior to interacting with a system provides valuable context. I’ve been trying to add this context to my deliverables.
To add more contect to the typical task flow, I’ve added a column that indicates the content the user reacts to. The left, content column describes content using nouns. The right, behaviour column describes interaction using verbs.
A continuum beneath the flow illustrates how engaged the user would be at a given point (relative to other points). This is useful if the flow branches into parallel paths.
Lastly, on some of the flows, a third column to the far right maps the user’s shift from one user group to another.
The improved interaction flow reveals a few tacit mantras:
Content and behaviour are intrinsically linked: two sides of the same coin.
Experience is the transfer of mental models, so design is about moving a user from one group to another.
The more engaged a user is, the more you able you are to change their mental model.
The improved interaction flow seems really useful, but it’s still young, and could still take some improvements. And this strategy should be incorporated into other deliverables, as well. The more context you can provide, the more effectively you will communicate.