Task Flows and the Process of Designing Interactions

Never Draw First

Over time, I’ve realized that it is important not to just add on this diagram, but to actually start with it. Plus, you always need to be able to take a step back from your drawings to consider the impact your detailed design decisions have had on the overall system.

As much as possible, I avoid drawing anything early on. There are a few other approaches I use when collaborating closely with others, but my normal method is to start with a bulleted list. Once I have a basic understanding of the product, process, requirements, technology, audience, organizational goals, and so on, I create a bulleted list.

Don’t Create a Site Map

Most clients, most project teams, and a lot of designers try to create site maps. Just for starters, this term makes my skin crawl because it’s an artifact from bad Web 1.0 design. Instead of having a sensible information architecture (IA), navigation, and wayfinding scheme, they just include a link to a telephone book explaining how your site is constructed at the bottom of every page.

During design, I never make site maps—although, at some point, it could be useful to create an IA diagram. A task flow is a little different. It isn’t about what page is where in a theoretical hierarchy, but how people flow through the system trying to perform their specific tasks.

Model the Interaction

A key thing to remember about most systems is that they are interactive. People do not just look at them or occupy them, but use them. Not just Web sites, but roads and houses and books.

Think about how road trips worked in the days before online maps. Your parents might have gotten out a road atlas or one of those complex, folding maps, and highlighted the route they planned to take. Print maps show the existence, size, and relative location of all the elements within their scope.

The highlighted route showed the expected way your family would interact with the system—which turn to take and where to stop to eat, sleep, or take a tour.

Our system of design documentation must likewise be more than just mapped. You can’t just list every page and organize the documentation to describe the relationships between technologies, but must highlight the most likely paths users would take through the system.

Task Flow Tools: The Bulleted List

When creating a task flow, I’ve tried various tricks and tools for organizing data, both physical and digital, and I’ve settled on the bulleted list. Occasionally, I create a numbered list, but usually just an unordered, bulleted list.

While you could accomplish this goal in some other way—for example, by creating a spreadsheet, particularly using a shared spreadsheet such as Google Sheets that allows commenting, labels, descriptions, and indentations whose formatting does not get lost.

However, I would avoid using other types of tools such as flowcharting tools at this point—partly because this documentation needs to be as accessible as possible and also to help you keep your focus. You can put a bulleted list in an email message, Confluence, OneNote, on story cards, or in whatever system you want. Start simple, then expand. Mostly, a bulleted list retains a single path of interactions. The user sees a page, clicks something, then—next bullet—this other view appears, and the user reacts to it.

Accounting for Complexity

This bulleted list represents what everyone I’ve worked with calls the happy path—a fairly straight-line process, with few branches or options, that assumes no problems.

Of course, in reality, all of the interactive systems that our users work within are complex—arbitrarily complex in the mathematical sense, meaning nearly infinitely complex. You have to address all of the possible ways to get into the process, encounter errors, and avoid them.

Typing out your assumptions about the process based on the requirements, or story, is a good way to challenge this happy path. Go back to your design principles and think about which of them you might be violating. For this software-update feature, I’d challenge the assumption that any user actually wants to check the software status. Sure, maybe a few might, if Customer Care tells them to, but shouldn’t the default be to check automatically?

After questioning this, I find that this process cannot be entirely automatic and occur just in the background—because of the way connections work and the chance of bricking the device if it disconnects—but I still add a branch to inform the user.

Boxes and Arrows

Next, it’s finally time to draw, but proceed carefully. Use low-fidelity drawing tools or coarse methods. One reason people use Post-It notes and whiteboards to draw during ideation workshops is that they are purposely very rough. Keep that same principle in mind when drawing boxes and arrows, stick to the structure and ideas, and avoid getting into UI details.

You could break out Lucid Chart, Miro, Visio, or just PowerPoint. I usually draw in Adobe InDesign, OmniGraffle, or whatever vector design tool I’m already using, but that’s because of tool familiarity more than anything else.

The time to move on to the boxes-and-arrows mode is when it becomes too confusing to keep track of a nested, bulleted list. Take each step in the process from the bulleted list and add a page for it to the flowchart. Usually, each bullet point represents one page. If you have broken the bulleted list into sections, as I did earlier, start placing each of the boxes into a labeled section.

As you add each box, the pages should remain in the same order as in the bulleted list. People read flows from left to right and top to bottom—at least in the West, where we have left-to-right languages—so lay out the process in this way. I also make my arrows follow this same approach, with arrows to a page always entering at the upper left and arrows from a page exiting—ideally, adjacent to the function, so the buttons at the bottom—to the lower right whenever possible.

Be sure to paste in the text from the bulleted list below each box. Then, start connecting the boxes and expanding the flowchart, as follows:

• Draw arrows between each step, in the order they occur.
• Elaborate on functional details and the display of elements, turning these details into new bulleted lists.

The bulleted lists for each item can be as detailed as you want. I still often resort to the UML method and divide the list into display versus interactive items in some way. You can be explicit and create two labeled lists or imply this division through formatting:

• Display element
• Input—Allow the user to type some value.
• <Links, with their full labels>
• [Buttons, with descriptions such as SUBMIT]

This diagram would look similar to the example shown in Figure 3.

The next step is to reanalyze everything. What other conditions, exceptions, or error states could exist? How should you deal with them? Start explaining the variations, drawing new boxes, linking them up with arrows, and adding branch points or conditions.

Group variations on a single template, again cribbing from UML, providing a labeled box for the whole group and arrows inside the group showing relationships. A set of tabbed views, for example, should be next to each other, with double-ended arrows between them to indicate the shifting view. I don’t use this approach much these days because it isn’t as easy for most other team members to consume, but a stricter state-chart diagram would organize the items not as a list, but in subdivisions within the box itself, as shown in a snippet of a work-in-progress document in Figure 4.

You can show a series of pages as a process or a series for which you don’t really need to show every step as a stack of pages. Figure 5 shows some of these drawing methods.

In reality, these are not precisely sequential steps. However, as you start pasting in the content—and especially as you begin to expand on your bulleted lists of both display and interactive conditions, you’ll see the gaps in the process. It’s just fine to stop and fill in each of those gaps as you discover them. But some people prefer to add placeholder notes to ensure they don’t lose their way. This could also become messy and need to be revised once it’s complete, to keep the flow going generally left to right and ensure it doesn’t become too cluttered or have too many lines crossing.

This is just fine. You should always be willing to revise or correct a flowchart—or even realize that your design isn’t working and needs major revisions. This is not just a method of artifact creation, but a way of helping you to define your design. Not everything that works in your brain makes sense when you write it down.

The process of expanding your design may have no fixed end. But just as you moved from bulleted lists to boxes and arrows, at a certain point, it’s time to move on to the next step.

Cartoons or Icons

The next step in your design process is not a leap of faith to a pixel-perfect user interface, but another subtle segue from one mode of design to another. Take the flowchart you’ve created and start adding little pictures within each box.

These are not the full user interface, but are more iconic—or as I like to say, they’re cartoon representations of the user interface. You can now show whether a user-interface element is a page or pop-up message box or overlay, a list or a form, and indicate tabs, graphics, and more. But represent these only roughly, providing visual indicators, but not actual detailed designs. Figure 6 shows the same detail area as before, expanded to display the UI detail.

Each of these representations of UI elements should already exist and correspond to those in a legend. Reuse them as much as possible, creating new ones only when no existing element suffices. This approach, of course, means you are set up for modular, reusable design, making it easier to build, fix, and update user interfaces and enforcing consistency within your mobile app or Web site.

The Structure Is Most Important

Remember, the work of creating a task-flow diagram—and most of the artifacts that UX designers create—is not about creating an artifact for its own sake, but is part of the actual design process. Do this activity to determine whether what is in your head actually works, and use it to progress to other bits of the work, step by step, all the way to a coded product.

The next step is certainly to get buy-in from your team. One of the best things about this form of output is that most people can read flowcharts and everyone can read bulleted lists. Whether you present this artifact or just give the product team a link to review it on their own, this is a good point for everyone to approve or give detailed feedback on your design. Then, as necessary, either change your design or revise the feature or user story to comply with your new understanding.

This collaboration step should also determine what tool you use. Just recently, I did a lot of flowcharts for a client who had a Lucid Chart account that they’d linked to their Confluence shared-resource library. I didn’t love working in that system, but everyone could see the design, comment, and edit it.

The next artifact you could create at this point varies a lot. Often, I create detailed design templates and components, but you might need to hand off your work for another designer to fill in the details. This process could optionally branch to doing analysis, software design, or creating proof-of-concept code in parallel to detailed design.

Creating proper design artifacts and sharing them with your team throughout the design process helps push the process forward. Early-engagement artifacts such as the task-flow diagram give User Experience the highest value and impact on a product, so they are always worth creating.