Meditations on a Paper Jam

I cleared a paper jam in one of the printers at work (a trifling problem that isn't quite frequent, nor quite rare) and then got sucked into a two-hour meeting at which I had nothing to contribute and nothing to gain (ditto) and found myself thinking about the former problem. A few random thoughts bubbled up:

Bad at a Glance Isn't Necessarily Bad

The indicator on the printer indicated that there was a paper jam, and to follow procedures "D" and "Y" to clear it. That much is cryptic ... and opening the front panel to refer to the instructions, this is what I saw:

My reaction at a glance, was that this was an awful design: not only had I been given a couple of cryptic error codes, but I had been referred to this complex diagram that was visually daunting, with a jumble of letters and numbers along with a chaos of arrows showing the solutions to several different problems, only two of which were actually relevant to my situation.

But as I worked through it, it really wasn't that bad. Certainly, the diagram was cluttered and the letters seemed to be in random order (CDPZBRAY), but it really wasn't a problem to find the two procedures I needed and follow the comic-book style sequence for each procedure, clear the jam, and get the unit functional again. It was really quite simple.

This called to mind the value of usability testing: showing your design to a peer to get their input often begins with the same knee-jerk reaction to complexity, which gets aggrandized rather than resolved by a person who is passing judgment at a glance and not really working through the task. The only way you can get good, valid feedback about whether something is usable is to have a person actually use it.

Some People Are Easily Paralyzed

I recalled that, as soon as I had repaired the problem and taken my print-out, someone sitting nearby, facing the copier, rose from his desk and came to get his own print-out that had been queued before mine. My initial reaction was, "What an [expletive]! He knew the printer was jammed and just sat there waiting for someone else to fix it." On further reflection, my opinion has not changed.

But this calls to mind another common problem for design: a user is easily paralyzed and prone to drop off if there is even a minor problem that would take him even a small amount of thought and effort to resolve for himself. It's likely the reason we need to be so persnickety about instructions and error messages - or better still, about holding the developers to doing the extra work that is necessary to make the system smart enough to assist a user in completing a task without ever encountering an error message.

At the same time, this is not a good fit. I've been critical of colleagues who have misused research into bystander apathy (Latane and Darley) to suggest that users will not work through problems at all. Those studies, as well as the copier situation, were the result of group mentality - people do not take action, or take action more reluctantly, in situations where they expect someone else to take action.

The same studies show that people readily take action when they are alone and there is no-one else to provide assistance, so this is likely exaggerated or misapplied when it comes to online and mobile channel, where people do not work as a group. If I recall correctly, around 75% of test subjects took the proper course of action (reported a fire, responded to someone in distress, etc.) when they were alone, as opposed to around 10% when a person was in a group of people.

Knowledge is Slavery

The last meditation, likely more to do with ethics than with design, is that having the knowledge to address a problem and the will to act on it is generally positive - but doing so in a manner that rewards the negligence of others is dysfunctional. And yes, I'm still a bit ticked about the guy who recognized the problem and waited for someone else to fix it.

It occurred to me that the reason a person might do so is that if they demonstrate to others that they can solve a problem, they then become "the guy" whom everyone calls upon to take care of things they could well have done for themselves. Granted, that's whitewash for a no-goodnik in this instance, but it's also quite likely that people whose desks are near a printer are constantly interrupted by others to tend to problems, and maintaining an appearance of stupidity and laziness is a defense mechanism to avoid becoming the official unofficial copier repairman for the office.

The B-side to that argument is being "the only guy" who knows how to do something is job security - but I don't buy that in this instance. Being the only guy who knows how to run cross-tabs in the marketing database to better segment customers is something that is respected, that grants you esteem and makes you head-and-shoulders above colleagues when there's an opportunity for promotion. But being the only guy who knows how to fix the copier, make coffee, and unclog the commode makes you the office bitch when there's anything unpleasant that other people know how to do, and could very well do, but don't want to get their hands dirty.

***

And with that, it's likely I've meditated a bit too long on this situation and my internal pessimist needs to be put back in his cage for the evening. Hope it's been entertaining.