PresidenteOG Negotiating visual changes
Prohibition: never start a full rebuild or restyle of a UI surface the user has already seen on request phrasing alone, without confirming scope and appetite first — and never bundle two or more separable visual changes into one indistinguishable edit. Working code proves the code works, not that the design is wanted; a surface can be built-and-verified-working and still get discarded on sight, more than once.
Rationalization → counter
| What it sounds like | Why it's wrong |
|---|---|
| "The request sounds urgent / already agreed ('like we talked about')" | Urgent, presumptive phrasing describes their state of mind, not confirmed scope. A 15-second scope check costs less than a discarded rebuild. |
| "They just praised the last small fix — this is the natural next step" | A small, reversible fix landing well doesn't transfer to authorization for a much bigger, harder-to-reverse change on the same surface. These are independent signals. |
| "The two changes live in the same function, separating them is extra work" | Code adjacency isn't conceptual separability. Keeping two changes as distinguishable pieces costs a label, not a rewrite. |
| "This surface has been discussed before, no need to re-ask" | Prior discussion doesn't survive the next instruction being read as blanket approval. Confirm current appetite, especially on a surface with a revert history. |
| "Asking feels like friction / slows things down" | The question is one sentence. An unwanted full rebuild is an hour lost, and it still has to be caught and reverted afterward. |
Red flags — confirm before building, or split before shipping
- A UI surface with a documented rebuild/revert history is getting a new large request.
- One request names two or more distinct visual elements or concerns in the same breath ("also improve X while you're at it").
- Positive feedback on a small, scoped change is immediately followed by a request to scale it up to the whole surface.
- Phrasing that presumes agreement already exists ("like we talked about", "you know what I mean", "just redo it").
Procedure
- Before a full rebuild/restyle: name the surface's revert history if any, and get an explicit "yes, this one" before building — not a formal spec, one confirming sentence.
- When a request bundles 2+ separable changes: ship them in the same pass if asked, but keep them as separately identifiable edits — separate diff hunks, or a clear "change A" / "change B" split — so a later "undo just X" gets answered precisely instead of a manual untangle. Doesn't apply to one cohesive change with multiple properties of the same element (e.g. a badge's color + position together) — only to separable concerns on different elements.