Decision architecture

What is decision architecture?

Decision architecture is the way a decision-making process is organized: who makes the call, who contributes, what evidence they consider, how they compare alternatives, and how they learn from the result. In an organization, it includes the routines and responsibilities around a decision, not just the options on the table.

Imagine a team choosing a new customer-support system. Everyone has seen the same demos. Everyone has an opinion. But nobody has agreed on what the system must do, who gets to decide, or whose experience matters most. Another meeting will not necessarily solve that problem. The team needs to decide how it will decide.

In an interview with HEC Paris, Olivier Sibony uses decision architecture to describe changes to how organizations make decisions. He emphasizes two parts: the people involved and the process they use. This is a practical approach to organizing judgment, not a single standardized intervention with a fixed effect.

Decision architecture and choice architecture

The terms overlap, and writers do not always draw the same boundary. Choice architecture usually concerns the environment in which someone encounters a choice: the options, their order, the information shown, the default, and the effort needed to choose. Decision architecture can include those things while also addressing how a group reaches and carries out a decision.

For the support-system purchase, putting all vendors' annual costs in one comparison table is choice architecture. Deciding who prepares that table, how the team checks the figures, who can challenge the recommendation, and who approves the purchase is decision architecture in this broader sense.

Johnson and colleagues' account of choice architecture includes both structuring the choice task and describing its options. So the distinction is not simply “individual versus group” or “small versus important.” It is the question being asked: how is this choice presented, or how is the whole decision organized?

What needs to be decided before the decision?

A useful starting point is to make the parts that people are currently guessing about explicit. For a consequential team decision, that might mean answering these questions:

• What problem are we solving? State the outcome, the constraints, and whose needs matter. “Buy new software” is already a proposed answer. “Reduce the time customers wait for help” leaves room for other answers.
• Who has which responsibility? Separate the person who decides from those who supply evidence, offer advice, or implement the result. Asking for input does not have to mean requiring unanimous agreement.
• What will count as a good option? Agree on relevant criteria before arguing for a favorite. Cost, accessibility, reliability, and the time needed to switch may matter in different ways.
• How will alternatives get a fair hearing? Make room for evidence against the preferred proposal. Include keeping the current arrangement when it is a real option, not just an obviously bad comparison.
• When will we decide and review the result? Set a decision date, record the main assumptions, and identify what later evidence would justify another look.

These are design questions, not a requirement to create five new documents. A small, easily reversed decision may need a short conversation. An expensive commitment that affects several teams deserves more care. A decision process also has costs: meetings, delay, and work taken away from other tasks.

Example: choosing a support system

Return to the team comparing software. Suppose its current process is to watch three demos and then discuss which product felt best. The most polished demo could become the reference point even if the product makes everyday work harder.

Here is one way the team could organize the decision differently. This is a hypothetical example, not a tested recipe.

First, the support lead defines the problem using actual customer requests. The team then writes a small set of requirements, including the tasks agents must complete, the information they need, and the budget. It checks whether the problem requires new software at all. Better staffing or a change to the existing system might address it.

Next, agents try the same representative tasks in each promising system. They record what worked and what failed before discussing their impressions together. Finance compares the total cost, including migration and training, rather than only the advertised subscription price. The support lead asks what would make the leading option a poor choice.

The person responsible for the purchase makes the call using that evidence. The team records the reasons, the remaining uncertainties, and the conditions it expects the new system to improve. After the switch, it checks those expectations against the actual work.

Notice what changed. The team did not just make the comparison table prettier. It changed how options were generated, how evidence was collected, and who was responsible for the result. None of that guarantees the purchase will work out. It does make the reasoning available for scrutiny.

Can decision architecture remove cognitive bias?

No process makes an organization bias-free. The useful question is whether a particular change addresses a particular weakness. If a team keeps searching for evidence that supports its first idea, a concrete question such as “What would show this is the wrong option?” gives it something to investigate. Telling everyone to avoid confirmation bias does not specify what they should do differently.

A procedure can also become an exercise in filling boxes. People can complete the scorecard and still protect the boss's preferred answer. Evaluate the way the process is used, not just whether the organization has one.

Keep the quality of the decision separate from the outcome. A carefully considered choice can turn out badly because of information nobody had. A poorly considered one can get lucky. Outcome bias is the tendency to let the result distort that assessment. Record what was known at the time so a later review can distinguish weak reasoning from an uncertain world.

For a further practical example, The Uncertainty Project walks through an organizational decision process. It is a practitioner illustration, not evidence that one meeting sequence works for every team.