Tools for Mobile UX Design: Task Flows

Context, Environment, and Ecosystem

System design is important. We all like to refer to the “UX Is Not UI” chart and complain about clients who demand that we just pretty up the user interface, choose the colors, and maybe change the buttons. But I see lots of designers, UX teams, and design agencies delivering just that. Where are the product design, the taxonomy, the interaction specs? I don’t see nearly enough of these other artifacts—those that would enable us legitimately to call ourselves UX designers and communicate the value that we can really bring to the process. These are the deliverables that show our focus on the user, the environment, the context, and the holistic experience.

Back to tactics or storyboarding—at least the way most UX professionals do it now—is another way to think about all of this. Draw only users, their actions, and their environment. Leave out screen design entirely so you can focus on the user experience and the user. Figure 3 shows an example of a storyboard I drew for Lowe’s Home Improvement.

I created the storyboards at exactly the time when this should be done: early. My going through these exercises, not just designing the system, freaked out a few of my client contacts. Clients’ having the wrong expectations of what we’ll deliver is our fault as an industry. We sell ourselves with portfolios of pretty pictures and write endlessly about the pros and cons of flat design when we should be talking about the power of a custom URI or how to decide when to build or use intents.

Artifacts such as storyboards work great—and not just because they really make you, the designer, confront who the user is and what they do outside the phone, but because they’re something real for everyone to hang onto. Clients who may not understand an IA diagram can begin to see how the product solves problems for real people.

Doesn’t Prototyping Make This Pointless?

When I conduct workshops on this topic—and even when I discuss the whole principle of design documentation, as in my previous columns on design tools, “Tools for Mobile UX Design” and “Tools for Mobile UX Design: Adobe InDesign”—people regularly ask me questions about one key issue: prototypes.

The idea is that prototypes show instead of tell, so we don’t need documentation—or even meetings. This concept has two problems:

1. It’s simply impossible to prototype out of the blue. You will end up with similar results as you would just sketching a user interface. Things will become inconsistent as you design screens for just one platform, instead of designing data, processes, and flows.
2. I have never in my life been shown a prototype to evaluate. I work with lots of people, and they hire lots and lots of other vendors to do design work. Some of them are big, name-brand design organizations who expound on the new world of Lean, prototype-centric design. Still, I’ve never seen anything but Photoshop drawings, PDFs, Word documents, PowerPoint presentations, and so on.

Okay, once I saw an Axure prototype, but because of various sharing issues, most people, including the developers, viewed a simple PDF export. Which brings up another key point: It’s not a prototype if it doesn’t work in context. If it works only on a desktop computer, it’s missing much of the point of prototyping in a world where 30 to 80% of your Web traffic is on mobile devices.

Value Understanding Over Pointless Speed

Don’t assume that creating these task flows would slow down your launch. However, it will take time. You may already sell UX design, in part, as a way to ensure that development is efficient and speedy. The same principle applies: If you just start drawing comps or draw UI designs page by page, you will waste time. You will duplicate effort, won’t create a very good, coherent overall product design, and you will have to revise it later—if you even still have a job.

At the beginning of a project, take a little time to understand the overall product vision, plan your design strategy, and draw your concepts, so everyone on the team has the same understanding. You can collaborate on developing the task flow, as shown in Figure 4, so the whole team is on the same page.

My experience on a couple hundred launched agile and Lean projects makes it clear to me that these methods strongly encourage setting aside careful consideration of design strategy and empathy. But to adhere to a user-centric ethos, you have to be free to explore options, make decisions, and stick to them if you want to get anywhere.

Even if we make good design decisions, we forget why we’ve made them. People are terrible at remembering project details, interactions, and decisions. Therefore, we must document this information somewhere permanent, so we’ll know why we did what we did.

On projects that go too fast, products are rarely designed at all. Oh, sure, they may have pretty interface designs, but the software architecture suffers. Decisions get made based on whatever technology is available that team members happen to be comfortable with. Overly speedy projects get bogged down in technical debt very, very fast.

Creating design documentation isn’t really that slow even at the moment of execution. You can sketch the design solution for an emergent issue while people stand around a whiteboard, then get on your computer to formalize the design and specifications. When I do this, I can usually finish my documentation in time to print it out and stick it on the wall before the developers have come back with their detailed questions.

Conclusion

For years, really ever since User Experience became a practice area with processes and principles, we’ve been saying that the best time to engage with a project is early. But we simply do not exercise that principle often enough. We’re all too happy to please our bosses and clients in the short term—and let them insist that we can do our work fast, cheap, and well.

Unfortunately, all of this dysfunction is worsening just as more people are using more types of devices and better-connected devices. People who expect not just functionality, not just beauty, but well-integrated, robustly predictable services across all of their devices.

Our work can be responsive, accurate, and reasonably fast without sacrificing quality—from design through implementation. But we cannot achieve this by guessing or shortcutting the design process. We can’t do this by ignoring the user, making assumptions about technology, and mistaking design trends for patterns.

When you start your next project, first ask the right questions, then solve the design problems through design strategy. Try creating storyboards, task flows, and architecture documentation. Try creating these artifacts with your project team—and see how doing this helps make the rest of the project go better and faster.