Topic 9 — Design systems and Figma

Goal: Learn the industry tool and how teams keep design consistent at scale.

Lesson 9.1 — The tool the job runs on

Tessa's recruiter call lasted four minutes. Friendly, encouraging, and then: "And you're comfortable in Figma, right?" She said yes, hung up, and immediately googled how to download it. After eight years arranging retail floors by hand, the idea that her whole craft now lived inside one piece of software felt strange. By the end of that first evening, she'd drawn a rectangle, typed her name into it, and shared a link with her sister. The strangeness was already wearing off.

Figma is the design tool the industry runs on, and being comfortable in it is close to required for the job. The reassuring part is everything about how it lets you start. It's free to begin, it runs in a web browser with nothing to install, and it was built for people who aren't engineers. You can learn the basics in a single day and keep growing for years.

The free Starter plan is enough to learn on and build a portfolio with: unlimited drafts, up to three files in a shared project, real components, and the core canvas. (Drafts are your private sketch space and don't count against that three-file limit — so you're never short on room to practice.) Teams pay later for things like shared libraries across many files and the fuller engineer handoff mode. None of that gatekeeps the learning.

You don't have to be technical to use Figma. That's the whole reason it won.

When Tessa walked into Wanderwell, the 40-person travel startup where she'd landed her first design role, every screen of the app she'd be working on already lived in Figma. So did the comments, the version history, and the conversations between designers and engineers. The tool wasn't a side detail of the job. It was the workshop.

Lesson 9.2 — What to actually learn (not every button)

Tessa's first instinct was to learn all of Figma. She opened a tutorial playlist with sixty videos and felt her stomach sink. Marcus Bell, the lead product designer who'd be mentoring her, saw the panic on her screen-share and laughed.

"Nobody knows all of it," he told her. "You need four things and one habit."

Here's the short list Marcus gave her. It covers the vast majority of real work:

• Frames — the containers that hold a design. A frame is a screen: a phone screen, a web page, a single card. You drop everything else inside frames. Think of them as the artboards your work lives on.
• Basic shapes and text — rectangles, circles, lines, and text. Surprisingly, most of any interface is rectangles with rounded corners and well-set type. The visual fundamentals from Topic 8 do the heavy lifting here.
• Components — reusable elements (the next lesson is entirely about these, because they change everything).
• Prototyping links — drawing arrows between frames so a flat design becomes clickable and testable, exactly the prototype idea from Topic 6, no code required.

And the one habit: real-time collaboration. Multiple people can be in the same file at once, cursors moving live, leaving comments pinned right on the pixel they're talking about. When Priya Anand, Tessa's product manager, wanted to question a button's wording, she didn't send an email. She dropped a comment on the button. When Hannah Reyes finished a usability study, she left her findings as notes beside the screens they affected.

That live, everyone-in-one-file way of working is the feature that made Figma spread through the industry. Master those four things and that one habit, and you can do almost any junior task in front of you. The other fifty videos can wait.

Lesson 9.3 — Components, Figma's superpower

In her second week, Tessa hand-drew the same "Book now" button on eleven different screens. Eleven rounded rectangles, eleven labels, all styled by eye. Marcus reviewed it and asked one quiet question: "What happens when we change the brand orange?"

She did the math out loud and went pale. Eleven edits. And that was eleven screens. The real app had over two hundred.

That's the problem the component solves, and it's Figma's single most important feature. A component is a reusable element you design once and use everywhere. You build the button one time, turn it into a component, and every copy you place is an instance linked back to the main component (the master). Change the master, and every instance updates at once.

Marcus rebuilt her button as a component and changed the brand orange in one place. All eleven buttons turned, instantly, together. Tessa actually said "oh" out loud.

A component is "design once, use everywhere." Edit the master, and every copy follows.

If that instinct sounds familiar to an engineer, it should. It's the design version of "don't repeat yourself" — define a thing in one place so you never have to fix it in a hundred. Dev Okonkwo, the frontend engineer who builds Tessa's designs, lit up when he saw she'd componentized her work, because his code mirrors the same idea: one Button he reuses, not two hundred copy-pasted ones.

Components matter because real products are big. Hundreds of screens, sometimes thousands of elements. Keeping all of that consistent by hand goes past tedious into impossible. It quietly drifts out of sync the moment you try. Learning to think in reusable components is one of the clearest steps from beginner to professional. It's the difference between drawing eleven buttons and building one.

Lesson 9.4 — Design systems: the shared kit

A component fixes consistency inside Tessa's own file. But Wanderwell has several designers, dozens of files, and one app that has to feel like a single product no matter who touched which screen. What keeps Tessa's work and Marcus's work and the next hire's work all looking like the same app?

A design system. It's the level up from components: a shared library of reusable parts plus the rules for using them, that an entire team designs from. At Wanderwell, Marcus owns it. A real design system usually has three pieces:

• A component library — the ready-made parts everyone pulls from: buttons, form fields, cards, menus, navigation bars. Tessa doesn't redraw a text field; she grabs the official one.
• Style definitions — the official colors, fonts, and spacing values. The exact Wanderwell orange, the exact body-text font, the spacing steps. These are often called design tokens (the next lesson).
• Guidelines — the rules for when and how to use each piece. Which button is the primary one, how much breathing room a card needs, what the error state looks like.

The payoff is consistency and speed at scale. Every designer assembles new screens from the same trusted kit, so the product feels unified, and a fresh screen comes together in an afternoon instead of a week because half the parts already exist.

The most famous example is Google's Material Design — a public design system used across Google's products and far beyond, with its components and tokens documented for anyone to follow. Big companies (Apple, Atlassian, Shopify, and many more) ship their own. As a new designer, you'll almost always use and contribute to an existing design system rather than invent one from nothing. In year one, Tessa won't build Wanderwell's system. Her job is to design fluently with it, and occasionally add a well-made part back into it.

Lesson 9.5 — Design tokens, the bridge to code

Tessa kept hearing one word in standups and nodding like she understood it: tokens. Finally she asked Marcus, who pulled up the design system and pointed at a color swatch. It wasn't labeled #F26B21. It was labeled color-primary.

That name is the design token. A design token is a named, reusable value that stands in for a raw design decision. Instead of the hex code #F26B21, the system says color-primary. Instead of "16 pixels of space," it says spacing-8. Common tokens cover color, spacing, and type.

The power is in the name. Because every primary button across the whole product points at color-primary rather than a hardcoded orange, rebranding to a new orange means changing one token value and watching the entire product update in step. No hunting through two hundred screens.

Here's the part that makes tokens matter beyond the design file. Dev's code uses the same token names. When Marcus's design says color-primary and Dev's button reads color-primary, design and code are speaking one shared language. The designer's palette and the engineer's build stay in sync because they reference the same named values.

Tokens are the bridge between the designer's palette and the engineer's code — one name, both worlds.

That bridge leads straight to handoff. When Tessa's design is ready, Dev opens it in Figma's developer view and inspects it: the exact pixel sizes, the exact colors, the exact spacing, often shown with the token names attached. He reads the specs straight off the screen instead of guessing or pinging her every five minutes. Good components and clean tokens make that handoff smooth, which is why engineers quietly love designers who work this way. It's the moment Tessa's design stops being a picture and starts becoming a product.

Worked example — Wanderwell changes its orange

Wanderwell's brand team picks a new, slightly warmer orange. In the old, by-hand world this would have been a multi-week slog. Watch how the system handles it instead.

Marcus opens the design system and changes one value: the token color-primary, from the old hex to the new one. That's the entire design-side edit. One field.

Every component that references color-primary — the primary button, the active tab, the selected date in the calendar — updates instantly across the library. Because Tessa built her booking screens from those library components rather than redrawing them, all of her work turns the new orange the moment she pulls the update. Eleven buttons, fifty screens, no manual fixes.

Priya, the PM, checks the prototype, clicks through the booking flow live in the same file, and confirms the new color reads well at every step. Hannah notes it looks fine against the photo backgrounds from her last study. All of this happens in one Figma file, comments and all.

Then handoff. Dev opens the developer view, sees that color-primary changed, updates the single matching token in his codebase, and the live app turns the new orange too. Design and code, in sync, because they pointed at the same name the whole time.

One token. One edit. A whole product re-skinned. That's what "consistent and fast to change at scale" actually means in practice — and it's the entire reason components, systems, and tokens exist.