---
title: "Let people click, then repair the state"
locale: "en"
url: "https://irz.fr/en/articles/let-me-click-state-repair-en"
markdown_url: "https://irz.fr/en/articles/let-me-click-state-repair-en.md"
category: "tech"
tags: ["UX", "interface", "accessibility", "affordance", "Ilya Birman", "interaction"]
published_at: "2026-08-28T09:05:00.000Z"
author: "Manon Girard"
translation: "https://irz.fr/fr/articles/let-me-click-state-repair-fr.md"
---

# Let people click, then repair the state

Ilya Birman's 'Let me click' principle accepts intent before repairing dependencies. A reliable target must look actionable, be reachable and produce a coherent state.

A control can be visible, large enough and neatly drawn yet still feel broken. Refusing the click at the exact moment someone tries to use it is enough.

Ilya Birman summarizes this problem with a rule he calls **“Let me click.”**[1](https://ilyabirman.net/meanwhile/all/let-me-click/)

Birman is not asking designers to make every surface interactive. The point is narrower: do not turn the current state into a ban when the user's intention is still valid. When controls depend on each other, the interface can accept an action first and reconcile the resulting state afterwards.

That is the difference between **preventing** and **reconciling**.

## The last checkbox

Birman's first example has several notification checkboxes with a rule that at least one must remain selected.[1](https://ilyabirman.net/meanwhile/all/let-me-click/)

The obvious implementation disables the last active checkbox. The form stays valid, at the cost of something awkward: the user no longer controls the order of actions. Someone who wants to disable chat before enabling email is forced to do the reverse.

Birman moves the constraint instead. The last checkbox can turn off; immediately afterwards, the system selects a fallback option.[1](https://ilyabirman.net/meanwhile/all/let-me-click/)

The business invariant survives; only the order of gestures stops being prescribed.

> **Accept intent, repair state**
> Comparison between an interface that blocks an action to preserve a constraint and one that accepts the action then automatically restores a valid state
> - THE CONSTRAINT DOESN'T DEFINE THE ORDER
> - BLOCK
last checkbox disabled
forced order
> - RECONCILE
accept the click
then restore a default
> - Same final invariant, but the user keeps control over action order.
> Birman's principle moves the constraint: it applies to the final state, not necessarily to every intermediate gesture.

The mechanism reads like a tiny transaction: intent, action, then dependency repair.

## The field that activates

The second example pairs a “send by email” checkbox with an email-address field.[1](https://ilyabirman.net/meanwhile/all/let-me-click/)

It is easy to justify greying the field while the checkbox is off. The address really has no job when email delivery is disabled.

But the user may want to type the address first.

Birman keeps the field editable anyway. Typing an address turns the email option on automatically.[1](https://ilyabirman.net/meanwhile/all/let-me-click/)

Going the other way requires more care: clearing the checkbox should not erase the address. The interface can repair its own state without deleting data the user entered.[1](https://ilyabirman.net/meanwhile/all/let-me-click/)

Another rule falls out of this example: **automatic repair should not be more destructive than the gesture that triggered it**.

## Impossible dates

The third example moves the boundary again: filtering too early can annoy just as much as validating too late.

A date picker can hide June while day 31 is selected because June 31 does not exist. But a person entering June 10 may reasonably choose the month first.[1](https://ilyabirman.net/meanwhile/all/let-me-click/)

Birman prefers allowing June and clearing the incompatible day. If a conflicting day is selected afterwards, clear the month instead.[1](https://ilyabirman.net/meanwhile/all/let-me-click/)

An impossible date is cleared quickly. Dependencies never need to become pre-emptive locks.

> 3 LAYERS
> **A reliable click needs more than a button**
> - the element must look actionable: 1. Signifier
> - the hit area must be easy to acquire: 2. Target
> - the click must accept intent and produce a legible state: 3. Transition
> - missing any one layer is enough to feel broken: Failure
> Let me click mostly addresses layer three: don't turn a state dependency into an arbitrary interaction ban.

## Before the click

Birman's principle assumes the user can tell where to click in the first place.

Nielsen Norman Group distinguishes an affordance from its **signifier**: an action may technically exist without the interface making its location obvious.[2](https://www.nngroup.com/articles/top-10-application-design-mistakes/) On a screen, almost any pixel can receive an event. Users should not have to play minesweeper to discover which ones matter.[2](https://www.nngroup.com/articles/top-10-application-design-mistakes/)

The first contract is visual: anything that promises an action should deliver one, and important actions should not require a treasure hunt.

Most of that consistency is learned. Underlines, capsules, raised cards, hover responses and pointer changes become promises through repetition.

Break the promise and every later interaction costs another moment of hesitation.

## The real target

A perfect signifier cannot rescue a tiny hit area.

WCAG 2.2 Level AA specifies a minimum pointer target of **24 × 24 CSS pixels**, with exceptions including sufficient spacing and inline links.[3](https://www.w3.org/TR/WCAG22/#target-size-minimum) Apple's button guidance recommends a hit region of at least **44 × 44 points** so controls remain easy to activate with fingers, pointers and other input methods.[4](https://developer.apple.com/design/human-interface-guidelines/buttons)

Those numbers have different status, so treating them as a contradiction misses the point. The useful lesson is that a button has two sizes: **the visible shape and the hitbox**.

A visually small icon can therefore own a much more generous invisible hitbox.

## When blocking is real

“Let me click” is not an instruction to enable every command all the time.

Some actions genuinely cannot run: permission is missing, a resource does not exist, an irreversible operation needs confirmation or a service is offline. Inventing a result just to honor the click would be worse than blocking it.

The useful split is narrower: **is the action impossible, or does the current state merely make its order inconvenient?**

In Birman's three examples, the user is expressing a valid intention. The dependency model is what became too rigid.

In those cases, the interface can absorb part of the model's rigidity itself.

## A small architecture

For a developer, the principle becomes three practical tests:

1. Can the user identify the action area?
2. Can they acquire it without excessive precision?
3. If their intention is valid but the intermediate state is not, can the system reconcile that state without destroying user data?

The third test is easy to lose in a Figma file and tends to reappear later as implementation work.

It forces the team to design transitions rather than just screens.

A good interface does not merely display what is legal right now. It tries to understand **what the user is attempting to do**.

Then, when possible, it lets them click.

## References

1. [Ilya Birman, Let me Click, 2026](https://ilyabirman.net/meanwhile/all/let-me-click/)
2. [Nielsen Norman Group, Top 10 Application-Design Mistakes — Hard-to-Acquire Targets](https://www.nngroup.com/articles/top-10-application-design-mistakes/)
3. [W3C, WCAG 2.2 — Success Criterion 2.5.8 Target Size (Minimum)](https://www.w3.org/TR/WCAG22/#target-size-minimum)
4. [Apple Human Interface Guidelines — Buttons](https://developer.apple.com/design/human-interface-guidelines/buttons)