Countering Automation Bias
Those handy default values you provide your users could be doing more harm than good.
It's hard to remember the days before ubiquitous GPS navigation systems.
As someone who enjoys map reading, I find my reliance on GPS and automated navigation a bit disheartening. I love looking at a map, finding where I'm at, and designing a route to get where I'm going. I never do that anymore, though. Unfortunately, my paper map cannot account for live traffic and road conditions.
Waze outperforms my old-fashioned navigation skills almost every time.
The danger comes in relying so heavily on a piece of technology that we begin to consider it infallible. As it is wont to do, The Office captured this phenomenon to hilarious effect:
[Michael Scott]: [The GPS] said, "Go to the right."
[Dwight Schrutte]: It can't mean that. There's a lake there.
[MS]: I think it knows where it is going.
[DS]: This is the lake!!!
[MS]: The machine knows!!!
[DS]: This is the LAKE!!!!!
[MS]: Stop yelling at me!
[DS]: No, I'm telling you THERE'S NO ROAD HERE!!!!
[Michael Scott drives the car into the lake]
What is Automation Bias?
From Wikipedia:
Automation bias is the propensity for humans to favor suggestions from automated decision-making systems and to ignore contradictory information made without automation, even if it is correct.
Examples in Access: Default Values
The most common source of automation bias in our Access applications is with default values.
Default values are a tremendous time saver, but they come with a dark side. Over time, users may come to trust the system more than their own knowledge.
With this in mind, we need some criteria to help us decide whether to offer default values:
- How often can we correctly predict the value a user will enter?
- What are the consequences of incorrect data entry?
- Is there immediate feedback?
Prediction Reliability
Paradoxically, the situation is worse the more reliable the default values are.
For example, imagine the default value is what the user wants 75% of the time. On average, that means the user needs to choose a different value one out of every four times. With such a high relative frequency of having to choose a different option, the user will pay close attention.
Now imagine the default value is what the user wants 99% of the time. It won't take long for the user to begin assuming the default value is what they want every time. Which means the one out of a hundred times it needs to be a different value the user is unlikely to realize it.
This is closely related to the Software Reliability Paradox:
As software reliability increases, so too does the degree of harm it has the potential to create.
Mike Wolfe
Consequences of Mistakes
Default values are easy to justify when the stakes are low.
A classic example of a low-stakes default value is setting a report filter. Many financial reports are run as of the previous month- or year-end. Assuming there are no side effects when running a report (i.e., you are not changing any data), then the consequences of entering an incorrect date are very low.
Enter the wrong report filter? Simply close and re-open the report with the correct filter. No harm, no foul.
On the other hand, our tax colection software needs to categorize payments based on their payment date:
- 2% Discount Period
- 0% Face Period
- 10% Penalty Period
The discount, face, and penalty amounts are stored in the program's database in the billing table. The user enters a bill number and the system retrieves the associated bill information along with the amount owed based on the selected payment period.
Imagine a taxpayer pays a $1,000 tax bill at the end of the 2% discount period by making a $980 cash payment. Not paying attention, the tax collector enters the payment as though it occurred during the face period. If the tax collector does not catch the mistake, they are on the hook for the missing $20!
Presence of Feedback
Providing immediate feedback to the user reduces the risk of incorrect default values.
Imagine two different user interfaces for our previous example. In the first UI, the payment information gets saved to a table, but immediately disappears from the screen. In the second UI, the payment information gets saved to the same table, but instead of disappearing from the screen, it shows in a subform of recently posted payments.
In the first UI, the "fire and forget" approach makes it less likely the user will catch their mistake. In contrast, the second UI offers the user many of the same benefits of an "undo" feature, especially if there is an easy way to edit the recently created payment record.
Cover image created with Microsoft Designer
