Design Systems
Tokens, governance and deprecation. Built twice, so you can see which version survives its second year.
- Courses
- 16
- Hours
- 24
- Modules
- 5
The path builds a small system twice: once the way most teams do it, and once with ownership and deprecation defined from the start. The second build is slower for two weeks and considerably faster afterwards.
Seeing both is the fastest way to understand why the second one holds.
The sequence
Modules unlock in order. You finish one before the next opens, which is the point of a path rather than a playlist.
-
01
Naming by role
Why a token called button-teal expires and button-primary does not.
-
02
The token layer
Colour, type, spacing and elevation as one set of decisions.
-
03
Governance
Who approves an addition, who approves a removal, and where that is written down.
-
04
Deprecation with a date
A removal path that actually removes things.
-
05
Measuring adoption
The monthly query that tells you whether any of this is working.
What you can do afterwards
The assessment checks these directly, against a rubric published before you start.
Before you start You have shipped interface work in a team and felt a library go wrong.
- Name tokens so a rebrand is a value change, not a rename.
- Write the three sentences of governance a system needs.
- Retire a component instead of marking it deprecated forever.