Clarity Trumps Consistency

Say you're building a form with a city picker. Your browser already has one built in: the native <select> dropdown. It works everywhere and nobody needs to be taught how to use it, but it looks like it belongs to a different decade than the rest of your design. So you swap it for a custom listbox, styled to match everything around it.

That instinct isn't wrong, exactly. Consistency matters, up to a point. Does this match the design system, though, or does it just look like it belongs there?

Clarity trumps consistency. If you can make something significantly clearer by making it slightly inconsistent, choose clarity.

Steve Krug wrote that in Don't Make Me Think, a book most people who've worked on a website have at least skimmed. It's fine to break your own design system when doing so makes something easier to understand rather than just different to look at. From inside the design tool, those two feel identical. They only split apart once someone else is using the thing.

The test

Before replacing something standard with something custom, ask two questions, in order. Will people understand the new version without anyone explaining it to them? If not, is what they gain worth that small bit of learning?

The first one is easy to fake from inside the design tool, where your gut has already decided the new version is clearer. Watch the support inbox for confusion tickets on that control. Look at drop-off on that specific field. Or put it in front of three people who have never seen it, and shut up while they try.

Keep the standard version if the answer to both is no. Nobody notices the boring choice.

Click through a few patterns that get reinvented constantly. The same two questions land differently on each.

On date range, frequency helps a little without settling anything. If people touch the filter every week, teaching the calendar once is probably fine. If they barely use it, why are you shipping the heavier control?

Where ego wins

The native dropdown never makes the case study. Teams rebuild it anyway, and the rebuild is usually worse, because the custom version shows up in a writeup while the boring control does not, and from inside the project that always feels like progress even when the only thing that changed is how it looks in Figma.

Custom scrollbars look sleek in a mock: thin, colored to match the brand, hidden until you hover. Then you try them on an actual trackpad or phone, where that thin bar often breaks the smooth glide scrolling is supposed to have and hides the one clue that the page scrolls at all.

Nobody was ever confused by the old scrollbar. This one isn't clearer. It's just different, and it happens to be worse.

On a phone there is no hover, which is where custom tooltips usually fall apart. Someone taps the icon, the tip appears, and half of them never dismiss when they tap away, or they cover the control the person was trying to use. The native title attribute is ugly and limited, and it still somehow causes fewer stuck fingers. If the control only makes sense once the tip shows up, put the words in the label.

Search palettes and custom dialogs can earn their keep when they do something the native control cannot: jump anywhere in a dense product, or run a multi-step sheet. Restyling either to match your border-radius is a different project, and a worse one.

Ask whether someone could use your version without anyone explaining it. If not, ask whether the gain is big enough to be worth teaching. When both answers are no, ship the boring one. When they disagree, sit with it.