Why Some of the Best Designs Were Never Designed: Emergent Use Cases — Part 1
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”. These “emergent use cases” are the subject of this article.
Emergent use cases: unplanned, user-discovered ways of using an object.
Understanding emergent use cases, like commenting out code for the purpose of debugging, is invaluable since 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 its parts don’t have (due to interaction amongst the parts). It’s one of those philosophical, systems-level topics that cognitive scientists love to chat about. 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.
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.
It’s important to remember that emergence, by definition, is unplanned. In my post introducing the writing graph, I juxtaposed an existing visualization type (timeline graph) with a new domain (text), but I didn’t “repurpose” anything. I wouldn’t call the writing graph emergent since visualization types are designed to be applied in domain-agnostics ways, not unlike how bags are designed to store different things.
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:
- 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)
- Cutting (i.e., slicing, chopping, mincing, etc.)
- Crushing (i.e., garlic)
- 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
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? One of my favorite examples is hashtags in Twitter: In 2007, designer Chris Messina suggested repurposing the # character to group related messages.
I like to keep a journal of the emergent use cases I see in tech. Based on my experience writing experimental apps and working alongside software engineers, here are a few examples around 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.
- Software/hardware example: Using headphones to silence your device. Have you ever needed to suddenly silence your computer or phone only to find it’s frozen or unresponsive (for example, when first opening it up in a meeting)? You can stuff a headphone jack in it (if your device still has one) to bypass laggy software.
- Temporarily commenting out one method in favor of another
While I imagine the original designers are aware of these use cases, I doubt they had them in mind before their first releases. When thinking about your own work, no one can help you design for specific emergent use cases (otherwise they wouldn’t be emergent), but you can design for emergent use cases in general by designing with modular components — this effectively raises the probability of emergence by increasing the number of possible part-part interactions. Let your designs breathe; let users discover untapped potential before rushing toward feature parity. In a similar vein, it helps to ensure your designs are good citizens that play well with others via 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.
In the upcoming parts of this series, we’ll discuss another type of emergent use case: Non-goal-based use cases, as well as more examples from crafts like software engineering, woodworking and sewing.
Originally published at cognitionandcraft.com on December 23, 2018.