Task flows for UX designers
Several thoughts, feelings and tips for creating task flows before you even think about touching a wireframe.
There is a not so small annoyance I’ve observed lately. A proliferation of disjointed and painful user experiences full of infinite loops, jarring transitions, incomprehensible workarounds, and whole pages that are thrown together by devs who — while great at building things — are not designers.
Many business/project/team leaders have heard that they can save time by doing agile (they could, but not how they’re doing it). They are under the misapprehension that no requirements need to be documented because that’s a waterfall thing(it’s not). Wireframes are a tangible deliverable that looks suspiciously close to something the devs could start building from(they shouldn’t). So we have a wonderful shitstorm which culminates in no documentation, a compressed timeline and a bunch of dingdongs that did a four-hour design thinking workshop last year and walked away knowing exactly one word: wireframe.
I know far too many designers who feel helpless against the requests to just push pixels into pretty screens. Too often that’s all the poor designer has time to do(see above compressed timelines) and they feel helpless to describe just how badly the project managers fucked up their estimation. Because it’s really hard to explain why you can’t design that enterprise platform with 5 user permissions and 250 thousand business rules in three months without, you know, designing that enterprise platform REALLY BADLY.
One solution
One potential cure for this malady is task flows. Unfortunately, it doesn’t seem that many GA/XI/insert-short-course curriculums include task flows in their chic minimalist classrooms. As such, I thought it only fair to share a few tips.
So goes, my tips for using task flows in Human-centred Design (before you get anywhere near your wireframes).
User first
Always describe who the user is and what task they are trying to achieve. Don’t get distracted by what the system or business is trying to achieve; remember, no person ever has wanted to log in — what they want is to view their account.
One task
Describe one task at a time. You can stitch your tasks together with a high-level flow if that’s helpful.
Good and bad
Show both happy and unhappy paths, errors, potential infinite loops and any unavoidable bottlenecks. Call attention to any parts of the journey that haven’t been accounted for in the project plan — show these to the project manager and BA.
You bloody legend
Whether you use the standard business/tech flowchart symbols or not, have a legend which defines each symbol’s meanings in YOUR task flow.
Make it pretty
Use icons or illustrations where they can reinforce your message. Colour coding and using icons make your flow easier to scan. Remember you’re a designer and you know how to communicate visually. Miro is incredibly helpful for this.
Testing is best-ing
Test your task flows like you test your designs. Is the meaning as clear and coherent to other people as it is to you? Print it out and shove it under the nose of the receptionist (if they’re the friendly kind of receptionist — don’t mess with the scary kind).
Everything matters
Describe all agents, touchpoints and systems including consultants, servers, emails and phone calls. Everything that affects the user is a part of the flow. Use swimlanes if that helps to improve clarity and differentiate actors and systems.
Before wireframes
If your product is anything more complicated than a light switch and hasn’t been understood end-to-end, push back on stakeholders asking for wireframes first. You may have agreed to “work through” ambiguity and that’s what you’re doing with a task flow. You’re clarifying or highlighting what’s ambiguous and saving the project from possibly months of rework.
Own your shit(and share the rest)
Some of the undocumented sections in the flow will best be filled/designed by the UXer, some will better be defined by business rules, the BA or even an architect. Book a meeting with your project manager or product owner(or whole team if that’s what’s needed) to figure out who should take on the work and get it into your backlog of work. Remember, just because you discovered that no one has considered the flow for deleting an account doesn’t mean you have to work weekends on your own to figure it out.
