Your design system drifted and nobody caught it until the whole thing felt off. This course teaches the structural fix.
Coming SoonThe design system started clean. Then twelve people touched it over three years. Every decision made sense when it was made. Nobody was making bad calls. But the cumulative effect is a system that says five different things depending on which surface you're looking at. The typography scale has exceptions. The component library has variants that contradict the pattern they were supposed to extend. The information architecture drifted from the product's actual mental model two years ago and nobody went back.
Or the brand version: three agencies touched the identity over four years. The guidelines exist, but they govern the logo and the color palette, not the actual decisions people make when they're building pages. The photography direction drifts. The tone shifts depending on who wrote the brief. The system looks like itself in the style guide and like three different companies in production.
A design system has layers the same way any complex system has layers. Information architecture (what the product thinks it is), visual system (how it presents), interaction patterns (how it behaves), and voice (how it sounds). Most design system work treats these as one problem or sequences them wrong. They are separate structural layers, and incoherence shows up when the layers disagree with each other.
This course teaches you to separate them, audit each one independently, identify where intent stops surviving execution, and build governance that holds across contributors and time. The methodology comes from the same place all Joinery courses draw from: accommodation design. You figure out what the system needs to do its job, design around that reality instead of the one you assumed, and build structure so the coherence doesn't depend on one person being in the room for every decision.
Break the system into structural layers
A design system has at least four layers operating simultaneously. Information architecture: what the product thinks it is, how it organizes concepts, what relationships it assumes. Visual system: typography, color, spacing, component logic. Interaction patterns: what the product does when you touch it. Voice: how it sounds when it talks to you. When these layers agree, the product feels coherent. When they disagree, the product feels off and nobody can say why.
Most design system audits treat the whole thing as one object. This module teaches you to decompose it, evaluate each layer against what the product actually needs, and find the specific disagreements between layers that produce the drift you're feeling.
Deliverable: A structural audit of your own design system or brand system, with each layer evaluated independently and cross-layer conflicts identified.
Read the system before designing at it
The instinct is to fix what looks broken. Redesign the component. Rewrite the guideline. Update the spec. The structural version starts earlier: what does this system actually need to do its job? What processing reality is it operating under? How many contributors touch it? How fast do they need to ship? What decisions does the current structure ask people to make, and are those decisions the system should be making for them?
This module teaches you to read the system the way a special education teacher reads a classroom. You don't design the instruction and hope the student fits it. You read what the student needs and build the instruction around that. Same move, applied to a design system, a brand, or a platform architecture.
Deliverable: A processing profile for your system: who touches it, what decisions they face, where the structure asks for judgment it should be providing, and a structural recommendation based on what you found.
Build rules that hold across contributors and time
A design system without governance drifts. The people making decisions are usually making reasonable ones. The problem is structural: no mechanism existed to catch the cumulative effect of those decisions as they accumulated. Governance is the set of rules, constraints, and checkpoints that make coherence hold without depending on one person's judgment being present at every decision.
This module teaches you to build governance that works: naming conventions that carry intent, component rules that prevent the variants-of-variants problem, voice constraints that hold across contributors, and review checkpoints that catch drift before it accumulates. The goal is a system where someone new can make a coherent decision without asking the person who built it.
Deliverable: A governance layer for your system: naming rules, component constraints, voice protocol, and a review checkpoint structure, tested against a real scenario from your project.
I built this methodology inside a production enterprise platform. Encore is a recruiting platform I've been the principal architect on for thirteen years. Over a thousand client deployments. Three full technology shifts: desktop to browser, monolith to modular front end, static to real-time. The platform stayed in production the entire time the architecture was being rebuilt underneath it.
I watched what happens when structural governance isn't maintained across years of decisions. The drift is invisible at first. Every individual call is reasonable. The front end agrees with the back end on what the product is, sort of, but the information architecture between them stopped agreeing somewhere around year four and nobody noticed until it was expensive to fix. The design system accumulated variants that contradicted the patterns they extended. The typography scale got exceptions that each made sense in isolation.
The methodology I use now came from fixing those problems in production, under real constraints, with real users on the other end. You decompose the system into layers, figure out what each layer needs to do its job, and build governance that keeps the whole thing coherent even as the people maintaining it change. This course teaches that methodology applied to whatever you're working on.
Built by a design engineer who spent thirteen years governing the same platform through three technology shifts. About the instructor.
Three modules. Three deliverables. Your own real system.
Get notified when this launchesComing soon. Join the list for launch details and pricing.