An interesting thing about the interface experiences we all spend so much of our time with is that they are designed for the same type of use case:

Consumption.

Netflix, for example, would love nothing more than for you to spend as little time as possible actually doing anything. Their algorithmic recommendations reduce the time you spend searching for content you’ll want to watch, and each successive episode plays automatically after the last one is over without any input from you, the user, at all.

Beyond just media platforms, content consumption drives retail consumption as well:

The undisputed heavyweight of optimization positions both browsing use cases with an essentially identical interface:

The sheer ubiquity of these interfaces, designed not just to be consumed but to, in turn, consume our time, can make it difficult to realize that taking design cues from consumption-driven products — and their practitioners’ many design philosophies — may not be right for every product.

At athenahealth we make the software doctors use to manage patients’ clinical data and run their businesses. Our entire product is oriented around work-critical application flows, not passive consumption.

Workflow: A sequence of tasks to produce a desired outcome.

This is where workflow planning matters most. Unlike a typical consumption-driven experience, maximizing users’ time spent is not a success indicator for us. In fact, it gets us further away from our actual goal — helping doctors interact with their patients instead of their screens.

If, like us, you’re building a product that is about helping people get complex work done, then You Won’t Believe These Six Crazy — just kidding, you know why you’re here. You want to know how you can design more effectively to help your users achieve their goals. So let’s get into it.

Understanding workflows.

“As a user, I want to do A, B, & C, so that I can complete the work I need to do.”

What would be the best design solution for this user story?

Is it like this…

Or maybe it’s like this…

Either approach would support the stated user need, but through two very divergent processes and, inevitably, interfaces. User stories tell you what to design. Workflow planning tells you how best to design it. And there are consequences for diving into designing for user stories before a solid workflow foundation is in place.

Without A Workflow Planning Methodology:

1. Design begins before downstream implications are understood
2. The resulting experience becomes a bunch of siloed pages or steps strung together vs. an integrated flow
3. Users end up faced with feature overload because the totality of the process has not been taken into account
4. And, worst case scenario, you end up reworking design (or even code) late in the game

How we do workflow planning.

Here’s our simple formula for how to break down workflows.

A workflow is the goal a user wants to accomplish — the thing that the product, or a particular part of it, is designed to help them get done— multiplied by scenarios — a set of circumstances that can affect how users accomplish said goal.

For example: if, as a patient, your goal is to prepare for an upcoming doctor’s appointment (filling out health history information, signing consent forms, paying the copay, etc.), the way you accomplish that goal would be affected by whether this is a brand new doctor you are going to see for the first time or if you’re coming in for a standing, weekly appointment. From the patient’s point of view, the goal is the same — you need to confirm the appointment and do any advance prep necessary — but the scenarios are completely different, and dictate distinct workflow solutions.

To solve for this, we’ve developed the 6-step process for workflow planning, below.

Step 1. Define your users’ goal / job to be done. (The reason they opened up your app or came to your site).

Step 2. Identify any scenarios that will impact this goal. What circumstances can be true about the world, the user, or the business objectives in different situations?

Step 3. Document the different workflows that result from these combinations.

Step 4. Are there other goals that a user wants to accomplish when they use your product, or a particular part of your product? Add them.

— Keep in mind, goals are not granular user stories; this is not the place to document an exhaustive list of tasks. A goal is the big picture thing a user wants to have accomplished — order a car, book a flight, file taxes — at the end of the workflow.

Step 5. Repeat the workflow documentation process. Add any additional scenarios you might encounter as you go along.

If you find you’re adding a lot of new scenarios for a specific goal, you might actually be better served by rethinking it as a different product / section altogether.

Step 6. Prioritize your workflows — because you can’t build everything at once.

Keep in mind, not every cell in the matrix will require its own separate workflow. One workflow may be able to support multiple goals and scenarios with some affordances for discreet needs. The point is to make sure you have your bases covered before diving into design.

Here’s a sample of a workflow planning process we did for the pre-appointment patient experience described above:

There are various ways to approach prioritization. It can be based on your product timeline or development cadence. Or you can focus first on the workflows that will solve the biggest pain points or address the most common scenarios. Up to you, so long as it gives you a roadmap for how to proceed. In the example above, our prioritization was based on building for the scenarios that require the most comprehensive information need first to then be able to easily modify for a range of variations.

Once you’ve got your workflows documented and prioritized you can move into diagramming the workflow steps.

Want to try it out for yourself?

Download our workflow planning matrix (.xlsx) to help get you started.

Let us know how it works for you!