On unintentional usability: or, make the tool resemble its purpose

People use tools for the task that they look like they ought to do. Or, more succinctly: The affordances of a tool determine its use [1]. Or, to quote Gibson, “the street finds its own uses for things.[2]

One of the challenges of a software or system designer, then, is to make sure a tool communicates its intended purpose. Another challenge, however, is to build tools durably enough that they can be put to new purposes.

A brief example

Bob, a plumber, needs to enlarge a hole in drywall. He has on his belt a measuring tape, a level, a plumb bob, a big pipe wrench, a small wrench, and a few screwdrivers. What does he use to enlarge the hole?

One common solution is to use the big wrench to hammer on the end of the small wrench (or on a screwdriver). This surely isn’t what wrenches were built to do–but to the plumber, it feels like they ought to be able to do it, and that’s enough. As a result, plumbers learn how to hammer with wrenches such that they don’t break — hammering on the very solid main handle, instead of the fragile jaws.

Home Renovation Cupcakes
Don’t try hammering on this wrench…

Could the plumber carry around a hammer just for this purpose? Sure. But it’s an extra tool, for an unusual case. And wrenches look a lot like hammers, to both the eye and to the hand. They afford hammering, as well as wrenching.

So, big, heavy plumber’s wrenches are built to withstand a little judicious hammering, if that’s what’s needed. And decent screwdrivers will also stand up to hammering, despite what your shop teacher might have told you.

Make it easy to do the right thing

As designers, it is our job to make sure that one of a few things are true:

1. The tool looks like it ought to do what it is supposed to do.
1b. The tool looks like it won’t to do what you don’t want people to do with it.
2. The tool will withstand being put to an alternate purpose, if that’s what the user wants.

We’ve seen this pattern repeated recently. A good example is the rise of Ajax and its precursors, in the generation of web browsers around, let’s say, 2000-2003. Active content started to dominate the web, and browsers just weren’t up to the task. IE’s JavaScript implementation was laughably incompatible, many sites were slow and broken, and website design was an enormous and high-effort headache. But it became the norm, because:

1. it looked like browsers ought to be able to display active, within-page content
2. someone figured out how to hammer on the fragile wrench of JavaScript at just the right angle
3. the result was incredibly useful

Engineers built a solution. First, individually, as a series of hacks. Then these were eventually gathered up and dubbed “Ajax”, and became a standard way of doing things. Finally, the technology evolved into a set of libraries (jQuery, NodeJS, etc.), to ease the burden of development. They built a new tool, or framework, within the constraints of the old — a new wrench that would withstand the hammering. And after a number of years, things were codified into a real hammer, HTML5, which integrates more fluent mechanisms for dynamic updating.

But none of this would have happened if the web browsers had fallen over dead when trying to display active content. The largely durable and flexible design of the browsers allowed innovation.

And that’s part of our job–to make things durable enough to allow a little exploration.

[1] See, e.g., The Psychology of Everyday Things, Don Norman (1988) for a full discussion of the important of affordances.
[2] From “Burning Chrome”, William Gibson (1982).


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s