In any project management tool, the select component may look like a small detail, but it quietly carries a lot of weight. For years, ours shifted shape depending on the page — sometimes a dropdown, sometimes a custom widget, each with its own quirks. That inconsistency made it harder for users to build intuition and harder for the team to maintain. With the arrival of our design system, the component finally found its form, along with a clear purpose. Accessibility also became a first-class consideration, baked into its very foundation.
From Out of Shape to In Form
Before the design system, the select component came in too many flavors. Some pages used the browser's native dropdown, others had bespoke versions with slightly different behaviors. Over the years, as different teams shaped the product, these variations piled up. It wasn't anyone's fault — it's a common outcome when there's no shared guidance to lean on. Eventually, the lack of consistency became too visible to ignore, which is what pushed us toward the design system.
Once we recognized the inconsistency, the next step was obvious — align the select with the rest of our form elements. Inputs and textareas already had a defined visual language, so we drew from that same system. Tokens for border radius, colors, and placeholder styles gave us a solid baseline and helped everything feel like part of the same family. On top of the visual side, we looked at decision-making principles. Hick's Law, for instance, reminds us that too many visible options can overwhelm users, so we capped the visible list at seven. For cases where the list goes well beyond that, we added search to keep navigation fast and clear.
Accessibility makes selects trickier than they first appear. Native elements behave differently across browsers, which often pushes teams toward building custom React components for consistency. The catch is that once you go custom, you inherit the full responsibility of restoring everything the browser used to handle automatically — keyboard navigation, screen reader support, focus management, and so on. That meant we had to slow down and be deliberate. We leaned on guidance from accessibility experts like Adam Singer, Una Kravets, Sara Soueidan, Hidde de Vries, and Manuel Matuzović to make sure we weren't missing anything.
The goal was simple: a select that's as visually consistent and stylish as it is usable and accessible for every user, so the end result is a component that feels fully at home with the rest of our form elements, combining visual consistency with thoughtful accessibility. Drawing on our design system, we aligned borders, colors, placeholder styles, and spacing with inputs, textareas, and date pickers, giving the component a cohesive look across the product. At the same time, it implements ARIA roles, manages state with ARIA attributes, and supports intuitive keyboard interactions. Focus and hover feedback are clear, and the component remains fully customizable via CSS or Tailwind.