DSN 325 · UI Design & Design Systems · Week 1 of 7

Understanding Quality in Design

Fundamentals, judgment, and your first move on the Warren Incubator RFP.

You don't build anything this week. You learn to look at an interface and say, with the right words, why it works or why it doesn't. Every skill in this course sits on top of that one.

This week at a glance

Fri 11:59 pmStudio A: Teardown — one excellent screen, one AI-generated screen
Fri 11:59 pmStudio B: RFP Proposal — one page: problem, audience, constraints, quality bar
Fri 11:59 pmDiscussion: Share thread — post both, defend your quality bar
Fri 11:59 pmField Work: Type & Color Swipe File — post your five finds
Sun 11:59 pmReplies: discussion (2 classmates) and Field Work (1 classmate)

1The vocabulary

Design has a working vocabulary. When a screen feels wrong, one of these words usually names the reason. Each term below comes with a do and a don't — abstract on purpose, so you learn the principle, not one app's style.

Hierarchy

What the eye sees first, second, third. Controlled with size, weight, color, and position. If everything is loud, nothing is.

Do — one clear order
Don't — everything equally loud
Contrast

The difference between an element and what's behind it. It creates emphasis, and it decides whether people can read your text at all.

Do — text you can read
Don't — refined-looking, unreadable
Alignment

Elements sharing an edge or a center line. Broken alignment reads as sloppy before the viewer can say why.

Do — one shared edge
Don't — edges that almost line up
Proximity

Things that belong together sit together. The Gestalt principle you'll spot everywhere once you know its name.

Do — label hugs its field
Don't — which label owns which field?
Spacing

The empty room around elements. Good interfaces space things in a repeating rhythm. Cramped or random spacing is the fastest tell of weak craft.

Do — one rhythm, repeated
Don't — 4px here, 22px there
Consistency

The same thing looking and behaving the same way everywhere. This is the seed of design systems — section 3 explains what those are and why this course is built on one.

Do — one button, everywhere
Don't — three products in one

Where these come from: Nielsen's usability heuristics, Gestalt psychology, and a century of typography practice. Section 7 lists where to go deeper — start with the starred readings.

2The bar: excellence, clarity, consistency

Every piece of work in this course gets held to the same three-word standard. Here's what each word means in practice.

Excellence

The details hold up under inspection. Spacing is deliberate. Nothing is almost-aligned. The work survives a zoom-in.

Clarity

A person who has never seen the screen knows what it is and what to do within seconds. No decoding required.

Consistency

Decisions repeat. Same button, same behavior, same spacing rhythm, everywhere. The product feels like one thing.

Memorize the bar. In Week 7 you'll be asked to prove your final work meets it, in front of your classmates.

3What a design system is

Consistency is the third word in the bar, and it's the hardest one to hold. One designer on one screen can be consistent by paying attention. Forty designers on four hundred screens cannot. So teams stopped relying on attention and built a machine instead. That machine is a design system.

A design system is the reusable parts of a product plus the rules for using them, kept in one place, treated as the source of truth. Not a style guide, which is a document people read once. Not a Figma file full of screens. A system is something teams build with, every day, and it exists in two places at once: a design library your designers pull from, and a code library your engineers install. When those two stay in sync, the product feels like one thing.

Product The screens a person actually uses Checkout, dashboard, settings Patterns Approved ways of combining parts “Confirm before deleting” Components Built parts with variants and states Button, input, modal, table Tokens Named decisions — the foundation color-danger, space-4, text-lg
Each layer builds on the one below it. Change a token and every component above it changes — that's the whole point. You build the bottom two layers in Weeks 2 and 3.

A quick word on the bottom layer, because it's the one students usually skip. A token is a named decision: instead of typing #a33232 into forty places, you define color-danger once and point everything at it. Rebrand day becomes one edit instead of a four-week hunt. Tokens are also how a design decision survives the trip into code, because engineers use the same names you do. You'll build yours in Week 3.

Who builds it, who maintains it, who uses it

A system is a product, and like any product it has a team that makes it and customers who use it. At a large company those are different people. At a small one they're the same person wearing two hats on different days — which is most likely to be you, early on.

Builds it
Design systems team

Designers and engineers whose product is the system. They design components, write the code, run accessibility audits, publish the docs, and version every release. At a startup this is one person, part-time.

Governs it
Design system lead

Owns the roadmap and says no. Decides what earns a place in the system and what stays a one-off. Without this role systems bloat into a junk drawer with three date pickers in it.

Uses and feeds it
Product designers

Build features out of system parts instead of drawing from scratch. When the system can't cover a need, they raise it — with evidence. Most of what enters a system starts here.

Ships it
Engineers

Install the component library and build features from it. They also catch what design missed: keyboard behavior, error handling, what happens at 200% zoom, what breaks on a slow connection.

Also in the room: accessibility specialists set the bar each component has to clear before it ships. Content designers own the words — button labels, error messages, tone — because "Delete" and "Remove" are not the same promise to a user. On small teams, all of this lands on the designer. On yours this term, all of it lands on you.

Why a business pays for one

Systems cost real money to build and maintain, so it's fair to ask what a company gets back. It's not "our app looks nicer."

What it returns

What it costs

Notice the last item on the left. This is the part that's new, and it's why this course is titled the way it is. When you direct an AI tool to build an interface, the quality of what comes back is capped by the quality of the spec you gave it. Your system is the spec. Students who hand a tool a precise component kit get builds they can ship. Students who hand it a vibe get slop. You'll prove this to yourself in Week 5.

How a new component actually gets in

Systems don't grow by committee brainstorm. They grow when a real product need shows up more than once. Here's the path, using a case that happens on nearly every team: the system has a date picker, and someone needs a date range picker.

  1. A designer hits the wall

    Someone on the Reporting team is designing a "custom date range" filter. She checks the system first — that's the habit. There's a single-date picker. There's no range picker. Checking first is the whole discipline; skipping it is how you end up with three of everything.

  2. She builds a local one-off

    The feature can't wait for a system release, so she builds a range picker inside her own file, using system tokens and the existing input component. She labels it clearly as local, not system. The deadline is met and nobody pretends the one-off is official.

  3. It happens again

    Six weeks later the Billing team needs a range picker for invoice history. Then Analytics asks. One team's need is a special case. Three teams' need is a pattern. That's the signal the system team waits for.

  4. Someone proposes it, with evidence

    The proposal isn't "we should have this." It's: three teams, five screens, screenshots of the three different one-offs already in production, and the specific reason the existing date picker can't be extended to cover it.

  5. The system team pushes back first

    Standard questions: can an existing component plus one new option handle this instead? Is there an established accessible precedent to follow? Does it need new tokens, or does it use what exists? The default answer is no. Making the system earn every addition is the job.

  6. It gets designed as a system part, not a screen part

    Every variant, every state, keyboard navigation, screen reader announcements, what happens on invalid input, what happens on small screens, and the content rules for labels and errors. This is ten times the work of the one-off — which is exactly why it waited for three teams to ask.

  7. Built, documented, versioned, released

    Engineers implement it in the code library, it passes an accessibility audit, it gets a documentation page with do and don't examples, and it ships with a version number and a changelog entry.

  8. Adoption — where systems live or die

    The three teams migrate and delete their one-offs. The old versions get formally deprecated. A component nobody adopts is worse than no component, because now the system is lying about what the product uses.

  9. It keeps changing

    Six months on, bug reports and usage data show people fighting the preset ranges. v2 ships. Systems are never finished — they're maintained, or they rot.

Patterns enter the same way, but they're documented rather than coded. A pattern is an approved way of combining parts to solve a recurring problem — confirming a destructive action, designing an empty state, structuring a multi-step form. After the fourth team invents its own delete confirmation, someone writes down the one right answer and everyone stops guessing.

Systems worth knowing

These are all public. Open them. Real systems, maintained by real teams, and free to study.

Where to browse hundreds more

Where this course goes. Week 2 you build your foundations — type, color, spacing. Week 3 you turn those into components with real states and named tokens. Week 5 you hand that kit to an AI tool as build context and find out how much your precision was worth. Week 7 the system ships as a portfolio artifact a hiring manager can open. You are building a small design system over seven weeks. Now you know what one is.

4Slop, and how to spot it

AI tools can generate a full interface in seconds. Some of it is good. A lot of it is slop: work that looks finished and isn't. Generic, inconsistent, wrong in ways that take a trained eye to catch. Spotting it is your first skill in this course, because you're going to spend the back half of the term directing these tools, and the quality of what ships will depend on what you catch.

Common tells

This week you'll practice on instructor-provided specimens. You are not generating anything yet, and nothing in the specimen set is meant to be kept or copied. It exists to be judged.

5The Warren Incubator RFP

The setup

Buffy Warren, a tech-entrepreneur-turned-philanthropist, funds MVPs that use technology for social impact. Her incubator has issued a Request for Proposal, and you're applying. Over seven weeks you'll take one product from proposal to working prototype to a pitch in front of her Investment Committee.

Read the full RFP document before Friday. It contains the sector details, the check-in schedule, and the evaluation rubric your final presentation is graded against.

EdTech — education access; low-bandwidth, mobile-first
HealthTech — healthcare access; privacy and compliance
Sustainability — climate action; low energy footprint
Mental Health — resource access; anonymity, 24/7
Public Safety — emergency response; works offline, usable under stress
Disability Services — independence; no extra hardware, screen-reader ready

Pick the sector you can stay curious about for seven weeks. Your proposal is one page: the problem, who it hurts, the sector's constraints, and your quality bar — three products you consider the standard for this audience. The committee reads the constraints section first.

One expectation, all term: any AI use gets disclosed. Which tool, what for, what you kept, what you changed. The committee treats undisclosed AI work as disqualifying, and so does this course.

6How to do this week's work

  1. Set up Figma Education first. Apply at figma.com/education with your school email. Verification runs through SheerID and you must verify within 7 days of joining the class team, or the team locks you out. Do it today, not Thursday.
  2. Read the starred items in section 7, then skim the rest as needed. Watch the one-hour fundamentals video if the vocabulary is new to you.
  3. Studio A — Teardown. Pick one screen from the excellent set and one from the AI set. For each, write what the design does with hierarchy, contrast, alignment, spacing, and consistency. Name what works, name what fails, use the vocabulary. Screenshots with annotations beat paragraphs.
  4. Studio B — Proposal. Read the RFP. Pick your sector. Write the one-page proposal. Be specific about the problem; "students struggle with resources" is not a problem statement, "rural students lose class access when their bus wifi drops" is.
  5. Post both to the share thread by Friday. Lead with your quality bar and defend it. Reply to two classmates by Sunday. Challenge a call they made. Politely, specifically, with the vocabulary.
  6. Field Work — Swipe File. Collect five screens whose type or color you admire. For each: what's the scale, what are the color roles, what would you steal. Post by Friday, reply to one classmate by Sunday. These become raw material for your Week 2 style tile.

7Resources

Everything here is free. Start with the starred readings — they carry the most weight this week. Titles only, on purpose: search them by name and you'll land on the current version.

8Before you submit