In 1977, Christopher Alexander, Sara Ishikawa, and Murray Silverstein published an architecture book proposing “a pattern language” for designing everything from towns to individual buildings. Each of the 253 “patterns” is a problem-solution combination. More granular patterns combine into bigger patterns. Each pattern solves a problem, and different problems require different patterns.
In many ways, their book was visionary. For example, decades before cell phones and ride-sharing apps, they proposed a pattern labeled “mini buses” integrated within a higher-level one labeled “public transportation network.” These are shared rides that can be called on-demand from bus stops equipped with a phone to get people all the way to their door.
For a house, some of the patterns they outline are quite self-explanatory:
- Private Terrace on the Street
- Bathing Room
- Bulk Storage
- Couple’s Realm
- Children’s Realm
They also go further, proposing how these elements could be laid out according to a higher-level pattern, which they call an “intimacy gradient,” sequencing rooms from the most public to the most private. A common room in a house would be on the public end whereas a bedroom would be private and deeper into the house. In an office, an entry lobby would be public, and private offices would be further inside the space.
Their goal was to provide ordinary people with the tools to design their own buildings, communities, and public spaces. They were hoping to translate the knowledge of professional architects, designers, and urban planners into something nonprofessionals could use.
While some in the architecture world were receptive to the idea, many were not. Architectural historian Molly Wright Steenson writes about how architects hated this approach. “Patterns are really a lot of rules,” Steenson writes, “and what architect wants to be a rule follower?”
Architects may have hated it, but the idea caught on in software and user experience (UX) design. In 2003, roughly 25 years after A Pattern Language was published, Douglas van Duyne, James Landay, and Jason Hong wrote The Design of Sites: Patterns, Principles, and Processes for Crafting a Customer-Centered Web Experience. The book gave readers a pattern language for developing websites to make UX design more centered on user needs and easier to talk about.
They defined higher-level patterns like “advanced e-commerce sites” with components such as “daily featured products.” There are also granular patterns like “action buttons” and “fast-downloading images” that may appear on many types of websites. Unlike the response from architects to the idea of a pattern language, UX designers embraced the idea and developed it even further.
Today there are a number of publicly available “design systems” for helping build user interfaces. For example, Apple’s Human Interface Guidelines for app developers offers recommendations for various categories of components, like “menus and actions” and “navigation and search,” which then include guidelines for more granular components. “Menus and actions,” for example, contains guidelines for designing the menus, buttons, and toolbars within an app.
These systems help UX designers quickly adopt the most effective solutions to common design challenges. UX designers know they are using solutions that incorporate learning from many prior A/B tests while avoiding reinventing solutions that already exist. These patterns also allow designers to keep the look and feel of an app or website internally consistent and create some consistency across apps, making it easier for users to do what they’re trying to do. For example, the ubiquity of the three-line “hamburger” icon makes it easy for us to find drop-down menus across different apps and sites.
In UX design, these pattern languages have arguably achieved what Alexander, Ishikawa, and Silverstein were aiming for with their book: They have opened web design (and app and software design) to ordinary people. Eventually, these patterns were integrated into simple drag-and-drop tools so that today, with little to no knowledge of UX design and without a computer science or software engineering degree, someone can create a well-designed, functioning website in remarkably little time.
A question has been on my mind since I first learned about the idea of a pattern language (thanks to conversations with the designer Ruth Schmidt and data scientist Jim Guszcza): What if we applied the logic of a pattern language to behavioral design?
What if we applied the logic of a pattern language to behavioral design?
What if we identified similar sets of patterns that affect behavior and appear repeatedly in particular settings? Could we improve the work of behavioral designers, making their designs more effective? Could we put good behavioral design in the hands of ordinary people, empowering them to improve their lives, homes, workplaces, and more?
The first step to finding out is exploring whether it’s possible to define a set of patterns for behavioral designers. The specific kind of patterns that could be worth articulating is what I’ve come to call context patterns. By context patterns, I mean the elements that recur across situations that influence behavior. These might be things like how choices are presented, the number of steps in a process, or the scarcity or abundance of time.
Context patterns are different from internal mental processes, often referred to as psychologies, like loss aversion, confirmation bias, or choice overload. Psychologies, especially as represented in lists of biases, connote a set of possible failure modes; they point out problems. A set of context patterns, by contrast, would be designed to point you directly toward a solution (more on this in a moment).
And if we could identify a set of patterns, like the authors above did for architecture and UX design, we could begin testing whether they make behavioral designers’ work better—specifically, by aggregating the most effective solutions and reducing the number of times behavioral designers inadvertently reinvent the wheel; spending time, energy, and resources on problems for which someone has already found a solution.
For example, we could make a list of context patterns for “physical service locations” like government offices or health clinics. Several patterns, like “waiting time” or “opening hours,” commonly appear in any type of physical service location and influence people’s motivation and ability to use the services at these locations. From there, we could supplement a generic list with ones for specific types of service locations like “rural medical clinics.” Patterns like “long distance to travel,” “small staff,” or “supplies frequently out of stock” would appear on that list. Some of these features are difficult to change, but considering them is still essential to understanding what impact those constraints have on behavior.
Another example ripe for a list of context patterns is an “application process,” which appears in a variety of places, including applying to college, getting a home loan, or signing up for government benefits. This list would include elements like “instructions with jargon,” “deadlines,” and “future appointment for documentation verification.” Again, more granular patterns could appear in the supplemental lists specific to college applications, borrowing, and so on.
These “context patterns” can allow us to apply a behavioral lens to broader problems and entire systems more easily.
Creating a list of context patterns is very feasible if we start with narrow settings like the examples above. The growing community of applied behavioral science practitioners can contribute to creating and growing the list. UX designers have created rich communities where they share solutions with one another. Have a look at the Figma community for an example.
Context patterns can allow us to apply a behavioral lens to broader problems and entire systems more easily.
Now let’s come back to what context patterns might offer that lists of biases (or psychologies) don’t. I can think of at least two reasons why I hope behavioral designers would find context patterns more useful. The first is that context patterns make behavioral design faster. (In fact, experts are likely already using them, if implicitly, in their work.) The second is that they make behavioral design easier, and therefore more accessible to everyone.
When I first started working in behavioral design 15 years ago, I was amazed how quickly Sendhil Mullainathan could see the behavioral patterns in any situation. In one instance, he and Eldar Shafir sent a young research assistant to go record all the behavioral patterns at a job training center in New York City. We were looking for context patterns that might cause people to stop engaging with the center. She came back with a very long list that included things like the color of the paint on the walls and what program was playing on the TV in the waiting room.
With his experience, Sendhil was better able to discern what mattered for behavior and what didn’t. The color of the paint was less important than the fact that it was peeling because it could affect whether people trusted the center. The fact that there was a waiting room with a TV was more important than what program was playing. That suggested long waiting times, which could deter people from using the services of the job center. However, it also showed that the organization cared enough to try to make the wait less boring.
At the time, I just chalked it up to his genius, but over time, I found myself able to do the same. It’s as if I had finally found the proverbial behavioral lens. I started noticing that sometimes insights about the situation or context repeated themselves. I had developed my own pattern language of sorts. I am confident that many experienced behavioral designers have done the same because using these patterns is a much faster path toward designing solutions.
Psychologies, especially as represented in lists of biases, connote a set of possible failure modes; they point out problems. A set of context patterns, by contrast, could point directly toward a solution.
In the typical process we teach and use in behavioral design, we start with a particular group of people engaging in a specific behavior. Then we hypothesize psychologies or biases that could be at play. For each psychology, we try to identify what in the environment could be triggering it. Then we collect data in the field to narrow our hypotheses around what appears to trigger the psychology again and again. For example, procrastination, channel factors, and identity conflict may all be triggered by a complex application form. Only then are we prepared to start designing solutions. With a list of context patterns, we would see that complex application form right away and be able to redesign it based on what we know other behavioral designers have found effective.
Importantly, it wouldn’t just be behavioral designers who benefit from developing a pattern language. Armed with a list of context patterns, nonprofessionals would also be able to design behaviorally informed processes or services without behavioral science expertise in many common settings. In other words, just like a novice can design a basic website quickly because of all the work UX designers have done to identify effective patterns for web design, so could behavioral design empower ordinary people to do the behavioral equivalent.
Think about what web design patterns opened for people with all sorts of different ambitions: nonprofits with limited budgets can design a website and collect donations with little to no technical expertise; individual writers and artists can showcase their work; small businesses can sell their products across the world.
Imagine these same nonprofits, artists, and businesses with better behavioral processes for their stakeholders and employees. Imagine rural clinics with reduced waiting times, serving more patients; government application forms that help more people access the benefits available to them.
Behavioral designers by and large want to change the world for the better. If developing a pattern language can make behavioral designers better at their work and bring those same lessons to non-experts, we give ourselves a better chance of doing just that. We of course need to experiment to see if this hypothesis is right. But it seems like it’s worth a try.
Disclosure: Piyush Tantia is a member of ideas42 which provides financial support to Behavioral Scientist as an organizational partner. Organizational partners do not play a role in the editorial decisions of the magazine.
