A crit about button placement was really a debate about information architecture.
A designer brought an AI assistant to crit. The feature lives inside an error state: when a billing claim gets rejected, the assistant helps the user understand why and fix it. The open question was where to put the button that opens it. Inside the red error banner? Just above it? Somewhere else entirely?
The first thing the room reacted to was the banner option. Purple button on a red banner. It looked noisy, and people said so. If we’d stopped there, we’d have moved the button a few pixels for aesthetic reasons and called it resolved.
The better instinct in the room was to keep asking why the banner felt wrong. The honest answer wasn’t really about the color clash. It was that binding the assistant to the error banner binds it to errors. This feature is the first of a roadmap. More assistants are coming, and they won’t all live inside failures. If the entry point is welded to a red banner, every future assistant inherits a home that only makes sense when something has gone wrong.
That’s why the placement that won wasn’t the prettiest one. It was the one beside “Get Support.” Putting the assistant there made it a peer of the help the user already knows how to find, which gives the whole future family of assistants a consistent, durable place to live. The decision was about information architecture. It arrived disguised as a complaint about two colors fighting.
The reusable bit: when a crit fixates on a surface problem, the surface problem is usually pointing at a structural one. “Purple on red” was real, but it was the symptom. The team that only fixes the symptom ships a button that looks fine and scales badly. The team that treats the visual complaint as a thread to pull finds the architecture question hiding behind it. Good crit is mostly the discipline of not resolving the easy version of the problem too early.