Understanding workflow interviews, one of the best 5-minute reality checks from users
A quick method for getting user guidance about how they actually work
You might find workflow interviews to be your best friend when designing more complex interfaces.
Workflow interviews aren’t a prominent user research method because they’re usually not done as stand-alone research. They’re usually a part of user interviews, but they don’t necessarily have to be.
I’ve often found that they are great as a Tag-along meeting to any interaction I have with users. In addition, they’re the reality check that your project desperately needs.
Understanding the workflow interview
At one of my first workflow interviews, a participant laughed at what we presented. It wasn’t to be mean: we got the general gist of their workflow but used wholly inappropriate terms.
“Nobody uses the word burn.” The participant said after he stopped chuckling. “You cauterize tissue. If you burn it, you’d be going to the ER.”
This sort of reality check was incredibly useful in building a Hierarchical Task Analysis (HTA) that broke down the complicated steps of laparoscopic surgery and happened informally after another meeting.
A few weeks ago, I talked about Tag-along meetings, where you take the last 5–10 minutes of another meeting (or chat in the hallway) to talk with participants individually about user research (or other things). Workflow interviews are often perfect for this because they’re bite-sized versions of research methods, such as:
User Testing
User interviews
Concept Testing
Storyboarding
Hierarchical Task Analyses
etc.
We’re not trying to get statistical significance to get 85% of all usability problems by talking with five users.
We’re trying to get a quick reality check from users or subject matter experts by trying to understand their workflow using whatever design artifacts we might have. It can be especially effective if you have standing meetings with your target audience, and scheduling hour-long user interviews with them are challenging.
It tends to work best in two primary scenarios:
You have a “Business” workflow (i.e., what steps businesses think users should take) that you want to get user input on
You are trying to design something in a field you don’t fully understand, and you want to check if your understanding of the workflow is correct.
Both of these scenarios are times when you want to check how your users work and if it differs from the business or your understanding. These reality checks can also be a precursor to a more formal user interview setting if there are significant gaps between the workflows.
But ensuring you’re on the right track now, rather than waiting till later, helps ensure that your design is focused on what users want and need.
Here’s how to conduct these workflow interviews.
The core parts of conducting a workflow interview
While workflow interviews are flexible, there are still several core concepts you should apply to ensure that these things are done correctly.
Emphasize how you’re on your user’s side (and they won’t get in trouble)
The #1 thing you must do to see how users work is to ensure that you’re not seen as a consultant for their boss.
This is for a straightforward reason: users often work differently from how the business wants them to. For example, there may be a ‘standardized process’ set forth by management, but users may not follow it.
One of the clearest examples that I’ve seen of this was a project where management complained that their employees were filing a claim incorrectly.
After interviewing users about their process, it was easy to understand why: the incorrect category took two steps, while the correct category took 11. Users were filing hundreds of these claims a day, so it wasn’t surprising that they chose the workflow they did.
To see what users are doing, ensure they understand that you are not evaluating their performance or reporting to their bosses. In user interviews/testing, this can quickly be done at the beginning of any session. However, this point might slip your mind in these quick chats, so this is a reminder.
Provide something visual in all cases
Many times, workflow interviews are paired with user testing, so there’s something for users to look at (the new design). In these cases, they can see what you’ve designed and judge how much they prefer it to the old method.
However, if you’re pairing a workflow interview with another research method, it’s best to have something visual for them to critique. It doesn’t have to be anything fancy (and I’ve done this with whiteboards), but the main idea is to get the workflow down on paper so they can think about the process.
Sometimes, I’ve even had the fortune to be shown what their actual work screens look like (so that they remember how they do things). When they see the actual steps visually, they can critique them much more quickly. They also see steps they might have forgotten because they don’t do them that often (or the poor wording you use).
Having something visual in these cases helps people understand the process and provide targeted and detailed feedback.
Think of your relevant questions, and narrow them down to 1–2
Lastly, a set of questions should be part of any workflow interview. Most of these are ones you should be used to, such as:
Tell me about your job responsibilities. What do you do daily?
What happens when X (i.e., the start of a particular task)?
How does X typically start (i.e., do you get a phone call, does someone order you to do something, etc.?)
What happens when you finish X?
(With a visual aid) Does this diagram capture your workflow? Are there any changes you’d like to make?
Is there anything you would like to change about the process?
Are there bottlenecks in the process (waiting for time/approvals/etc.)?
However, you don’t have time to ask all these in tag-along meetings. In this case, you must prioritize which questions matter most and ask them first. You want to give them time to comment on the visuals you presented, but you also have a few questions just in case there is any extra time.
I learned this when testing designs with the public: when there’s a chance a rowdy kid, a dog, or something else might pull a person away at any moment, ensure that even if they only answered one question, you got what you wanted.
You might find, especially when starting with a re-design, that many of your users have specific and detailed design feedback since they’ve dealt with specific frustrations for a long time.
Doing these sorts of reality checks can help move the needle towards a design ideal: intuitive designs.
Understanding a user’s workflow is crucial for intuitive design
One of our core goals, when we design something, is to try and make things intuitive.
This doesn’t apply to design elements on the page but to the interactions and steps users take to complete a task. As a result, it’s crucial to understand how your users currently work—designing something to fit business specifications (or what you think it should be) instead of a user’s workflow will cause them to re-learn the process from scratch.
So if you’re not quite sure how users do work or how it might compare with how the business wants things done, try to squeeze in a workflow interview in whatever way you can. Figuring out how users work will help build the blueprints for better design.
Kai Wong is a Senior UX Designer, Design Writer, and author of the Data and Design newsletter. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.