I’ve been recently irritated at something that feels vaguely similar with regards to research loops. Walking through this example…
I note that most of those problems have little to do with the printing technology, and mostly about poor organization around that technology.
Friction sources
Choosing which printer to use isn’t trivial for someone who doesn’t already know it.
Counter-intuitive print dialogue which doesn’t make it clear how to locate a specific printer/add a new one to someone who doesn’t already know.
The printer’s physical location isn’t clear from where you control it.
The printer is not in the same room as where you control it. This means that if you have to iterate on printing due to (potentially minor) errors, each iteration is unnecessarily extended by having to walk back and forth.
No fine-grained feedback on what the printer does from where you control it (that it only printed two of your pages and then ran out, that page 1 printed blank).
Paper is not in the same room as the printer.
Locations of things aren’t trivially clear to someone who doesn’t happen to know them.
The printer’s initial location.
The printer’s new location.
Room 1A1′s location.
The location of the paper for the printer.
The new location of the paper.
Poor organization of printer output (that it just dumps everyone’s print-outs in the same stack; not sure if that was a problem, but sorting that out can add friction too).
Different printer behaviors depending on the software you print from, and what page you print, even though all entity types (documents, pages, function mapping from document-pages to physical pages) should be the same.
What common threads can we see?:
Systems are not optimized to make it easy to interface with by someone who is using them the first time; someone with zero local tacit knowledge.
Arguably (9) fits too: probably the different behaviors were due to some peculiarity of the printing algorithms in different software that someone very familiar with that software would know about.
No affordances for easily recovering from common failure modes/errors/hiccups, or even for quickly learning about them.
Paper in a different room from the printer, printer in a different room from where you control it, no feedback on printer behavior from where you control it.
I see a few directions we can take it.
Direction #1: No affordances for one-time users.
People who set up/modify systems are usually people who work with those systems a lot. They have tons of tacit knowledge about where things are, how to use them, how to avoid and recover from failures, etc. Modeling the mental state of someone who doesn’t have your tacit knowledge is notoriously hard, and even when it isn’t (“a random person wouldn’t know where I moved the paper”), there are no established societal norms/organizational standards regarding making things frictionlessly easy for first-time users.
Even when there are manuals/instructions/etc., they usually assume that you’re going to be thoroughly figuring out how to work with that system, as if you aimed to become a frequent user, rather than doing a specific thing once and never interacting with it again.
The problem is that “a person interacts with a system once and then never again” is a very common occurrence. For some systems (e. g., specific bureaucratic procedures), this is potentially the bulk of user experience; and on the flipside, “interacting with a system for the first time and never again” is a significant fraction of any given person’s life experience.
Direction #2: Systemic accumulation of small friction sources.
All of those individual sources of friction were annoying, but ultimately not that time-consuming (figuring out things’ locations, how to install/locate a printer, replacing paper, re-printing things).
What made the whole experience miserable is that there were tons of those sources of minor friction which came into effect simultaneously.
Thus, it’s easy to see why the person responsible for creating each bit of friction didn’t think of it as a big deal, or why we don’t have societal/organizational standards regarding not creating such minor friction. (Consider that making a big deal of complaining about any given bit of friction in isolation would make you look like a loon/a “Karen”.)
But the problem is that tons of systems you interact with end up with these small bits of friction cropping up, so your ability to move forward is constantly mired down by that stuff.
Direction #3: No affordances for quickly recovering from small failures.
Some sort of default assumptions that things will go as intended, with no minor errors, hiccups, need to fix problems/iterate, etc.
And as long as things-going-wrong doesn’t create a big incident (e. g., someone dying with that as the clear leading cause), nobody is particularly incentivized to think about that and prevent that.
So there are no affordances for easily recovering from them.
But this pattern reoccurs everywhere, so a large fraction of the human experience involves dealing with them.
In what other situations does this show up? An obvious example are various bureaucratic procedures, which require some research to make sense of, and where a small typo/mistake in your documents might lead to having to schedule another appointment next hour/day/month. That is: a procedure you’d plausibly interact with only one/a few times in your life is managed by people who interact with it constantly, and the bits of friction you run into are not obviously catastrophic, so those people are not forced to make things easy for first/imperfect/inexperienced users.
Note that the full thing is not necessarily easy to fix, much like e. g. technical debt isn’t[1]. The work to keep systems easy-to-interface-with is, as usual, a battle against entropy. Overall, I feel this problem is just another manifestation of that one.
Things could certainly be made much better, though, by both:
Establishing high-level organizational standards/policies (e. g., keeping printer paper in the printing room).
Creating low-level societal norms (if you moved paper somewhere, leave a post-it about that).
And indeed, technical debt is another instance, where, for programmers maintaining a codebase, it’s no-one’s first priority to make it easy to understand/modify/interface-with for a one-time user.
Potentially the “inconsistent printer behavior” is downstream of that, by the way. Perhaps there’s no obvious correct/convergent way to interact with low-level printer software, so each app’s designers had to take their own approach, so there are inconsistent behaviors across apps.
I’ve been recently irritated at something that feels vaguely similar with regards to research loops. Walking through this example…
I note that most of those problems have little to do with the printing technology, and mostly about poor organization around that technology.
Friction sources
Choosing which printer to use isn’t trivial for someone who doesn’t already know it.
Counter-intuitive print dialogue which doesn’t make it clear how to locate a specific printer/add a new one to someone who doesn’t already know.
The printer’s physical location isn’t clear from where you control it.
The printer is not in the same room as where you control it. This means that if you have to iterate on printing due to (potentially minor) errors, each iteration is unnecessarily extended by having to walk back and forth.
No fine-grained feedback on what the printer does from where you control it (that it only printed two of your pages and then ran out, that page 1 printed blank).
Paper is not in the same room as the printer.
Locations of things aren’t trivially clear to someone who doesn’t happen to know them.
The printer’s initial location.
The printer’s new location.
Room 1A1′s location.
The location of the paper for the printer.
The new location of the paper.
Poor organization of printer output (that it just dumps everyone’s print-outs in the same stack; not sure if that was a problem, but sorting that out can add friction too).
Different printer behaviors depending on the software you print from, and what page you print, even though all entity types (documents, pages, function mapping from document-pages to physical pages) should be the same.
What common threads can we see?:
Systems are not optimized to make it easy to interface with by someone who is using them the first time; someone with zero local tacit knowledge.
Printer/room/paper locations, printer choice, print dialogue.
Arguably (9) fits too: probably the different behaviors were due to some peculiarity of the printing algorithms in different software that someone very familiar with that software would know about.
No affordances for easily recovering from common failure modes/errors/hiccups, or even for quickly learning about them.
Paper in a different room from the printer, printer in a different room from where you control it, no feedback on printer behavior from where you control it.
I see a few directions we can take it.
Direction #1: No affordances for one-time users.
People who set up/modify systems are usually people who work with those systems a lot. They have tons of tacit knowledge about where things are, how to use them, how to avoid and recover from failures, etc. Modeling the mental state of someone who doesn’t have your tacit knowledge is notoriously hard, and even when it isn’t (“a random person wouldn’t know where I moved the paper”), there are no established societal norms/organizational standards regarding making things frictionlessly easy for first-time users.
Even when there are manuals/instructions/etc., they usually assume that you’re going to be thoroughly figuring out how to work with that system, as if you aimed to become a frequent user, rather than doing a specific thing once and never interacting with it again.
The problem is that “a person interacts with a system once and then never again” is a very common occurrence. For some systems (e. g., specific bureaucratic procedures), this is potentially the bulk of user experience; and on the flipside, “interacting with a system for the first time and never again” is a significant fraction of any given person’s life experience.
Direction #2: Systemic accumulation of small friction sources.
All of those individual sources of friction were annoying, but ultimately not that time-consuming (figuring out things’ locations, how to install/locate a printer, replacing paper, re-printing things).
What made the whole experience miserable is that there were tons of those sources of minor friction which came into effect simultaneously.
Thus, it’s easy to see why the person responsible for creating each bit of friction didn’t think of it as a big deal, or why we don’t have societal/organizational standards regarding not creating such minor friction. (Consider that making a big deal of complaining about any given bit of friction in isolation would make you look like a loon/a “Karen”.)
But the problem is that tons of systems you interact with end up with these small bits of friction cropping up, so your ability to move forward is constantly mired down by that stuff.
Direction #3: No affordances for quickly recovering from small failures.
Some sort of default assumptions that things will go as intended, with no minor errors, hiccups, need to fix problems/iterate, etc.
And as long as things-going-wrong doesn’t create a big incident (e. g., someone dying with that as the clear leading cause), nobody is particularly incentivized to think about that and prevent that.
So there are no affordances for easily recovering from them.
But this pattern reoccurs everywhere, so a large fraction of the human experience involves dealing with them.
In what other situations does this show up? An obvious example are various bureaucratic procedures, which require some research to make sense of, and where a small typo/mistake in your documents might lead to having to schedule another appointment next hour/day/month. That is: a procedure you’d plausibly interact with only one/a few times in your life is managed by people who interact with it constantly, and the bits of friction you run into are not obviously catastrophic, so those people are not forced to make things easy for first/imperfect/inexperienced users.
Note that the full thing is not necessarily easy to fix, much like e. g. technical debt isn’t[1]. The work to keep systems easy-to-interface-with is, as usual, a battle against entropy. Overall, I feel this problem is just another manifestation of that one.
Things could certainly be made much better, though, by both:
Establishing high-level organizational standards/policies (e. g., keeping printer paper in the printing room).
Creating low-level societal norms (if you moved paper somewhere, leave a post-it about that).
And indeed, technical debt is another instance, where, for programmers maintaining a codebase, it’s no-one’s first priority to make it easy to understand/modify/interface-with for a one-time user.
Potentially the “inconsistent printer behavior” is downstream of that, by the way. Perhaps there’s no obvious correct/convergent way to interact with low-level printer software, so each app’s designers had to take their own approach, so there are inconsistent behaviors across apps.