In Search of a Better Taxonomy for a Design System

2025-12-05 | 4 min reading

Have you ever felt confused while adding an element to a design system?

Design systems play a key role in communication and consistency but they can be difficult to manage without a clear taxonomy.

For this reason, aim of this article is to explore some use cases and variations as a reference.

But why is the taxonomy so crucial?

You can think of taxonomy as a fancy word for category or grouping.
Having this grouping right creates hierarchical order, like an onion with its layers.

And when you understand these layers bottom to top, you can better structure your codebase and plan ahead for what’s to come.

That can make all the difference in the world when you’re rushing to scale a project.

The Dimensions

We’ll start by introducing the criteria we’ll use as metrics.
Think of them as the names of our onion’s layers.

Browser: Grouping based on the HTML element types.
Implementation: Grouping based on how we code an item.
E.g., does it rely on specific syntax, patterns, or code properties?
Functionality: Grouping based on the functionality of an item.
E.g., does it enable navigation? Highlighting content?

Browser

This is the core of our onion, the most basic form of categorisation based on the browser itself.

Here, we consider only the native HTML elements the browser provides.

As a start, it should suffice to have two categories: content and forms.

Content includes all the elements that present information, while forms include all the elements for data acquisition.

In case you may want to dive further, refer to the HTML Content categories in MDN.

Many minimal CSS Frameworks like, Milligram, sakura, and Simple.css lives here.

Content: Presents information.
Form: Data acquisition (or related to).

Browser examples

  + content

      - headers
      - paragraphs
      - list
          - ol
          - ul
          - dl
      - article
      - address
      - blockquote
      - images
      - table
      - links

  + form
  
      - input
          - text
          - number
          - checkbox
          - switch
          - radios
          - range
      - time picker
      - date picker
      - select
      - labels
      - button

Implementation

This is the second layer, it relates to the libraries and framework in use and how things are coded.

Is it a single component? Is it a collection of components? Or, is it a whole page?

For anyone with experience in React, Angular, or Vue, this usually came as a natural first extension on top of the browser category.

Component: Anything that is implemented as component.
Collection / Composite: Anything that aggregates items.
Page / Views / Screen: Anything that do represents a page on a browser or screen in an app.

Implementation

  + component                
  
  + collection | composite
    
      - list
      - tables
      - tag group
      - button group
      - tree view

  + page | views | screen
      
      - article                    
      - dashboards                    
      - product list                    
      - product item

Functionality

As the solution grows, clusters will emerge unlocking new groupings.

Perhaps some new groups won’t be immediately self-evident but with time new elements will get in easing the task.

For this reason, it helps to look at the elements by the type of information they present and by the function the element enables.

What does this element help to achieve? Without this particular element, would you be able to achieve a specific action? Does it have a particular shape? Or does it shape the content?

Token: Items used globally across the system for communication.
Layout: Items that spatially shape content.
Navigation: Items that allow a user to go somewhere.
Status / Notification: Items that communicate a progress or a state.
Overlays: Items that float over the main content.
Charts: Display data visually.
Domain specific content: Specific content related to the business.
E.g., a product for an e-commerce, or an apartment for a rental.

Functionality examples

  + token
   
      - icons
      - color
      - font
      - spacing
      - animation

  + layout
    
      - container
          - columns | rows | grid
      - card
      - accordion
      - tab
      - reveal
    
  + navigation
    
      - navbar
      - sidebar
      - breadcrumbs
      - pagination
      - links
      - link tiles

  + status | notification
    
      - badge
      - alert
      - progress bar
      - progress circle
      - toast

  + charts

  + domain specific content 
    
      - products
      - appartment
      - flights
      - car
      - articles

  + overlays

      - modals
      - drawers
      - tooltips
      - contextual menu

Among all the elements, domain specific content deserves a couple of extra words.

There may be cases, let’s say an e-commerce, or a rental properties in which a piece of content has multiple shapes.

Usually, it’s a piece of content core to the business in question.

For example, in an e-commerce, the core content is the product to sell.

As such, you may have a product tile for the home page, a product card for the search page, and a product block for the item page.

Same in a rental property website for a property.
You see how it goes.

You have this core content so important that has several variations and at that point make sense to group them.

Lifecycle of a taxonomy and the concept of gravity

As mentioned, during the lifetime of your project, your taxonomy will evolve.

Now, at some point, some of your categories may start to get more weight and attract some items that may have multiple possible interpretations.

For example, let’s take a Toast component.

You may decide something like:

Components > Notifications > Toast  <~  by functionality
Components > Overlays > Toast       <~  by implementation

In which category Toast should be? Well, depends.
Do you have any other items in Notification or Overlay? Do you have any other component to start a new category?

What i want to say with this is that despite theoretically the categories we have in our taxonomy should be mutually exclusive (e.g., if an element belongs to category A it shouldn’t fit in category B), in practice i saw many edge cases and i believe you’ll see too.

When it happens, don’t stress out too much; it’s just the way it is.
With time, the system will gain more elements and some categories will stand out.

Just trust the process, endure the discomfort, and plan a periodical review.

Summary

A good taxonomy helps you predict how the code base might grow, spotting possible pitfalls, and it can be a lifesaver during rough times.

As such, we looked at three main possibles metrics as inspiration: the browser, implementation and functionality with some variations and examples.

If you are interested in the topic, i would recommend checking Storybook Showcases, Adobe Spectrum, or if you need an extra level with Storybook check Storybook Sidebar Roots Grouping.