During a redesign of a complex clinical software platform, I discovered that a legacy configuration feature had been silently rebuilt with reduced functionality — and no one had caught it.
The original feature let users save panel visibility preferences globally, across all cases. After a scope reduction during redesign, only case-level settings remained. But the UI was never updated to reflect that change. The control stayed where it had always been — disconnected from the panels it was supposed to control, with no indication of what level it was actually affecting.
A quick fix was proposed. I pushed back — not by rejecting it, but by making the full problem visible.
The Challenge
A key configuration feature had changed behavior mid-redesign — but the interface hadn't caught up. This introduced three specific risks:
A spatial mismatch between the control and the function it affected
No UI feedback about whether a setting applied at the case level or globally
A genuine risk of user confusion and unintended configuration in a clinical context
The behavior had changed. The interface hadn't.
The Approach
Rather than arguing against the quick fix in isolation, I mapped four possible paths forward — each with explicit tradeoffs between clarity, risk, and effort.
Option 1 — The quick fix as proposed I documented exactly where it introduced risk: it would silently overwrite local settings, confuse users about scope, and add backend complexity while appearing simple.
Option 2 — The ideal solution Not a scope recommendation — a signal. This is what responsible global configuration would actually require: scoped controls, UI feedback, tooltips, default states. It framed the delta between "possible" and "responsible."
Option 3 — A lean MVP Most of the clarity from Option 2, fewer heavy UI patterns. A path to reintroducing global presets responsibly if scope allowed.
Option 4 — A minimal UX patch No backend changes. Just better placement and labeling of the existing control to eliminate the spatial mismatch and reduce ambiguity.
Each option was designed to reveal, not just resolve.
The Outcome
We chose Option 4. The control was relocated, the ambiguity was eliminated, and the fix shipped without backend changes or added scope.
There was initial tension when I raised the issue — but arriving with alternatives rather than just objections helped the team move quickly to a better answer. The final solution was met with relief.
The quick fix looked simple, but wasn't. The real fix was simpler — and safer — because it came from understanding, not instinct.
Lessons Learned
Make the problem visible before proposing the solution. The team didn't need to be convinced I was right — they needed to see the full shape of the problem. The four-option framework did that better than any argument could.
Alternatives create alignment. Showing up with options rather than objections reframed the conversation from "Samuel vs. the quick fix" to "us vs. the problem."
UX design isn't only about solving problems. It's about helping teams see them clearly enough to solve them well. Slowing down just enough to reframe the issue meant we avoided rework, aligned faster, and shipped something everyone felt good about.
