Are Flow Charts Right for Me?
Do the needful thing.
That’s something my yoga teacher says. It means, make a pose work for you. If you can’t bend that far or need something to prop you up, that’s OK. “Do the needful thing” gives me permission to make the practice my own.
That’s how I feel about user experience design. You don’t do something because you have to, you do something because the project needs it. In design, as in yoga, do the needful thing.
So when someone objects to a tool or technique, I have to scratch my head. Is there something fundamentally wrong with the tool or technique? Or would they just use it in a different way? As long as I stick to principles, shouldn’t I pick the tool that lets me do my best work?
For me, sometimes, that’s flow charts.
I don’t do flow charts for every project. Here’s what I listen for when deciding whether a flow chart is a needful thing:
Ambiguous Requirements or Priorities
“We know this feature is important, and we know what it should do, but we don’t know how.”
I could start by drawing a few screens, but when requirements aren’t well understood or defined, we get caught in rabbit holes. We end up debating whether something is relevant or not, but absent the context of the whole application.
Flow charts show us requirements in context
Distracted by Details
“We’re going to need the table columns wider.”
Even if the requirements are clear, you might be working with stakeholders who happily debate the merits of table column widths (true story) instead of validating the content. Flow charts, perhaps more than any other diagram, let me drive conversations at different levels. We can talk about the content of a screen based on what it’s connected to. But because we see those screens in the context of a diagram, I can easily shift to a broader view.
Flow charts explain the contents of screens
Conflicting Perspectives on Process
“That’s not how it works from my end at all.”
When building a tool to support a business process, that process is really just people with vastly different perspectives. It’s like everyone going into the same theater but seeing a different movie because of their experience and background. It’s difficult for someone to look at a screen and understand it from another’s perspective.
Flow charts let us converge on a singular direction informed by multiple perspectives
App as Platform for Interaction
“When the people in finance approve the transaction before I’ve had a chance to review it… what happens?”
It’s one thing if you’re building a dashboard or even a payment flow. These are generally one-way affairs. Some of the products I work on have multiple people engaging with data asynchronously. These have countless dependencies. Their “happy path” is really just “what we’d like to happen, not what actually happens.” The inherent complexities make it difficult to start with a single screen to illustrate what this application is about.
Flow charts offer insight when all cases are edge cases
The Needful Thing, Part 2
But those are project needs. What about your needs? I’m serious. It’s the day and age of self-care, so ask yourself, “Are flow charts right for ME?”
It’s important to me that you to use tools that are most comfortable for you. You may not like flow charts. That’s OK, we don’t have to be friends. They work for me, and do more than justify my salary. Here’s why I need flow charts:
I like seeing the big picture
For some products, you can get the gist of the underlying structure and the overall framework from a single screen. Not so with every project. With some products, screens can’t provide insight into the big picture. Looking at an app screen by screen can’t tell me what happens over there when I make a change here, for example. With some products, I need to understand the downstream impact before I can design what goes on the screen. If I feel like I need a handle on the big picture, I draw a picture to solidify it.
I worry about data objects
For Twitter, it’s the Tweet. For EventBrite, it’s the Event. For your online bank, it’s the Account. A data object is the application’s central concern. It’s the thing that the site is about. It’s a container for information, and it’s tagged with metadata. It’s instantiated and maintained and managed and transformed by the application. It’s how I think about what an app does.
To me, it’s organic: it’s a being that needs care and feeding. Until I have a good handle on the anatomy of that data object, I won’t feel confident defining the ecosystem in which it lives.
I know how my brain works
It’s taken decades, but I think I understand how my brain likes tackling problems. It looks at how things move through a system. It asks questions like, “What happens first, and then after that?” And “How does this process get triggered?” And “How often does this occur?” It likes looking at things in terms of its component parts, and with processes, those are the steps and dependencies between them. Following this path builds my confidence — in understanding the design problem and in making decisions about the solution.
Sometimes I dread going to yoga class. It’s Monday night, and I don’t know about your Mondays but I sometimes feel like I compress a week’s worth of effort into Monday. But I drag my middle-aged ass to yoga class, and sit and stand and pose in a room with other people who probably aren’t all that excited to be there. And we do it. We follow along, all while Linda tells us to “do the needful thing.”
I always feel rewarded after I go. Not because I have to, but because I need to.
Communicating Design is a book all about design documentation. Maybe you’ll read it because you need other ways to communicate your ideas and facilitate conversations. Maybe you’ll rage-read it because you think documentation is a waste of time. Either way, I hope you read it.
Need help with thinking through the flow of your complex application? EightShapes can help with your design discovery projects.
