UX Culture

How Well Does Your Product’s Workflow Work?

We’re all familiar with workflow systems that don’t work. Bad workflow systems cost employees, business partners, and customers efficiency and productivity. But with Web 2.0 principles in mind, there are many ways to create or redesign workflow tools to make them work right. Here are some guiding principles based on many years of experience in workflow design:

• 1. Be User-Aware. Don’t just show a random table of records and force the user to find the right “needle in the haystack” record each time; design the system logic so it knows which records are relevant to each user, and serve these up first.

• 2. Be Event-Aware. Important events, such as approvals, reviews, problems, etc, get lost in the shuffle of tabular design. Events should be bubbled up directly to users in an event/news stream, and these events can then help users perform triage and prioritize their time.

• 3. Be Context-Persistent. Too many systems make users re-find their record-context evey time they switch business activities. Smarter systems let users set and keep a client/record context across activities. They can then clear it and shift context whenever they need to.

• 4. Be Decision-Aware. Old workflow systems keep data separate from supporting intranet/extranet content materials such as powerpoints, how-tos, email steams, etc. Smart workflow systems create visibility from the workflow out to these “decisional” resources, which users can then easily access right at the moment users are making key decisions. 

• 5. Be Attention-Aware. Smart workflow systems use Web 2.0 ui design principles such as staying on the page, inline interactions, expand/collapse tables, rather than forcing the users through a sea of tabs, tables, second windows, pop-ups, and page shifting. These approaches respect the user’s attention and focus, and let them work in a more efficient way.

And remember that even incremental changes in your product’s workflow can greatly improve the end-user experience.

If you have invested in conducting a usability test of your product, no doubt you are ready, willing, and eager to interact with your current and prospective users. As your users interact with your product, they are bound to have a number of questions for you. For example:

•  ”How would I save my information here?” 
• “Could I customize this?” 
• “What would happen if I click on this button?” 
•  ”How is this supposed to work?” 

There is an essential piece of advice I can offer about how best to initially answer these and many other questions: don’t. Or rather, artfully redirect the question so that you have an opportunity to understand the user’s perceptions and goals before you lose that opportunity by providing too much information. Here’s an example of some artful redirects. You can start with “that’s a good question,” and from there: 

•  ”How might you try to answer that question if you were exploring this product on your own?”
•  ”What would be your expectation of how that would work, based on what you see here?” 
•  ”Let me ask you to explore the product further to see if the experience answers your question.” 

 Why The Redirect Is An Essential Tool 

The user’s initial question provides a pinpoint clue into an area of your product’s user experience that, for a range of possible reasons, is not crystal clear. The reasons could include poor labeling, issues with the UI design hierarchy, problems in the information architecture and flow, mismatch between the tool and the user’s existing way of working, missing contextual information, and more.

By close observation and interaction with the users, you’re hoping to find out where the disconnect is, so you can close the gap between the product’s design and their user’s reality. You’re hoping to amplify the gap and get more information about it so that it comes into view. If you answer the user’s question rather than redirecting it, the user will become “artificially” knowledgeable about the system, and it will be harder, if not impossible, to gain further insight into this gap. If you allow the user to move forward on their own, and succeed or fail to answer their own question, you can then double back with a follow-up probe: what might have made that clearer for you?

Resisting The Urge To Explain 

What usually happens in tests like these is that you may see the very same issue occur with other users. As your test proceeds, you can progressively optimize your line of questioning, and see whether the nature of the confusion is the same across multiple sessions.

If you’ve been working on your product for some time, which would mean months or even years, it’s a natural impulse to want to explain all the ins and outs to users in your testing conversation, especially if you find yourself frustrated by their confusion. Yet it’s key to the success of your test, and of getting good information, to let the product succeed, or fail, to speak for itself on its own. 

When you inform your test subjects of your intent, they become less like outside participants and more like internal members of your own team. The reason you brought them to the test in the first place is because they could help you understand how the product would be received in the open market, without the benefit of your in-person explanation. So have the confidence in your usability process to let problems surface. That way, you and your team will be equipped with great information to solve them.