Designing for Discovery

Many design systems fail not because the components are badly built, but because they are hard to find and hard to recognize once found. A component that cannot be located quickly is a component that will be rebuilt from scratch — and that is how design debt accumulates.

The key to making components discoverable is treating naming as a design problem, not a labeling afterthought. Names are the primary interface your team has with the system, so they deserve the same care you give to the components themselves.

People search for components using mental models shaped by their own experience, not by your documentation. A button is rarely called a "button" in a search box — it is more often a "cta," a "submit," or a "primary action." If your naming follows internal conventions instead of common usage, you are hiding the component from the very people you want to use it.

A useful exercise is to audit the language your team actually uses in daily conversation, in code comments, and in issue trackers. Those words are your vocabulary. Map component names back to that vocabulary, and you will find that discovery improves dramatically. Conversely, names that sound elegant in a design review — but appear nowhere in your team's natural speech — will get ignored.

Structuring Names for Findability

There are three kinds of component naming conventions you can adopt: functional, semantic, and a blend of both. Each has trade-offs, and a mature system will combine them deliberately.

Functional names describe what the component does ("navigation," "filter," "search"). These are intuitive and easy to link to user intent, but they end up overloaded quickly. Every component on a page can be described functionally, and vague functions like "widget" or "module" leave too much room for interpretation.

Semantic names describe meaning or hierarchy ("hero," "utility," "masthead"). They keep components free of context, but they rely on shared culture within the team. Define these carefully, because the moment you onboard a new person without that culture, the names become opaque.

For larger systems, a blended approach is often strongest: a semantic prefix to group related components by intent, followed by a functional suffix to capture what the component accomplishes. For example, a chunk of UI for the primary marketing page could be hero-carousel or utility-navigation.

The four pieces of a searchable name

When you name a component, aim for it to be four things:

  • Describing the function: What does it do? A person should be able to guess, from the name alone, roughly where they might use it.
  • Avoiding connotative words: Stay away from internal jargon or cute names. They are memorable to a few but invisible to many.
  • Clear to the point of boredom: Boring names get reused. Shiny names get admired and then forgotten.
  • Backed by a logical structure: A naming convention is only as resilient as the documentation that explains its rules.

One common trap is trying to force all components into nouns or verbs as if a taxonomy were a grammar lesson. Instead, orient around intention. If your team says "I need this popup with a note," name it a popup-note-dismissible, not a notifier or a tooltip-info.

Indexing: The Missing Layer

Searchability is partly a naming problem and partly an indexing problem. You can craft perfect names and still lose components if your system lacks a meaningful order.

Indexing works when you define categories that match both product structure and user behavior. Organizing everything alphabetically is a last resort, not a strategy. Instead, think about how components will be used: by the pattern they serve (form elements, feedback, layout), by the page they belong to (checkout flow, profile pages), or by the layer they sit in (primitives, composites, layouts).

Whatever categories you pick, write down the thinking that produced them. A system where nobody remembers why a component sits in one place will see components duplicated in other folders, "just to be safe". Good indexing also include metadata. Tags, related patterns and ownership information make the component easier to surface. Crucially, the index should be something of a navigation system in itself — a way for designers and engineers to move from a user problem to a working solution without knowing the exact name in advance.

Auto-layout and the cost of over-automation

Auto-layout is an incredible time-saver, but it has a hidden tax: components that rely too heavily on auto-layout stop being flexible and start being opinionated. When spacing and measure are ruled by bendy group settings writ into each instance, adjusting the instance to an unintended but legitimate context becomes a fight against the component itself.

The answer is restraint. Build auto-layout so that teams can compose components quickly, but deliberately omit it where it ends up freezing adjustable spacing or fixing every nested padding. Use auto-layout for the repeatable parts, by all means, but leave some looseness in how a component is assembled so that layout misuse does not become the reason for a whole new component to be created.

The goal is a component whose behavior is self-evident enough to be predictable but held light enough to receive changes without breaking at the seams.

When full automation is unavoidable, tie it to explicit system tokens rather than ad hoc values. The visual grammar should be visible in markup and audit trails. Shorthand is for maintainability, but not if it becomes shorthand for mystery.

Naming in Practice

Broadly speaking, you have two options when you name a component: content-out or context-in. With real content in place, you will know very quickly where things should live.

Moving from the specific to the generic comes with experience. You will notice patterns that repeat between contexts and are worth abstracting; fold them into a shared component name. The attempt to ever-generalize too early results in philosophical blobs called block or element which nobody can comfortably apply. Deciding to fight this is a constant act of care while you inspect the evolution and usage of your system.

Adoption Is a Design Problem

Sparkbox's 2022 design systems survey ranks the top three challenges teams face as technical/creative debt, parity between design and code, and adoption. The first two are largely understandable constraints of tooling and organizational structure — no design tool offers export robust enough to automate handover, and no tool can repair siloed workflows. Adoption, however, is a different matter. If the system is well-built, why aren't people using it effectively? Making a system genuinely adoptable comes down to three levers: naming conventions, community-building, and communication.

Naming Conventions

Component naming in design tools spans everything from camelCase to kebab-case to slash-delimited hierarchies to descriptive labels like “Product Card — Cart.” Every convention has trade-offs, but the core requirement is discoverability: can someone find the component they need? That should drive the choice.

It's tempting to map design and code names one-to-one, but designers and developers search for and implement components differently. Naming should serve the audience. The Figma component description field is a practical bridge here: it provides space for additional searchable names or aliases. If the code name is headerNavItemActive but the design file calls it “Header link” with a toggled property, the developer-facing name can live in the description for searchable parity.

An illustration that explains how the component description field within Figma can be used in order to list out the possible name aliases of a component.
We can use the component description field within Figma to list out possible name aliases of a component. (Large preview)

The same logic applies to styles. Developers may work from tokenized semantic styles in code while designers need less abstract styles for ideation. Maintaining both as separate concerns is safer than forcing one set to serve both purposes.

There is a likelihood that your developers are working from a more tokenized set of semantic styles in code, whereas the design team may need less abstract styles for the ideation process. This delta can be tricky to navigate from a Figma perspective because we may end up in a world where we’re maintaining two or more sources of truth.

The recommended approach is to split quick, ideation-focused styles from semantic variables into separate sets. Apply semantic styles at the component level; reserve raw styles for exploring new ideas. For example, Brand/Primary may be the muscle-memory choice for the border color of an active menu item during design. Inside the component itself, alias that token to something semantic like border-active.

Note: Some teams push naming to a component-specific level, e.g. header-nav-item-active. That hyper-specificity is an optional step. It constrains reuse and adds maintenance burden, so weigh the cost before introducing another token layer.

An illustration that explains how the bottom border for a header link should be named. On the left, you see a component ‘Header link,’ the bottom border is highlighted, and there are three arrows going to the right into three separate boxes: ‘Style: quick reference,’ ‘Variable: production,’ and ‘Variable: component (optional).’
How should we name the bottom border for a header link? A quick reference style, a production variable, or a component variable? (Large preview)

When a new idea matures — say, tabs in a settings page where the active tab border was built with Brand/Primary — the contributed component gets remapped to the correct semantic token, border-active.

An illustration that explains if we should support styles for ideation and variables for production components within the design systems. The two design stages are the ideation stage (using a style) and the production stage (using a variable).
Can we support styles for ideation, and variables for production components within our systems? (Large preview)

This split is most valuable for large design teams with lengthy contribution processes or fixed release cycles. For most teams, a single semantic set is sufficient. Variables simplify management by centralizing token properties, but that's a topic for another article.

Community-Building

A design system only succeeds when product, design, and engineering teams are advocates — excited by the system, not burdened by it. That requires building an internal community of champions who act as extensions of the central team. Many designers want to contribute to systems; the prevalence of local components that duplicate existing ones is often a sign of that desire, not neglect. The goal is to channel that energy through an open contribution model.

The “hub and spoke” model addresses the fundamental scaling limit of a central team: it cannot directly support every demand of an enterprise. Empowering business units and product teams to support themselves is the only way past that bottleneck. A community can be as lightweight as a design system Slack channel or as structured as fortnightly learning sessions. The point is to make discussion and shared knowledge central to the system rather than an afterthought.

Zalando's design system community demonstrates the model well, with a web portal, regular educational meetings, and an open-house culture. Aside from the custom portal, most teams can reach that target. A simple open monthly meeting or office hours, run by the system's owners and open to all cross-functional partners, is a solid starting point. The Gov UK team offers another example, running events from accessibility deep dives to full “design system days.”

Transparency keeps the system close to its users. It shifts the perception from a siloed design artifact to a resource that feeds every part of the production pipeline.

Advocacy follows naturally from visible, regular communication. Identify the product manager who pores over documentation, or the developer who always catches spacing token misuse, and position them as stewards of quality in their own areas. Tooling like Design Lint, a Figma plugin, can support these efforts: it scans selected layers for missing styles, and custom lint rules can flag misused color styles, unpublished components, missing descriptions, and more. A network of such advocates across departments is the practical guarantee of consistency.

(Over)Communication

Regular, informative updates keep the system present and relevant. Communication types to cycle through include:

  • Changelog and release notes.
  • Upcoming work and roadmap.
  • Survey results.
  • Resource sharing.
  • Hiring updates.
  • Small wins.

A steady rhythm builds the sharing habit and lends weight to the updates. Decide whether updates look forward or backward — the start or end of a sprint — and set a pattern:

  • Changelog/release notes go out on the final day of each sprint.
  • “What's next?” opens the sprint.
  • Helpful resources land mid-sprint as inspiration between focus blocks.
  • Small wins are shared quarterly.
  • Survey results are shared at the start of every second quarter.
  • Hiring updates go out as they arise.
An illustration that shows what a sprint-long plan would look like for a design systems team’s community. Sprint days 1-10 are displayed on a timeline. At 1) there is ‘What’s next?’, at 5) there is ‘Resource sharing’, and at 10) there is ‘Changelog’.
What would a sprint-long plan look like for a design systems team’s community? (Large preview)

Communication, more than any component API or token structure, determines whether a system thrives. Leading with it ensures the design system is doing everything it can for the people it serves.

Discoverability Starts With Communication

No matter how polished a component library is, it fails if the people who need it can't find what they're looking for. Teams working in "ship at all costs" mode will routinely bypass a design system — not out of malice, but because they don't know what exists, what things are called, or how a component maps to code. The system is being built in a vacuum, and the product work moves on without it.

Education and communication are the levers here. That's why Design Ops roles are gaining traction in larger organizations: they exist to build and maintain channels between design, product, and engineering. On a practical level, this can be as simple as a dedicated messaging channel for component work. The maintainers post frequent updates with full context:

  • What is being worked on right now?
  • What updates should land in the next day, week, or month?
  • Who owns which component?
  • How can the wider team contribute?
  • Are there blockers?

Running this conversation in a public forum builds understanding around the system, which in turn drives adoption of what's being shipped and when.

The tools themselves also offer opportunities for over-communication. In Figma, version history can be used with intentional, timestamped notes that spell out exactly what changed, when, and by whom — effectively turning that panel into mini-documentation that even collaborators without a paid license can read. For teams using a branch-based workflow, branch descriptions serve the same purpose. A note of caution for large organizations: reserve branches for small fixes and updates, and create new files for major releases. That way, one group of designers can work on v1 while others move to v2.

Naming For Usage, Not For Abstraction

Naming is the hardest part of design system work. One person's dropdown is another's select and someone else's option list. With so much vocabulary in play, alignment across a team is genuinely difficult.

Prioritizing discoverability over complexity helps. In practice, that means embracing verbosity rather than concision. Consider a generic rounded card with an inner list of icons. Called in isolation, you might call it a dropdown, a popover, or an action list. But add context — it sits on a search filter and offers the user actions like importing a predefined query, exporting the current one, or sharing it — and the right name becomes something like search actions.

That specificity is a feature, not a bug. A system matures through real usage, and decisions about scalability should happen when a component is actually needed in multiple places — not before it has any usage at all. Naming a component for its concrete job makes it findable by the people who need it today.

Optimize For The Consumer, Not The Creator

We tend to build design systems for ourselves — the maintainers — rather than for the people consuming them. That's a problem, because consumers vastly outnumber maintainers and are far removed from the reasoning behind a component's structure or name.

Figma makes it almost too easy to build complexity into components. Component properties can multiply until the properties panel turns into "prop soup," and the Assets panel becomes a maze of near-identical variants. A usable system optimizes for speed of discovery and efficient implementation. That goal sometimes means accepting repetition, which runs against the grain of a strict don't repeat yourself philosophy. But a confused designer is slow. A compact, descriptive, and lightweight component is fast.

Consider a button component with four intentions (primary, secondary, error, warning), two types (fill, stroke), three sizes, and four states. Listing those options already reveals the problem. Ask yourself: will a designer ever need to switch a single instance between a primary button and a warning one? Or are those genuinely separate use cases — and therefore separate components?

Splitting that button into four distinct components, one per intention, brings two big wins. The Assets panel becomes easier to navigate because each variant is visually surfaced in its own set. And the designer removes one decision — which type to use — from the usage workflow. The trade-off is losing direct parity with coded components. That's acceptable. Documentation is still where design and development meet, and component permutations can be spelled out there without sacrificing usability inside the design tool itself.

Auto Layout As A Guardrail

Component usability also hinges on the decision to use auto layout. The advice here is to go all in. Auto layout removes the need to eyeball measurements in production designs, and it shifts the spacing burden away from non-design partners. A copywriter can safely edit a line of text inside a component, confident that the surrounding content will reflow rather than break the layout.

Using padding and gap variables within main components further removes the "is this spacing right?" question from composition. Consistency is the goal, and auto layout everywhere pushes the system as far in that direction as possible.

Naming for Precision

Naming conventions are a core part of making components usable at scale. The clearer and more specific a component name is, the more likely it is to be found and applied in the right context. This often feels inefficient at first because it leads to more components in the library. But efficiency is a long-term goal; getting there usually requires accepting some short-term duplication.

Specific naming means calling a header a header, a filter a filter, and a search field a search field. That sounds obvious, but naming is genuinely difficult across teams. The same pattern gets different names depending on the design system you consult:

  • Apple’s Human Interface Guidelines calls it a “search field.”
  • Material Design calls it a “search bar.”
  • Microsoft Fluent 2 has no search field at all; it offers a “combobox” with typeahead search.

There may be legitimate reasons to distinguish a combobox from a search bar, but your designers and developers need to know those nuances without guessing. Specificity removes that guesswork. Instead of bundling combobox and search into one flexible component with toggleable settings, split them into separate components. That way, searching for “search” in Figma returns exactly what you need, rather than forcing someone to evaluate whether a generic combobox can be adapted for the job.

An illustration that shows how a single component is then split into two separate components: one of the components is labeled ‘Search’ and the other one ‘Combobox’.
A single search variant component split into two main components, one for each distinct type: Search and Combobox. (Large preview)

Design Systems That Earn Their Keep

If you have made it this far, you have absorbed a great deal of advice on building components within Figma. The real reward for following the principles outlined previously is a system that has a much higher likelihood of actual adoption. For design systems teams, adoption is typically the central goal, and a focus on reducing complexity is the most reliable way to get there. Doing so not only improves the quality of the components but also strengthens the case for continued investment and makes collaboration with team members more productive.

As maintainers, it helps to remember that the work is not just about the files themselves but about the workflow you foster. A system that is easier to consume encourages more feedback, which in turn refines the system further. If you have questions about implementing any of these approaches, the author is available to respond in the comments of the original article.

Key Resources and Further Reading

To continue refining your approach, the following articles, talks, and tools cover component architecture, collaboration, and process strategy.

Guides, Talks, and Documentation

Token, Layout, and Style Guides

Implementation and Tooling

Reference Material on Search Patterns

Process-Focused Reads on Smashing Magazine and Beyond

Smashing Editorial