# The Exposure Grid

> Two questions decide how much interface a decision deserves: can it be undone,
> and will the user notice. Four quadrants, four different design postures. Most
> teams apply the same amount of ceremony everywhere, which means the dangerous
> things get too little and the harmless things get too much.

---

## The two axes

**Reversibility.** If this turns out wrong, what does it take to get back? Not
whether it is theoretically reversible. What it actually costs the user in
actions, time, and dignity.

**Visibility.** Would a normal user notice it went wrong, without being told, in
the course of normal use? Not whether it is visible in principle. Whether they
would actually catch it.

Visibility is the axis teams skip, and it is the one that matters more. A
reversible mistake nobody notices does not get reversed.

---

## The grid

```
                    HIGH VISIBILITY          LOW VISIBILITY
                  (user will notice)       (user will not notice)

  REVERSIBLE      Q1: Let it run           Q2: Surface it
                  Minimal ceremony          Make it noticeable
                  Cheap undo nearby         Then cheap undo

  IRREVERSIBLE    Q3: Confirm              Q4: Do not automate
                  Explicit, in-session      Human in the loop
                  Show what is at stake     Or do not build it
```

---

## Q1: Reversible and visible. Let it run.

The user will see it and can fix it. This is the quadrant where speed wins and
ceremony costs you.

**Posture:** no confirmation, no interstitial, no "are you sure." Do the thing.

**What the interface owes:** an undo that is at least as cheap as the action, in
the place the result appears.

**The mistake to avoid:** adding a confirmation dialog because it feels
responsible. Every unnecessary confirmation teaches users to dismiss dialogs
without reading, which is a cost you pay in Q3 where it matters.

## Q2: Reversible and invisible. Surface it first.

The most under-designed quadrant, and the source of the "I did not know it did
that" complaint that shows up months later.

**Posture:** the design work is disclosure, not prevention. Reversal is easy, so
the only real problem is that nobody knows there is anything to reverse.

**What the interface owes:**
- A visible account of what happened, in a place the user actually goes.
- A summary at the next session start if it happened while they were away.
- The undo attached to that account, not somewhere else.

**The mistake to avoid:** logging it somewhere technically accessible and calling
that transparency. An audit trail nobody opens is a record, not a disclosure.

## Q3: Irreversible and visible. Confirm properly.

The user will notice immediately, and cannot fix it. Confirmation earns its
keep here, and only here.

**Posture:** explicit, in-session, human.

**What the interface owes:**
- The confirmation states what will happen, in specifics, including the count and
  the scope. Not "are you sure."
- It names what will not be recoverable.
- For large or unusual scopes, it shows a sample of what is affected.
- The confirming action is proportionate to the stakes. Type-the-name friction is
  appropriate occasionally and infuriating routinely.

**The mistake to avoid:** the confirmation being the first time the user learns
what the system already did. That is not a confirmation, it is a notification
with a button.

## Q4: Irreversible and invisible. Do not automate it.

Cannot be undone, will not be noticed. There is no interface that makes this
acceptable.

**Posture:** a human is in the loop, or the feature does not ship in this form.

**What to do instead:**
- Make it reversible, which moves it to Q2.
- Make it visible, which moves it to Q3.
- Reduce the scope until it is one of the above.
- Or leave it manual.

**The mistake to avoid:** treating a well-written warning as a solution. Warnings
do not create visibility after the fact, and nobody reads the one that mattered.

---

## Plotting your surface

List every action your product takes, then place each one.

| Action | Reversible? | Would the user notice? | Quadrant | Current posture | Matches? |
|---|---|---|---|---|---|
|  |  |  |  |  |  |
|  |  |  |  |  |  |
|  |  |  |  |  |  |

The last column is the finding. Look for two patterns:

**Q1 actions with Q3 ceremony.** You are slowing people down for nothing and
training them to click through dialogs. Cheap to fix and it makes the product feel
noticeably better.

**Q4 actions running autonomously.** Stop and fix these first. Every product I
have seen do this audit finds at least one, and it is usually something added
late, by a well-meaning person, to save a step.

---

## Two refinements worth making

**Ask who the user is.** An action that is Q1 for an admin can be Q3 for the
person the action was taken about. Plot the grid for the affected party, not just
the acting party. This is where products that automate on behalf of one person
and affect another go wrong.

**Ask about the fifth time.** Frequency changes visibility. The first automated
action is noticed. The fiftieth is furniture. Some Q1 actions become Q2 actions
simply by being common, and the design response is a periodic summary rather than
a per-event notice.

---

## The one thing to do this week

Plot every autonomous action your product takes. Twenty minutes, a whiteboard,
the four boxes. Anything landing in Q4 is the conversation to have before Friday,
and it is worth having with the person who built it rather than about them.

---

_From "Downside Exposure for Interfaces", chapter 15 of The Design Operating Model._
_falkster.com/design/downside-exposure-for-interfaces_