Three Labels, Six Surfaces

A pattern I keep ending up with, on enterprise after enterprise: an action that should run exactly once per item — upgrade, migrate, enroll, archive, apply baseline — surfaced from six different places. A toolbar. A card footer. A row inline action. A recommendation card. A side drawer. A detail page. From one entry point it’s trivial. From six, it’s where teams ship double-runs, ghost states, and bug reports that all open with “I think I already did this.”

I used to design each surface in isolation, which is how the bug got in. Every team I joined had a different label per surface — Upgrade, Upgrade now, Upgrade selected, Re-upgrade, Upgrade again. Each one defensible on its own. Together, they made the product feel like five products glued at the seams.

The rule I now apply is small enough to fit on a sticky note. Every trigger, on every surface, uses exactly one of three labels:

• <Action> when nothing in the target set is done.
• <Action> remaining when some are done, some aren’t — and it operates on the not-done subset only.
• Already <action verb past tense>, disabled, when everything is done.

That’s the entire UX of the pattern. Upgrade / Upgrade remaining / Already upgraded. Migrate / Migrate remaining / Already migrated. The full state model, the per-surface enforcement table, and the multi-step dialog rules are in the Idempotent Bulk Action Pattern.

The biggest unlock isn’t the labels themselves. It’s the cross-surface enforcement table — a small grid where every entry point names its disabled rule and its relabel rule. The act of filling in the table is how you catch the one surface that quietly accepts a double-run. Interestingly, that surface is almost always the recommendation card, because recommendations are the most likely to be implemented last and reviewed least.

Three labels, six surfaces, one map of completed state. The whole thing fits on a page and pays itself back the first time someone clicks twice.