Interface Design

Foundations tell you what a screen is made of. Interface design is making the actual thing: the buttons people press, the forms they abandon, the empty state they meet on day one.

What separates a team that ships consistently from one that does not is rarely talent. It is whether the pieces have names. Named components, named values, named patterns, named states. When a designer and an engineer both say "secondary button, disabled" and mean the same pixels, handoff becomes a conversation instead of a negotiation.

This is the point where mockups stop being pictures and start being a specification.

Components

A component is a named piece of interface with defined variants and defined behaviour. Button, with variants primary, secondary and destructive, two sizes, and states for hover, focus, active, disabled and loading. Not "the blue rounded rectangle on the pricing page".

Build the component the third time you need it, not the first. Two similar things can be coincidence. By the third you know which parts actually vary, and you avoid baking a false variant into the library forever.

The failure mode is a library nobody uses. It happens when a component does not cover a real case, so someone detaches an instance and edits it by hand. Watch for detached instances. Each one is a bug report about your library, filed silently.

UI Patterns

A pattern is the settled shape of a solution: where navigation lives, how a modal behaves, what a date picker looks like, how a field shows its error. Most of these are already decided. Users spent years learning them on other products, and that learning is free to you unless you fight it.

Deviate only where the standard genuinely fails your case, and be able to say how it fails. "It felt generic" is not a reason. Novel navigation charges every user a small tax on their first visit and again after a few weeks away.

Write your chosen patterns down with the rule for when each applies — modal for a blocking decision, drawer for a side task, full page for anything with its own URL. Skip that and you will ship all three for the same job.

Design Tokens

A token is a named design decision: space-4, color-surface-raised, radius-md, font-size-body. The value is not the point. The point is that the value lives in exactly one place and everything else refers to it.

Name tokens for their role, not their appearance. color-text-muted survives a rebrand; gray-600 does not survive the day muted text turns blue. The usual structure has two layers: a primitive palette (blue-500) that nobody references directly, and semantic tokens (color-action-primary) that point at primitives and are what designers and engineers actually use.

This is what turns dark mode into a remapping instead of a rewrite. Without tokens, dark mode means finding four hundred hardcoded hex values by hand, and you will miss some.

Interface States

Every component and every screen has more than one state, and the one in your mockup is the flattering one — real data, the right amount of it. Design at least five: empty before anything exists, loading while it arrives, partial when it arrives thin — one row in a list built for twenty — error when it never arrives, and the ideal case you drew first. Then hover, focus, active, disabled, selected.

Empty states are the ones teams skip and the ones new users see first. A list reading "No items" squanders the most attention you will ever have. Say what belongs here and offer the button that creates one.

Error states must say what went wrong and what to do next. "Something went wrong" is an apology, not information.

Design the sad path deliberately, or ship it by accident.

Sign in to track your progress

Discussion

Sign in to ask a question

No questions on this lesson yet. Highlight a passage to ask about it, or use Ask a question.

Up next

Motion & Interaction

Build the Interface