Every day, teams make architecture decisions that affect the overall design of their product. Unfortunately, sometimes they make bad decisions. As software architects and technology leaders, our responsibility is to create environments which make it easier for teams to choose what’s best for the product, while recognizing the human behaviors that make people susceptible to various biases that ultimately lead them to fault.
The term “choice architecture”, coined by economist Richard Thaler and legal scholar Cass Sunstein in their 2008 book Nudge, describes the design of a system that influences people's choices without removing their ability to choose differently. This concept is based upon “libertarian paternalism” - the idea that you should offer people the freedom to choose, but that there is usually a known best choice which should be made clear, obvious and easy to select.
Thaler and Sunstein show that with the right choice architecture, you can influence or “nudge” people into making the best choice without restricting their options. The authors created a unique mnemonic based on the principles underlying a good choice architecture:
INcentives,
Understand mappings
Defaults
Give feedback
Expect error; and
Structure complex choices
A nudge, as we will use the term, is any aspect of the choice architecture that alters people's behavior in a predictable way without forbidding any options or significantly changing their economic incentives. To count as a mere nudge, the intervention must be easy and cheap to avoid. Nudges are not mandates. Putting fruit at eye level counts as a nudge. Banning junk food does not.
Choice architecture is as applicable to software as it is to any other domain where humans make decisions. Internal engineering platforms are one way architects and technology leaders can create decision-choice environments for their teams. In this blog, you’ll better understand how all of the elements of Thaler and Sunstein’s NUDGES principles come into play in good engineering platforms.
Choice architecture principles
Defaults
The default option is a preset selection that an individual automatically receives if they do nothing. A large body of research has shown that, all things being equal, consumers are more likely to choose default options because it's easier. Consideration of what a sensible default is in your choice architecture allows humans to make guided decisions on the right choice. Sometimes that default might be the lowest common denominator (like fruit which meets all dietary restrictions like non gluten, non dairy, vegan, kosher and halal), sometimes it’s the option which provides most value to most people (like a managed fund for retirement investments).
An example of how this applies to platforms
|
Being able to provision multiple tech stacks but defining a sensible default. |
Give feedback
Well designed feedback systems tell people when they are doing well and when they are making mistakes in a timely manner. Choosing retirement investments is one example shared in Nudge where feedback from plan performance can help the investor select the right investment for them.
An example of how this applies to platforms
|
Metric dashboards, code analysis tools, build pipelines, fitness functions |
Expect error
To err is human. Good choice architectures anticipate and prepare for errors to occur. Contrast the difficulty of getting a USB plugged in the right way every time, to the ease of plugging in an Apple phone charger, which expects error and allows for any direction to make a connection.
An example of how this applies to platforms
|
Predictive command line interfaces (CLIs) which prompt for correct keyword usage, automated testing, API tests, PACT |
Understand mappings
The path from the choice and its consequence is called “mapping”. Sometimes it's easy to see the mapping: the choice of strawberry, chocolate and vanilla ice cream is easy to make because the map of the choice to the taste is known based on your past experiences. However, it’s more difficult to map out more complex or less familiar choices.
Good choice architectures make the mappings as clear as possible. For example, if different food options were presented not with the number of calories but with the number of burpees needed to burn the energy, you might make healthier choices.
Being able to map consequences of not only your selected option but also the alternatives gives better feedback. You may never know that there is a quicker route home if you do not get feedback on alternative routes. Thaler and Suntein call this RECAP: Record, Evaluate and Compare Alternative Prices.
An example of how this applies to platforms |
Architecture decisions are ones that offer significant trade-offs for all the choices, making them difficult decisions. Making the mapping between decision and trade offs clear and accessible is one way we can empower teams to understand those trade offs.
For example, choosing sync vs async communication has serious trade-offs — switching to async to "nudge" users towards eventual consistency, for example, has a host of other trade-offs that need to be clearly articulated in a way that makes them digestible.
|
Structure complex choices
Social science research reveals that as choices become more numerous or vary on more dimensions, people adopt simplifying strategies. When the size and complexity of available options grow large, a good choice architecture provides structures to automatically simplify the process. Hyper-personalization is an example that Amazon uses to help simplify the selection of books. Paint wheels in hardware shops help customers choose the right color from the innumerable different shades of blue.
An example of how this applies to platforms |
Group individual components together as stacks, e.g. SPA stack (React, S3), Serverless stack (Node, Lambda, infrastructure), Eventing stack (K8S, Confluent, Kotlin). Structure choices around levels of availability or performance and their implications these have on decisions e.g. all customer facing services must run in multiple regions active-active
|
Create incentives
People make better decisions when the right people are provided the right incentives. Unfortunately many cases are filled with conflicting incentives. One way to start thinking about conflicting incentives is to consider “Who uses? Who chooses? Who pays? Who profits?” and presenting the salient incentives.
An example of how this applies to platforms
|
Engineers and Operations are often seen as having conflicting incentives: Engineers need to get features out the door quickly but Operations are responsible for a stable system. A good platform enables engineers to quickly and frequently deploy good quality software which is proven to be reliable and stable: thereby satisfying both incentives.
|
Poor choice architectures lead to ineffective platforms
Ineffective platforms lack many elements of a good choice architecture. For instance, many platforms only allow for the provision of a single tech stack, removing the freedom for delivery teams to adopt the stack which best fits their application (the consequence being most teams ignore the platform). Conversely, when many stacks are provided, there is no obvious default choice for delivery teams to select and the mapping between choice and consequence is unclear.
Essentially, ineffective platforms do not cater for human behavior.
By considering the choice architecture that we adopt and applying the NUDGES concept, we can create environments which make it easier for delivery teams to choose what’s best for the product, while acknowledging and taking into account their human behavior.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.