DSN 326 Micro Lectures

It's tempting to jump straight into designing components. But if you don't understand the current state of the UI first, you'll build a system based on assumptions instead of evidence.

The audit is your research phase. It tells you what your startup's UI is doing today — the good, the bad, and the inconsistent.

Screenshot everything. Landing pages, settings screens, modals, empty states. Get the full picture.

Then catalog what you see into three categories: Foundations (colors, type, spacing, icons), Components (buttons, cards, nav), and Patterns (forms, menus, modals).

The goal isn't just to list things. It's to annotate what you notice. Are the buttons consistent? How many shades of gray are they using? Does the typography follow a scale or is it all over the place?

Your audit findings directly inform your design tokens. If you found 6 different blues in the app, your job is to decide: which ones stay, which ones merge, which ones go?

Design tokens are the named values that define your system. Colors, font sizes, spacing units. In Figma they're variables and styles. In code they're CSS custom properties.

Set up a Design Tokens page in Figma this week and translate everything into CSS variables in CodePen. This is the backbone of your entire system.

You're also creating your first real component this week in the general assignment — a button with auto layout, variants, and a boolean property for an icon toggle.

This is practice for Week 3, where you'll build your full component library. Get comfortable with auto layout, variants, and properties in Figma now. They're the tools you'll use every week going forward.

One thing to keep in mind: always use your design tokens when styling components. Don't pick colors by eye. Apply the styles and variables you defined on your tokens page.

This week is dense — revised proposal, UI audit, tokens in Figma, tokens in CodePen. Start early and work through it piece by piece.

The audit and the tokens are the foundation for everything you'll design and code for the rest of the semester. Take your time with them.

When you design a button this week, you're not designing one button. You're designing every button your system will ever need.

That means thinking about types, states, sizes, and edge cases. A primary button, a secondary button, a ghost button, a danger button — each in default, hover, pressed, and disabled states.

This is the shift from UI design to systems design. Every decision should be intentional and documented.

Your buttons need 4 types and 4 states. That's 16 variants. It sounds like a lot, but if your tokens are set up right, most of the work is just swapping color variables.

Before you start designing, map out your matrix. Know what you're building before you open Figma. It keeps you organized and makes sure you don't miss states.

You're also defining your information architecture this week — the structure of your design system site. Think of it as a sitemap: what pages exist and how do they connect?

Your final site needs three pages at minimum: a Homepage, a Component Page, and a Guidelines Page. But the IA is your chance to think bigger about how someone would navigate your system.

Ask yourself: if a developer landed on your site looking for the right button to use, how many clicks would it take them to find it?

This is the week where Figma organization really starts to matter. You're creating enough components that a messy file will slow you down.

Name every layer. Not "Frame 427" — something meaningful. Use auto layout on everything. Organize your pages logically (Tokens, Components, etc.).

Annotate your components: what is it, what's its purpose, when would you use one variant over another. These annotations will become your guidelines later.

A clean Figma file makes the coding phase in Week 4 dramatically easier. A messy one makes it painful.

You're sharing your IA and your components with classmates for peer review this week. Take that seriously. Fresh eyes will catch gaps you've gone blind to.

After this week, you move into code. What you design now is what you'll build. Make it solid.

You've spent a few weeks building components in Figma. Buttons, cards, inputs. They look right in Figma. Now you need to make them real in code.

The number one mistake students make here is treating this like a pixel-matching exercise. It's not. You're translating a system, not copying a picture.

What I want you thinking about this week: how does my Figma file already tell me what my CSS should look like?

In Figma you defined colors, type scales, spacing. Those are your design tokens. In code, those become CSS custom properties (variables).

Before you write a single component, set up your :root variables. Colors, font sizes, spacing units, border radii. All of it.

If you find yourself typing a raw hex code or a magic number like padding: 13px, stop. That value should be a variable that maps back to your Figma tokens.

This is what separates a bunch of styled HTML from an actual design system in code.

Figma Dev Mode shows you the CSS values for any element you click on. Spacing, typography, colors. Use it.

But here's the thing — don't just copy-paste what Dev Mode gives you. It's a reference, not a finished stylesheet. The output won't use your variable names or follow BEM naming.

Your workflow should be: check Dev Mode for values, then write your own CSS using your tokens and your naming conventions.

BEM stands for Block, Element, Modifier. It's a naming convention that keeps your CSS organized as your system grows.

.btn is the block. .btn__icon is an element inside it. .btn--primary is a modifier that changes its appearance.

Think about how your Figma variants map to this. Your button has types (primary, secondary, ghost, danger) and states (default, hover, active, disabled). Those are your modifiers.

Every variant in Figma should have a corresponding class in your CSS. If it doesn't, your code and your design file are out of sync.

When I review your code, I'm looking for: CSS variables that match your Figma tokens, clean BEM naming, semantic HTML, and components that look like they belong to the same system.

If someone swapped out your color variables, the entire system should update. That's the test. That's what makes it a system.

Most design system docs fail because they describe what a component is. "This is a button. It has a label." That's not useful to anyone.

Good documentation answers three questions: When do I use this? How do I use it correctly? And what should I avoid?

Think about who's reading your guidelines page. It's a developer or designer on your team who's trying to make a decision right now. Help them make the right one.

Start with a short overview. One or two sentences. What is this component and what problem does it solve?

Then show examples. Not just a screenshot sitting there — show the component in context. Where does it live in the UI? What content goes inside it?

Include do's and don'ts. "Use the primary button for the single most important action on the page. Don't use it for every button in a form." Specific, practical.

End with code structure. Show the HTML and CSS. Not the full stylesheet, just the relevant pattern so someone can implement it.

You're writing two guidelines pages: one for a foundation (colors, typography, or spacing) and one for a component (buttons, cards, etc.).

Foundation pages are about rules and rationale. Why these colors? What's the type scale? How does the spacing system work? Show the tokens and explain the logic.

Component pages are about usage and behavior. When do I use this variant? What are the states? What are the responsive considerations?

Go look at how Material Design, Carbon, or Fluent UI structure their pages. You don't need to match their scale, but notice how every section answers a question.

You're also designing mockups at 375px and 1440px this week. The point isn't just to make two versions of the same page.

Annotate what changes and why. Does the navigation collapse? Does a multi-column layout stack? Do card sizes change? Those annotations show you're thinking about the system, not just the screen.

Your design system components should be flexible enough to handle both. If they aren't, that's a signal to revisit your component structure.

Your guidelines pages are going to become part of your final site. Put effort into them now and Week 7 gets a lot easier.

If you're stuck, start by opening Material Design's button page and ask yourself: what decisions did they document? Then do the same for yours.

Your presentation brief says you're pitching to a head of design and a head of engineering. That framing is intentional.

These people don't care about your process for the sake of process. They care about what problems your system solves and why they should invest in it.

Your deck has required sections: intro, research, design process, development process, key features, responsive design, reflection, conclusion. That's the skeleton.

But the skeleton isn't the presentation. The presentation is the story that connects those sections. What did you find in your research? How did that shape your decisions? What trade-offs did you make?

A common mistake: slides that say "I made buttons" with a screenshot. That's not a story. "Our audit found 14 inconsistent button styles across the app, so we consolidated to 4 types with clear use cases" — that's a story.

Your slides should be mostly visual. Screenshots of your Figma components. Before-and-after comparisons from your UI audit. Side-by-side of your Figma and your coded version.

Keep text on slides minimal. You're the narrator. The slides are the evidence.

When you get to the demo section, walk through your actual site. Don't just show static screenshots of it — show navigation, show the component page, show the guidelines.

Your presentation draft can have placeholder content. That's fine. But the structure should be solid. I should be able to see the arc of your story even if some slides are incomplete.

Same with your site draft. Homepage, at least one component page, at least one guidelines page. Include notes on what's missing and a clear task list for next week.

Drafts that show intentional planning are always stronger than polished work without direction.

You're one week from the finish line after this. Use Week 6 to get your story and your site into a shape where Week 7 is about polishing, not scrambling.

If you've been keeping up each week, most of your site is already built. Your components are coded, your guidelines pages exist, your presentation has structure.

This week is about pulling it all together, filling gaps, and making it something you're proud to present.

Comprehensive Component Library — Are your components complete with variants and states? Do they match your Figma source?

Consistency and Cohesion — Does everything feel like it belongs to the same system? Same spacing logic, same color usage, same typography.

Scalability and Flexibility — Could someone add a new page or component using your tokens and patterns? Or would they have to guess?

Accessibility — Semantic HTML, sufficient color contrast, meaningful alt text thinking. The basics.

Design Communication — Can someone understand your system just by reading your site? That's what the guidelines and documentation are for.

Figma and code don't match. If your coded button doesn't look like your Figma button, that's a red flag. The whole point is the design file is the source of truth.

Guidelines that describe but don't guide. "This is a card component" isn't a guideline. "Use the card component to display preview content in browse views. Always include an image, title, and one action" — that's a guideline.

Presentation is a recap, not a pitch. Don't walk through the semester chronologically. Lead with the problem, show the solution, explain why it works.

Broken links, missing pages, sloppy HTML. Run your code through the W3C Validator. Check every link. Test at both breakpoints.

Your recorded presentation is 10 minutes. Practice it at least once before you hit record. Know your transitions. Have your demo ready.

This project is portfolio-worthy work if you give it the polish it deserves. Future you will appreciate the effort.