The Anatomy of BBUI Components

From the very beginning, the plan with BBUI was to keep it lightweight. Not lightweight in terms of editorial options, but lightweight in noise, while still being powerful under the hood. With this baseline in mind, it made sense to optimise components in the most Figma-friendly way possible.

As a reference point, ShadCN documentation quickly became the go-to. Their component structure, fully layered and nested, translated well to Figma. Replicating that structure on the design side felt like the most natural starting point.

The markup

Having ShadCN as input for markup decisions, we decided to follow the same structural approach in BBUI. Components are not treated as single blocks. Instead, they’re composed of smaller, purpose-driven parts that mirror how the component is built in code.

For example, a Alert dialog component is broken down into:

A dialog wrapper:

• A header section with individual controls
• A content section with individual controls
• A footer with nested button components that designers can interact with

Each of these elements exists as its own layer or nested component, rather than being flattened into a single frame. From a visual perspective, this all resolves into one dialog. Structurally, however, every part has a clear responsibility.

This makes it possible to control layout, spacing, alignment, and behaviour at the right level, without duplicating the entire component for small changes.

Why components are layered this way

Building components in this layered manner allows us to reduce the number of variants needed in Figma while still keeping flexibility high.

For example, spacing or alignment changes can be handled at the container level instead of requiring a new component variant. Components get adapted around the use case, rather than forcing the use case to fit the component.

More importantly, this keeps the design structure aligned with how the component is actually implemented.

Structure as data

When AI tools read design files directly from Figma, they don’t see a “dialog UI”. They see a hierarchy of named layers, nested components, and associated metadata.

In the Alert Dialog example, an AI can clearly distinguish:

• Structural containers
• Content areas
• Interactive elements
• Reusable components like buttons and icons

Because the anatomy mirrors real component markup, the design file becomes usable data, not just a visual reference.

Summary

BBUI relies heavily on nested components to enable better customization with fewer variants. This results in faster updates, a more organised library, and easier adaptation for project-specific needs.

As modern tooling and AI workflows increasingly rely on reading real design context, having component anatomy in Figma match the developed structure becomes more important. When layers are named and structured correctly, AI tools can reason about the design far more accurately and produce results that stay true to the original intent.