Two text fields in the older Rightel library were both called “Large.” One was 48 pixels tall. The other was 60.
The label didn’t help me choose between them.
There wasn’t a clear difference in their purpose to explain the extra height. A designer could pick either one for an equivalent task and end up with a different form layout. Both choices came from the library.
I found this while working on Rightel’s design system. The library already had components, but some of them left designers without a clear reason to choose one version over another.
Both sizes were available under the same label. The library didn’t explain when to choose one over the other.
Why we started with Material Design
We had limited time and implementation capacity, so we chose Material Design as our starting point.
But our product needed components beyond what we could use directly. We built those additions around Material’s rules, which meant spending considerable time studying how its components were structured, how their layers fit together, and how that structure supported different states.
Before extending a component, I needed to understand how it was built. A similar appearance wouldn’t help if our version handled content or states differently.
Choosing Material gave us a starting point. It still left us responsible for how we adapted it and how we documented the components we added. The inconsistencies described here came from the Rightel library I reviewed; they weren’t findings about Material’s own library.
When the library leaves a decision unanswered
The height difference was easy to spot. Other gaps took a closer look: similar controls under different names, inconsistent corner radii, configurations that weren’t clearly exposed, and component families with incomplete interaction states.
Each gap left someone with a decision to make while designing a screen.
Take a missing state. If a form needs a particular error treatment and the component doesn’t support it, the designer still has to finish the form. A local edit solves the immediate problem. But unless that decision comes back into the library, the next designer has to solve it again.
If those local fixes stay outside the library, other designers can keep running into the same gaps. The component needs to support the recurring requirement or explain how to handle it.
What I expect a design system to do
A useful component library gives me a control I can place on a screen. A design system also helps me decide whether it belongs there, how to configure it, and what should happen when someone interacts with it.
For a text field, that means more than choosing a height and a border color. I need to understand the label, supporting text, optional icons, and feedback. I also need to know which decisions are fixed and which can change with the context.
The same questions reach into implementation. A focus state drawn in Figma needs a corresponding behavior in the product. A name should point designers and developers toward the same thing. When a new need appears, there should be a way to review it without quietly creating another competing version.
I want another designer to be able to use the component without asking its author to explain the same choices each time.
Consistency needs a reason
The two Large fields didn’t prove that every input should have the same height. Different contexts can justify different dimensions. A compact control and a roomier one may both belong in a system.
If both sizes are needed, their names and guidance should explain where each belongs.
In this case, one field was roughly a quarter taller than the other, yet both presented themselves as the same choice. I couldn’t treat that difference as a useful variant without first finding the need it served.
My working rule became simple: keep a difference when it supports a real use case, and make that use case explicit. When it doesn’t, investigate whether the difference is accidental before preserving it in the next version.
That matters because standardizing everything too quickly can remove something a product actually needs. An audit should help you understand the differences before you decide which ones to keep.
Making choices visible in Figma
Learning Material’s component structure informed how I worked on the evolved library: clearer anatomy, properties, variants, states, and usage guidance. For text fields, that meant organizing filled and outlined styles, labels, input values, icons, and state behavior into a more predictable structure.
For the components our product needed us to add, I had to consider how their structure would fit the same rules. A component could solve a specific screen’s problem and still need more work before it belonged in the shared library.
The point was to make those choices available where someone was working. If a component supports a leading icon, the configuration should say so. If two styles serve different purposes, the guidance should explain the choice.
The revised family brings styles, states, themes, and content options into a shared structure.
Try one component before judging the whole library
Pick a component that appears in several active screens. Compare the instances with the library version and ask:
- Can I tell which version to use without asking its author?
- Do the differences reflect distinct needs, or just separate design decisions?
- If the library builds on an existing system, do its custom additions follow that system’s rules?
- Can I represent the states and content the screen requires using the component’s existing properties?
- If the component doesn’t support what the screen needs, do I know who to discuss that with?
Write down where the answers become unclear. Keep the component, its screen context, and the unanswered question together. That gives you a specific problem to investigate before you start rearranging the library.
In the next post, Before You Build, Audit What You Already Have, I’ll work through that audit: collecting examples from screens and libraries, grouping them by purpose, and deciding which gaps to address first.