Task Flow Diagramming
Last updated
Last updated
People often tell me I can get pretty fanatic about Task Flows. And that is with good reason. It helps us understand how a user will move through our product with precision. It tells us which screens the flow needs, which actions are present, if we have loose ends and it reduces complexity. It's great fuel for discussion and helps bring clarity in clouded refinements.
But doing Task Flows is hard. It can get cumbersome. Especially when you try to combine it with designed screens. But there is an easier way by omitting screens. You can use a shorthand notation when you want to map out a task flow fast. I'm not sure where I got this from but I've been using it for years with success.
I use the notation often when running a workshop or when I sit next to a developer figuring out user stories. It's easy to use when at a whiteboard or when you collaborate remote with tools like Miro. The biggest benefit for shorthand notation is that it is cheap to make. Drawing every screen takes a lot of time and screens hard to maintain. When we want to change things, we become reluctant to do so because we're already invested in it. But when it took us only seconds to create it, it's easier to toss aside and start all over again.
The notation consists of singular steps. Each written down with only text. Each step contains what the user can see and what he can do. What he can do, is captured in one or more actions. The result of each action is feedback and transitions the user to the next thing he can see. We use arrows to connect the relevant parts with each other.
The shorthand notation is an excellent way to visualize your thoughts fast. This is especially helpful if you're trying to solve complex flows and interactions. It can help you hammer out the user experience before you even begin the pixel ceremonies.
On occasion, I add a trigger to an action. A trigger is something that someone can psychically do. For example: scroll, tap, pinch-to-zoom and spread. It provides a bit more context about the UI when there are multiple triggers inside the same step.
This is an example I made for an internal order processing tool when they wanted to add a revoke and delete function. Together with a developer, we mapped the task flow in a couple of minutes. Afterwards, we could start building it by using the components from a design system.
Add only relevant actions. Don't map out the entire app. In the example, the feed with orders has a lot more links and buttons to push, but they are not relevant. The feed itself, that each item is clickable and the quick actions menu are.
The amount of steps can increase fast. To prevent this, you can afford some things. If you have a form with a 'submit' button, which is only enabled after you've entered input in a text field, use a circulair note of it.
