Interface Design Foundations
Learn the craft behind screens that feel obvious: layout, type, color, states and the words on the buttons.
Beginner with Soren Klepacki
Build a component library that a real product team will adopt, and keep using after the launch announcement.
A design system is not a component library. The library is the artifact; the system is the agreement about how decisions get made, who can change what, and what happens when a team needs something the library does not have. Systems fail at the agreement, almost never at the components.
This is the most advanced course in the catalog. Over eight weeks you audit an existing product surface, define tokens, design a small set of component interfaces properly, write the documentation a busy engineer will actually read, and put a governance process in place that does not depend on you personally reviewing everything.
It assumes real experience: you should have shipped interface work and have opinions about component structure already. If you are earlier than that, Interface Design Foundations is the right starting point.
Applications for the Q4 2026 cohort close on Friday 18 September 2026. We reply to every application within two business days.
Interface design and front end craft
Nothing is finished until the empty state, the error state and the loading state are drawn. Those are the screens your users will actually meet.
Each module has one live session and one piece of practice applied to your own work.
Inventorying every button, input and card in the product, and using the duplication you find to make the case for the work.
Naming decisions by role rather than appearance, so that a theme change does not require renaming everything.
Treating each component as an API: which decisions it exposes, which it refuses, and how it fails when misused.
Knowing when to add a property and when the answer is a smaller component the team can assemble themselves.
Encoding focus, keyboard behavior and semantics into the component so consuming teams get it without effort.
Writing the page an engineer opens at four in the afternoon, with the decision guidance and the counterexample.
A contribution path that does not depend on you, a deprecation process, and how to say no to a request without losing the team.
Tracking real usage across the product, finding the surfaces that never migrated, and reporting the system's value honestly.
By the last session of Design Systems in Practice you will have practised each of these on your own work, not on a case study.
The craft behind interfaces people find obvious, from single screens to a shared component library.
Learn the craft behind screens that feel obvious: layout, type, color, states and the words on the buttons.
Beginner with Soren Klepacki