The UX of Workflows: Doors, Driving and Software
Workflows: what are they, exactly? They’ve got roots in storytelling — there’s a beginning, middle and end — and in some ways they’re a physical embodiment of a story — you experience the story and are part of that story rather than just listening to, reading, or observing it.
A lot of what User Experience (UX) is about is noticing the unseen-but-obvious — the things that are so deeply ingrained in our environment they’re completely invisible to most people. It’s taking the time to observe and see things as they truly are, and then being able to further define those things in order to simplify them and mold them into what should or could be.
I digress. We’ll get back to UX, but for now let’s hone in on a concept that people encounter every day, both at work and everywhere else: workflows.
Required elements
A workflow involves the steps a user must take to complete an action across time. A workflow can be as simple as a single interaction or task, or it could be incredibly complex. A larger workflow might contain many smaller workflows, and those could contain even smaller ones turning the whole thing into a veritable Russian nesting doll. Nielsen Norman Group wrote a great article a few years ago on various perspectives on improving workflow usability overall, but in this post, we’re going to focus less on nuance and more on the essentials. What defines a workflow in the first place?
No matter the scale — whether small micro-interactions or large multi-step, multi-page user flows — effective workflows are defined by three basic elements that appear in the following order:
- Announcement: the workflow has to announce, in some way or another, what the user can expect to accomplish
- Action: the workflow must facilitate the user’s required action, not inhibit it
- Acknowledgement: the workflow needs to acknowledge that the required steps have been taken and the user is ‘done’ or completed
Each step is critical to the success of the workflow and needs to appear in order to be effective. Otherwise, we potentially leave our users feeling unsure and lacking confidence in both themselves and our software.
Breaking it down
Let’s zoom in to the workflow concept by analyzing one of the simplest elements we can have on any web page: a button.
Announcement
So, we have a button on a page. Let’s say that button’s purpose is to confirm whether your mailing address is correct or not, and you need to make that confirmation (via the button) in order to move on and do something else. What does a proper announcement look like? First, we have to consider the concept of affordances. Does it look like a button in the first place? Will people recognize that they can interact with it — that they click on it to engage it? Ok, let’s call it good there. This button looks like a button. Is that it? Nope — because although it might be clear the user can interact with it, we need to make sure the user knows why it’s there in the first place.
In the case of the button, this could be solved rather quickly with clear, explanatory language. TELL the user what they can do with this button. This is also a spot where we see workflows break down all the time. Depending on your editorial style (ours is more conversational) and the context of where the button appears, it should look something like this:
Action
This part seems like a no-brainer, but consider this: when’s the last time you walked up to the double door of a building and it didn’t open? You look up, see the “open” sign in the window, see a handle and pull…and then…nothing. You’re stuck. You feel like an idiot. Or maybe you feel annoyed or indignant. Or all of those things. Then, you notice the other handle and decide to give it one more shot. This one opens, thankfully. This is a real-life, all-too-common example of a completely broken workflow. As the person using the door, you’re getting all the signals that you can walk through that door. And then when you go to act, you can’t. Ack!
So back to our button example: it’s got to work, and not just 50 percent of the time like our door situation above. It’s got to work both on the back-end parts that your users can’t see, and in the front-end artifacts that they can. This is especially important in invisible design where your users have to put a lot of trust into things they can’t necessarily see or affect directly.
At Benefitfocus, we make sure our users can understand they’re interacting with our button by adding some simple changes that show them when they’re hovering and then clicking on the button:
Acknowledgement
Finally, we’re at the last step! Everybody do a little happy dance.
Except here’s the thing. We all have to know we’re at the last step, especially our users. Sometimes this is obvious. When you’re going through a door workflow, you know it’s done because you’ve physically entered a new space and you can see the door closing behind you.
But with our button? Not so fast. Even if we bring the user to a new page, we haven’t necessarily acknowledged the end of the action. If the purpose of our button was to confirm a mailing address, is it clear that the address was confirmed just by jumping to a new page? We need to look at context. Was the button part of a larger workflow, and the user now clearly sees that they’ve advanced to a new step? Is that enough? Perhaps they need additional confirmation, which might look something like this:
However it’s handled, every workflow needs a clear ending that everyone can recognize. At Benefitfocus, we have a Manual of Style with a collection of workflow patterns and editorial best practices that helps us keep our beginnings, middles and endings consistent.
When a good workflow goes bad
If you happen to be in the age group that’s had a driver’s license for more than a decade, you’ll know that for much of that time, you started your car with a key. It was a fairly straightforward workflow that relies on visual affordance, physical feedback and consistency. You had a key and looked for the keyhole to start the ignition. It’s always in the same basic spot and you turn the key in the same direction. You could feel the engine respond to your turning of the key.
In recent years, though, we’ve had changes to the workflow, without the proper announcements. Now, you can potentially start a car in a number of different ways. You might be able to start it with a regular key, you might start it with a push button while sitting in the vehicle (careful, you might have to also apply the brake to make this magic happen), or you might be able to start the car from inside your house using only your key fob. Now, when you buy a new car, one might assume that you’d learn how to start it before driving off. But are we sure that ALWAYS happens? What about rental cars? A good workflow should never rely on outside training to work. And what if someone has to drive another person’s car in an emergency? What if that emergency is time sensitive? Do we really want to spend precious moments trying to figure out how to get the car started?
This isn’t a knock against technological innovation. I don’t think any of us doubts the appeal of being able to start your vehicle from inside your warm home on a snowy day. With innovation comes responsibility, though, and ignoring the basic tenets of workflow structure could leave people literally stranded on the side of the road.
Software and beyond
Workflows are integral to software, but hopefully now we can all agree that they’re rooted in our offline lives, and they exist everywhere. Whether it’s writing an essay, riding in an elevator, or starting a car, workflows matter. Skip a step or get them out of order, and you’ve either confused yourself or those around you.
So, when you’re making a workflow of your own, consider:
- Are you clearly announcing what you’d like people to do?
- Are you letting them do what they need to do? Are you providing the tools to do so?
- Are you acknowledging when the action has completed and can everyone understand/see/feel that acknowledgement?
Where can we improve? To do that, let’s go back to the beginning where we discussed what UX is about: noticing things. User experience professionals at Benefitfocus (and beyond) are trained to notice the nuance, to hone in on how people do things, and to know how we can help them do things faster, more easily, with more clarity, or all of the above. Yes, there are specific skills involved, and that’s why we have professional UXers. But it all starts with awareness, and we can all do that. We can all watch for nuance. We can all pay attention to the little (and big) workflows in our lives and seek to make them better for ourselves and others. How will you?
Originally posted on Benefitfocus’ Design + Engineering blog.
