Thanks to Kurt Andersen for bringing this one to my attention.
Harvard Business Review recently published an article about how much time and energy it takes to get something done because of how many different applications are involved lately.
If you've been a reader for a while, you'll already know that people fill gaps, so you may also be unsurprised by this article.
Here's how HBR conceptualizes the problem[0]:
Most enterprise applications weren’t designed to connect to each other, which means that people operate in “swivel chair” roles, fetching and transforming data from multiple applications and then submitting data into other systems. A sizable part of their jobs is to act as the glue between disparate applications. This is a common pattern of work in almost every organization in the world, regardless of industry or size. Processes and tasks that people execute are designed to span multiple applications and hence the very nature of work today requires such constant toggling.
This is a negative (and rightly so) restatement of the fact that people fill gaps.
In fact, this is one of the things Safety II focuses on[1]:
"Safety-II focuses on how work is done, looking for the different ways people adapt to gaps, challenges, and surprises, and how they synchronize activities to resolve conflicts and achieve shared goals."
How bad is it?
We found that, on average, the cost of a switch is little over two seconds and the average user in the dataset toggled between different apps and websites nearly 1,200 times each day. That means that people in these jobs spent just under four hours a week reorienting themselves after toggling to a new application. Over the course of a year, that adds up to five working weeks, or 9% of their annual time at work
We found that after 65% of switches, users toggled to yet another app less than 11 seconds later. In other words, the time spent on an application is not significantly higher than the tax paid of toggling over to it.
Visual momentum can help
I think this amount of switching time, 11 seconds later, would be more acceptable if it was more seamless, if visual momentum was maintained.
Visual momentum, an idea borrowed from cinematography, is one way to help solve the problem. It is when a change in views affects the viewer and allows them to follow along with what changed.
We can think of visual momentum as lying on a continuum. On one side would be no visual momentum where entire views are replaced, if this happens there are no cues to possible views. Low visual momentum makes it so that each time you glance at a display it is disjointed and separate. You can't follow along so you have reorient yourself each time.
On the other side is high visual momentum, where each glance continues cues so you don't have to reorient yourself each time and can comfortably "move" around the virtual space. When visual momentum is high, then as David Woods explains it: "the observer works within a conceptual space in which individual views are grounded."[2]
Improving visual momentum by helping users (re)orient
The orienting function of UI helps users figure out where they are relative to other possible views that they could move to in the given context. Without some ability to orient (and reorient) any cut or significant change, like an application switch, users will get lost and have to start over in figuring out what is going on.
David Woods suggests several ways, including having some sort of overview that lets you see where you are, like a map, in order to navigate "the large network of possible displays." For more about different ways to improve visual momentum, read the full article.
From David Woods[2]:
This type of conceptual map makes movement in the large network of possible displays the equivalent of moving in the semantics of the domain from the point of view of the practitioner.
As HBR notes, people are acting as "glue". Resilience engineering research tends to refer to this as people adapting and filling gaps.
Because of the Law of Fluency, this gap filling can be hard to see as well, especially without some sort of observational study like this one seems to be.
The Law of Fluency tells us that because people adapt and fill gaps, these gaps that they had to fill will then become hidden. This is because ultimately people have a job to do and they do it, filling gaps and working around obstacles as needed in order to get things done.
But this turns those adaptations and workarounds that we're interested in into just "regular" work to those doing it, just the normal way they get things done, hardly worthy of commentary.
This can make it hard to discover them and hard to understand the risks to the system.
This makes the study of cognitive systems more difficult. It hides the details and difficulty, even from other "insiders" and certainly from "outsiders". Eventually insiders don't see these adaptations as something special or separate, simply just the normal work that happens every day.
This means those that would seek to glean an understanding from this work must "deliberately and carefully uncover and disentangle these conflicts and uncertainties in order to understand how operators cope with such complexity."[3]
So what to do? You can start like these folks did and observe the work to try and see things like this. For more on this type of work see observational study as a tool.
Rarely will the answer be something like new technology or "cleaner UI" without having some sort of insight from the people doing the work that this would help.
Without that grounding, then we're back to the core problem of work as done vs work as imagined. The HBR article even has an example of this:
Approve releases with actual hands-on users (instead of the nominated few power users) at every stage of software development. For example, a Fortune 500 retail pharmacy chain introduced a web-based pharmacy adjudication system to replace an old mainframe system — only to realize that most of their busy pharmacists were so used to the mainframe's interface and response time they didn't care for a much cleaner web interface. Speed and reliability were more important to them.
Takeaways
- When people need to reorient multiple times across a single task (like when switching applications), it takes up extra time and energy.
- People fill gaps and work around obstacles, this means that adaptations can be hard to see.
- But its worth investigating. Without investigating it can be nearly impossible to make an effective intervention.
- Visual momentum can help prevent users from having to reorient every time.
- Though it may be tempting "cleaner UI" is unlikely to help, especially in the absence of other information that indicates this is the solution.
- The amount of time and effort a task takes up is more than just the speed of the applications itself, it also includes the amount of (re)orientation and navigation work required.
References
[0]: How Much Time and Energy Do We Waste Toggling Between Applications?
[1]: Safety II Professionals: How Resilience Engineering Can Transform Safety Practice
[2]: How not to navigate too many displays
[3]: The Messy Details Insights from the Study of Technical Work in Healthcare
Subscribe to Resilience Roundup
Subscribe to the newsletter.