Chapter 10 — Component Thinking | The Designer Who Codes

Final chapter — Bonus

This one changes how you see every product you've ever used

After this chapter, you'll never look at a UI the same way again. You'll see components everywhere — and you'll design with that awareness, which makes you a dramatically better collaborator with any engineering team.

Think in systems, not screens

Most designers think in screens. "This is the profile screen. This is the settings screen. This is the checkout screen." It's a natural way to think — you're designing what users see.

Developers think in components. They don't build a "profile screen" — they assemble a nav bar component, a user avatar component, a settings card component, and a button component. The screen is just a composition of reusable pieces.

This difference in perspective creates friction. Designers hand off screens; developers think in components. When those two ways of seeing the same product aren't aligned, you get miscommunication, rework, and inconsistency.

The designer who understands components — who designs and thinks in systems, not just screens — eliminates that friction. They become the bridge between design and engineering. And that person is extraordinarily valuable.

What is a component?

A component is a self-contained, reusable piece of UI. It's a thing — not a screen. It has three parts:

Structure (HTML) — what it's made of: a button has a label and maybe an icon. A card has an image, a title, a description, and a CTA.
Style (CSS) — what it looks like: colors, spacing, typography, border radius, hover effects.
Properties (props) — what can change between instances. A button's label can change. Its variant (primary, secondary) can change. Its state (loading, disabled) can change. But the structure stays the same.

Examples of components in any mature product: Button, Input, Card, Badge, Avatar, Modal, Toast notification, Dropdown menu, Tooltip, Tab bar, Navigation bar, Data table, Progress bar.

Look at any real product and you'll see the same components repeating across dozens of screens. That repetition is intentional — it's what makes a product feel consistent, and it's what makes it efficient to build.

Props — what makes components flexible

In Figma, you use Variants to show different versions of a component — a button that's Primary, or Secondary, or Ghost. In code, these are called props (short for "properties") — values you pass to the component that change how it looks or behaves.

A Button component might have props like:

Button props:
  variant:  "primary" | "secondary" | "ghost" | "danger"
  size:     "small" | "medium" | "large"
  state:    "default" | "loading" | "disabled"
  label:    string (the button text)
  icon:     icon name or null (optional icon)
  onClick:  function (what happens when clicked)

// Used like:
<Button variant="primary" size="medium" label="Get Started" />
<Button variant="ghost" size="small" label="Cancel" />
<Button variant="primary" state="loading" label="Saving..." />

See how this mirrors Figma variants? In Figma, you'd create a Button component with a Variant property called "variant" (Primary, Secondary, Ghost, Danger) and another called "size" (Small, Medium, Large). The goal: your Figma component structure should match the code component structure exactly.

When they match, the handoff is almost automated. The developer looks at your Figma variants, knows exactly what props to build, and implements them. No back-and-forth, no guessing.

Atomic design — a vocabulary for systems

Atomic Design (coined by designer Brad Frost) is a mental model for building UIs from small, reusable pieces up to full pages. It has five levels:

Atoms — the smallest indivisible UI elements. A Button. An Input field. A Label. A Color swatch. An Icon. These are the raw materials.
Molecules — atoms combined into a simple functional unit. A Search Bar is a molecule: Input atom + Button atom + Icon atom. A Form Field is a molecule: Label atom + Input atom + Error message atom.
Organisms — molecules combined into a larger section. A Navigation Bar is an organism: Logo + Nav links (each a molecule) + Search Bar + Avatar. A Product Card is an organism: Image + Tag + Title + Description + Price + CTA Button.
Templates — the layout of a page, using real components but with placeholder content. The wireframe of how organisms arrange on a screen.
Pages — templates with real content. The final, specific instance of a design — the thing you see in production.

You don't need to follow Atomic Design religiously. But the underlying idea — that big things are made of smaller, reusable, named things — is one of the most powerful mental models in product design. Internalize it and it changes how you design every system, every Figma file, every handoff.

Building a component in HTML + CSS

Let's build a real, well-structured component together. A content card — the kind you see on every blog, dashboard, and marketplace.

<article class="card">
  <div class="card__image">
    <img src="cover.jpg" alt="Abstract geometric pattern">
    <span class="card__tag">Design Systems</span>
  </div>
  <div class="card__body">
    <h3 class="card__title">How to build a design system that devs love</h3>
    <p class="card__description">
      A practical guide to tokens, components, and the conversations
      that make handoffs actually work.
    </p>
    <footer class="card__footer">
      <span class="card__author">Rohan Boda</span>
      <span class="card__reading-time">8 min read</span>
    </footer>
  </div>
</article>

.card {
  background: #111111;
  border: 1px solid #222222;
  border-radius: 12px;
  overflow: hidden;           /* Image doesn't spill outside rounded corners */
  transition: transform 0.2s ease, border-color 0.2s ease;
  cursor: pointer;
}

.card:hover {
  transform: translateY(-3px);
  border-color: #f5e642;
}

.card__image {
  position: relative;         /* So the tag can be positioned over the image */
}

.card__image img {
  width: 100%;
  aspect-ratio: 16/9;        /* Forces a consistent image ratio */
  object-fit: cover;          /* Image fills its space without distorting */
}

.card__tag {
  position: absolute;
  top: 12px;
  left: 12px;
  background: #f5e642;
  color: #0a0a0a;
  font-size: 11px;
  font-weight: 700;
  text-transform: uppercase;
  letter-spacing: 0.08em;
  padding: 4px 10px;
  border-radius: 4px;
}

.card__body {
  padding: 20px;
}

.card__title {
  font-size: 18px;
  font-weight: 700;
  color: #f0f0f0;
  line-height: 1.3;
  margin-bottom: 8px;
}

.card__description {
  font-size: 14px;
  color: #888888;
  line-height: 1.65;
  margin-bottom: 16px;
}

.card__footer {
  display: flex;
  justify-content: space-between;
  align-items: center;
  font-size: 12px;
  color: #555555;
  font-weight: 500;
}

Notice the naming pattern: every class starts with card — this is called BEM (Block Element Modifier) naming. card is the block. card__title is an element inside the card. card--featured would be a modifier (a variant). BEM keeps your CSS organized and prevents class name collisions in large projects. You don't need to follow it strictly, but namespacing by component is a great habit.

Component thinking in your Figma files

For every component you design in Figma, ask these questions before you hand it off:

What are the variants/props? What changes between instances — label, icon, size, color, state?
What are all the states? Default, hover, active, focused, disabled, loading, error, success — have you designed all of them?
What content can change? What are the minimum and maximum lengths for text? Can the icon be removed? What happens with very long or very short content?
Where does this appear in the product? If it's used in 20 places, it should be a component. If it's used once, it might not need to be.

🎯 The collaboration unlock

When your Figma variants match code props, magic happens

The moment a developer opens your Figma file and sees that your component variants exactly match how they think about building it — the same names, the same variations, the same states — they trust you immediately. You've shown them you understand their world. That trust is worth more than any design tool or plugin. It's built one well-structured component at a time.

You need: Chrome browser VS Code GitHub (to publish your result)

1

Open a product you use regularly — Linear, Notion, Airbnb, Duolingo, Stripe. Spend 10 minutes looking for components. Make a list of at least 8 components you can identify (Button, Card, Badge, Avatar, Input, Tag, Tooltip, Nav item, etc.).
2

For each component, note its "props" — what changes between instances? A Badge might have: color (green/red/grey/yellow) and label (text). An Avatar might have: size (small/medium/large) and image (photo or initials fallback).
3

Pick one component — start with something small, like a Badge or a Tag. Build it in HTML and CSS. Try to make it work for at least 2 variants (e.g., green "Active" badge and red "Inactive" badge). Use class names that follow the BEM pattern: .badge, .badge--active, .badge--inactive.
4

Put the file in a GitHub repo (using what you learned in Chapter 05). Share the GitHub Pages URL. You just built and shipped a real UI component.
5

The challenge: Build one more component from your list. Then ask Claude: "I've built a Badge component in HTML/CSS. How would I build this as a reusable React component with props for color and label?" Read Claude's answer — you don't need to implement it, just understand the direction it's pointing.

✦ Own your code

Can you explain every line?

Before moving on: pick any 5 lines from the code above and say out loud what each one does. Not the general idea — the specific line. If Claude ever gives you code like this, hold it to this standard before you use it. If you cannot explain a line, you cannot debug it.

Key takeaways

Think in components, not screens — developers build products by assembling reusable pieces
A component has structure (HTML), style (CSS), and props (what changes between instances)
In Figma, your Variants = code component props — design them to match intentionally
Atomic Design: atoms → molecules → organisms → templates → pages — big things are made of small, reusable things
Design every state for every component: default, hover, loading, disabled, error, empty
When your Figma thinking aligns with how developers think, collaboration becomes frictionless

🎉 You finished the course

Now go build something real

The most valuable thing you can do after this course is build something and ship it. Start small — a personal portfolio page, a case study page, a landing page for a side project. Use Claude to write the code. Use Figma to design it first. Use GitHub Pages to host it. Share the URL. The act of shipping something real, even something imperfect, teaches you more than any course — including this one. You have everything you need. Go build.