Building a Component Library

Components Are Products Too

A component library is a collection of reusable UI pieces. Each one needs to work in every situation it will meet: long text, no text, tiny screens, slow networks, keyboard users, screen readers. Treat each component as a small product with its own requirements.

---

Anatomy: Breaking a Component Into Parts

Before you design a component, define its anatomy: the named parts it is made of. Everyone can then talk about it precisely.

Button anatomy

1. Container: the background shape
2. Label: the text
3. Leading icon (optional): before the label
4. Trailing icon (optional): after the label, for example a chevron
5. Focus ring: the visible outline when navigated by keyboard

Input anatomy

1. Label
2. Container / field
3. Placeholder or value text
4. Leading icon or prefix (such as ₦ or +234)
5. Helper text or error message
6. Trailing action (clear, show password)

Card anatomy

1. Container
2. Media (image or illustration)
3. Header (title and subtitle)
4. Body
5. Actions

---

Variants, Sizes and States

Variants: different purposes

• Primary: the main action on a screen. Use one per screen.
• Secondary: alternative actions
• Tertiary / ghost / text: low-emphasis actions
• Destructive: delete, cancel subscription, remove beneficiary

Sizes

Small, medium and large, all on the 8pt grid (for example 32, 40 and 48px tall). On mobile, make sure the tappable area is at least 44 to 48px even for small buttons.

States: how it responds

• Default
• Hover (desktop)
• Pressed / active
• Focus (keyboard): never remove the focus ring
• Disabled: explain why somewhere, if you can
• Loading: a spinner, and the button stays the same width to avoid layout jumps
• Error (inputs): red border plus icon plus message

Forgetting states is the most common reason designs and built products drift apart. If a state is not designed, an engineer will invent it.

---

Naming Conventions

Good names make a library searchable and predictable. A common pattern in Figma is:

Component / Variant / Size / State e.g. Button / Primary / Medium / Hover

Guidelines:

• Name by purpose, not appearance: Button/Destructive, not Button/Red. If the brand colour changes, the name still makes sense.
• Use the same names in design and code. If Figma says Secondary, React should say variant="secondary", not outline.
• Keep property names consistent across components: Size = sm / md / lg everywhere.

Figma's component properties (variant, boolean, text and instance swap) let one component set cover dozens of combinations without hundreds of separate layers.

---

Building It in Figma

1. Design the base component with auto layout so it resizes with content.
2. Apply tokens (colour and text styles or variables), never raw hex values.
3. Create variants and combine them into a component set.
4. Add boolean properties for optional parts, like "Show leading icon".
5. Test extreme content: "Pay ₦1,250,000.00 to Oluwaseun Adebayo-Williams" should not break the button.
6. Document usage: when to use it, when not to, and accessibility notes.

---

Try It in the Lab

The component anatomy explorer lets you pick a button, input or card. Hover over the numbered parts to see each piece highlighted, switch variants, sizes and states, and see the generated Figma-style name and React props. Try the long text toggle to stress-test the component.