I’ve been adding context and tweaking my approach to task flows. The work exists at an intersection between my need to improve the quality of my documentation, and the need to document asynchronous web apps (RIAs and Ajax).
The improved task flow adds important context about the user and experience (70kb Flashpaper. Also available as a 68kb PDF).
The improved task flow differentiates between active and passive tasks, lists insights generated, and records data the experience will generate. The resulting document speaks to the interaction design, visual design, navigation design, and database design. View as 70kb Flashpaper or 68kb PDF (try the Flashpaper. It’s nice.)
I’m swamped so an off-the-cuff explanation follows.
Tufte’s basic premise has always been that the more context you can offer, the better your informational graphics will become. My first attempt at improving the task flow by adding additional context was very successul, and resulted in something new I’ve been calling an interaction flow because it details the flow of interaction between the user and the experience space (usually a website, for me).
The interaction flow revealed a problem. What had started out as a task flow had turned into a useful flow of the content and behaviour. In some ways it’s almost like a more visual page description diagram, and it even maps user conversion. Very useful, but it’s no longer a task flow. The interaction flow maps the user’s experience, but a task flow maps the tasks performed during an experience.
At least I think that’s the difference.
For a new project, I documented the task flow. The main driving difference between the task flow and the interaction flow is that the task flow is interface agnostic: it should apply to any interface (verbal, web, paper, psychic, etc.). The interaction flow assumed an interface.
In keeping with my quest to add more context to the document, I separated tasks into ‘passive’ and ‘active’. Oddly enough, the passive and active tasks match up to the content and behaviour columns in the interaction task flow. Differentiating between the two is important to me. With most task flows I’ve created in the past, and most that I’ve seen, there’s a lot of implicit assumptions hidden ‘in the margins’, in the white spaces between the boxes, annotations for the arrows.
Divorcing tasks from the page
Task flows often use boxes to note tasks, and their similarity to site maps cause many to assume each task occurs on its own page. We know this isn’t true. The complex interaction between content and behavior illustrated in my interaction flow show how rich a simple web page can be. More importantly, as we design asynchronous applications, pages will have more and more discrete tasks and groups of tasks.
We need to divorce the concept of a task from the concept of the page.
Re-envisioning for Ajax and RIAs
For task flows, the arrows between tasks represent not a move from one task to another, but a change in the user’s focus. For most traditional post/response web applications, the difference is trivial, but for rich internet applications, this means we can still use rich task flows to document things.
I think such a shift in viewpoint is very useful. Every presentation I’ve seen on RIAs and Ajax spends a good portion of time discussing the difficulty of using existing deliverables, and understanding the arrows on task flows as merely shifts in the user’s focus would solve this problem.
The next step, for me, will to go form the task flow and document the interaction between the user and a rich, asynchronous application interface. More than being a fad, asynchronous apps let you solve common nagging problems with abandonment and improve the interface so it’s more natural and intuitive, more human, and I am a staunch beleiver that the more human we cna be, the better the experiences will become.