Emergence and the many uses of a chefs knife

THE LANGUAGE OF DESIGN implicates a top-down culture. Designers spend years studying people and their behavior so they can optimize the artifacts people use to advance their agendas (if not the agenda of their employer). But an overly prescriptive view of design refuses to make eye contact with the fact that the world is only semi-designable. Because users are always finding new ways of using an object, a “design” is never fully “designed”. With any design, certain aspects will always be under- or undesigned. User interviews are punctuated with idiomatic reminders, like the defensive, “Oh, well that wasn’t part of the design,” or the prouder, “Of course, that feature was by-design”. Use-cases that emerge are the subject of this article.

Emergent use cases: unplanned, user-discovered ways of using an object.

Emergent use cases, like commenting out code for the purpose of debugging, are invaluable — their existence echoes a real-world need, one that was elusive enough to escape the designers’ original purview. They remind designers that they’re not always their users, while reminding users that they’re sometimes designers. Practitioners should encourage and support these (often ingenious) use cases as a source of feedback in their process. Below I introduces a few types of emergent use cases, with physical and digital examples, before providing guidelines for their facilitation.
What is Emergence?

Emergence itself is the idea that an object has properties it’s parts don’t have (due to interaction amongst the parts). It is a systems-level metaphor often adopted by cognitive scientists. Emergent use cases (not to be confused with emergent design), then, are the synergistic product of a system’s parts: users and objects. Like with many emergent phenomena, they’re inevitable; whether due to necessity, accident or play, time will ensure that user-object systems give birth to novel usage patterns.
Desire paths (one type of emergent use case) in a Walmart parking lot (reconstructed from a post by u/unroja)

There are different types of emergent use cases.

In 1968, chemist Spencer Silver failed in making a strong adhesive, and an emergent use case was born: that for “stick-y” (rather than “stick-ing”) notes. This is an example of repurposing.

One type of emergent use case, well-known in urban planning, is the desire path: “a path created as a consequence of erosion caused by human or animal foot-fall traffic.” In Finland, for example, plows wait to move snow until footprints reveal walkways. And some universities have even delayed paving sidewalks to see where grass would first erode. The goal of this series isn’t to provide an exhaustive taxonomy of such uses cases, but rather to highlight some illustrative examples. This post in particular focuses on perhaps the most common type of emergent use case: Repurposing. Here, users repurpose an existing design for a new application, like:
  • Opening a paint can with a screwdriver
  • Perching atop a solemn sculpture (offended parties call it, “loitering”)
  • Injecting botox to treat wrinkles
  • Using baking soda for most things other than baking
  • Using diphenhydramine (i.e., Benadryl) to fall asleep
  • Sleeping (rather than sitting) on a city bench.
The Camden bench, like many city benches, aims to paternalistically “design-out” the emergent use case of sleeping (another example of repurposing). This is an example of acknowledging but not supporting an emergent use case. Not coincidentally, it has come to symbolize anti-homelessness and hostile architecture.

Emergence, by definition, is unplanned. In my post on the writing graph, I juxtaposed an existing visualization type (timeline graph) with a new domain (text), but I didn’t “repurpose” anything. The writing graph is not emergent because such visualization types are designed to be applied in a domain-agnostics manner.

As you might expect, the list of repurposable designs goes on ad infinitum (e.g., using x as a paperweight, where x was not designed to be a paperweight). Even within a single object, emergent use cases abound. Consider the chef’s knife, the symbol of food craft: what began as a flintknapped rock for taking meat off bones has matured, over millennia, into a highly-refined trade-off of efficiency and safety, material and cost, style and versatility. Here are some of the use cases for the versatile chef’s knife:
  • Accessing food: 
    • Disjoining food (e.g., slicing bread, deboning chicken, coring apples, cleaning and scaling fish, peeling potatoes, seeding an avocado, opening coconuts)
    • Releasing flavor (e.g., using the spine to milk corn cobs or bruise lemongrass)
    • Cutting open food containers (e.g., tofu, or in an ill-advised pinch: cans)
    • Popping open drink containers (also ill-advised: sabering champagne, unbottling beer, uncorking wine)
  • Shaping food:
    • Cutting (i.e., slicing, chopping, mincing, etc.)
    • Crushing (i.e., garlic)
  • Moving food:
    • Scraping food (e.g., from center to edge of cutting board)
    • Scooping food (e.g., cutting board to pan)
  • Miscellaneous, kitchen-related tasks:
    • Steeling another knife
    • Opening packages and letters
    • Tightening a screw 
    • Sharpening a pencil (though sharpies are often preferred in the kitchen)
    • Fending off unruly diners

An alternative to designing-out: Global’s attorneys explicitly disincentivizing some emergent use cases.

But blacksmiths didn’t forge our iconic designs with the extent of these use cases in mind (these knives followed a slow evolution). Even recently, Global, for example, had to redesign their line after receiving feedback from countries they exported to that blades were breaking. Unlike Japanese users, some foreigners put the fine knives to rough work, like chopping through bones (the German and French knives they were accustomed to are better-suited given their softer steel and more obtuse bevels).
Emergent Use Cases in Software

As you can see, it’s easy to conjure examples in the physical space. But what about abstract space, like software? A classic example is hashtags in Twitter: In 2007, designer Chris Messina suggested repurposing the # character to group related messages.

Early, user-suggested mock-up for hashtags in Twitter

Here are a more examples in DX (Developer Experience):
  • Using a screenshot tool to measure objects on-screen. If you’re on a Mac, you can press ⌘⇧4 to get a quick and dirty measurement of the height and width of objects.
  • Commenting out code. Why remove code when you can more quickly “comment it out” (and avoid having to move it to disk or clipboard). The phrase “comment it out” has nothing to do with the colloquial comment, and I imagine that IDE shortcuts for commenting are primarily used for debugging purposes.
  • Adding todo-list items inside code. Another way developers repurposed comments is by annotating their code with in-situ tags, like TODO, FIXME, OPTIMIZE and BUG. Software makers like JetBrains have even added default functionality to support this emergent use case.

Temporarily commenting out one function call in favor of another.

Guidelines for Facilitating Emergent Use Cases

Designers cannot design specific emergent use cases (otherwise they wouldn’t be emergent), but they can design for emergence by embracing modularity--favoring independent componentry over monoliths effectively raises the probability of emergence by increasing the number of possible part-part interactions. In a similar vein, it helps to ensure designs are good citizens in terms of extensible architecture and services (whether open and physical or proprietary and digital). In addition to thinking of the user and object as two parts in a system, designers should think about such systems themselves as parts of even larger systems, like a user’s computing environment or a group’s niche ecosystem.