Status: Building in public Started: November 2025
Most design systems courses teach you how to use a tool:
- "Here's how to use Figma variables"
- "Here's how to set up design tokens in code"
- "Here's the perfect component architecture"
What I'm curious about: Where should your source of truth actually live? And more importantly: What are the real costs and tradeoffs of each approach?
Design systems education often focuses on specific approaches:
- Courses that teach how to use specific features in depth
- Consulting engagements that build comprehensive systems
- Tutorials that demonstrate successful implementations
- Framework-specific guidance for particular tech stacks
What I'm building is comparative, systems thinking. Teaching people to see the tradeoffs and choose deliberately based on their team's reality—not based on what demos well or what's trendy.
I'm building the same design system three ways:
- Figma as source - Variables, modes, components as single source of truth
- Code as source - CSS custom properties and components as source of truth
- Token system as source - JSON tokens with build pipeline
I'll build them in parallel. I'll document what breaks, where friction appears, and what the maintenance burden looks like. I'll show where each approach excels and where it falls apart.
Then I'll teach the decision framework: When to use which approach, when to use hybrid approaches, and when to keep things simpler than any of these options.
Most teams are either:
- Maintaining duplicate systems (Figma AND code) that drift out of sync
- Letting one system atrophy while pretending to maintain both
- Arguing about which tool to use without a framework for the decision
The honest answer might be uncomfortable: for some teams, maintaining a full design system in Figma might not deliver value proportional to its maintenance cost. For others, it's exactly the right choice.
The difference is context—team size, composition, workflow, complexity, platform requirements.
- What content? What IA? What pages, sections, layouts?
- Let the actual content tell you what components are needed
- Don't build a system in a vacuum
- What are all your options?
- History of how we got here (Photoshop → Sketch → Figma → Variables)
- Context for evaluating what comes next
- Same system, three approaches
- Real tradeoffs documented
- No "one right way" - just informed choices
- Every component in both contexts
- Show how they connect (and where they can't)
- Real implementation, not theoretical comparison
- How systems work in CMSs (WordPress, Contentful, etc.)
- Content editor experience
- Where systems break down in real use
- What breaks at scale and why
- What we're still figuring out
- When to fully synchronize vs. when to let Figma stay static
- Living style guides with states and testing
Anyone interested in design systems can follow along. You don't need to be an expert in Figma or code — the concepts and ecosystem thinking are what matter.
I'll show the code (semantic HTML, CSS, etc.) and call out key concepts, but I won't teach web development from scratch. That's what DFTW is for.
I'll show the Figma work and explain what's happening, but I won't teach every tool feature. There are plenty of courses for that.
This is about: The overall ecosystem, the concepts behind design systems, and the strategic decisions that make them work (or break them).
I believe in learning through discovery and showing people what breaks and why. I don't want to present polished, idealized systems. I want to show the mess, explain why it's messy (in both design tools AND code), and teach people to work intelligently within constraints.
Real design systems get messy:
- The hierarchy of primitive → semantic → component tokens gets complicated
- Naming becomes architecture
- Refactoring becomes expensive
- Modes and themes multiply
These problems exist whether you're working in Figma or CSS or JSON files. The mess isn't a bug—it's the lesson.
By documenting this process—what I tried, what broke, what worked—I can teach systems thinking instead of tool operation. That's the skill that transfers across tools and remains valuable even as specific tools evolve.
I'm documenting this process as I build:
- Real implementations (not polished demos)
- What breaks and why
- Honest assessments of tradeoffs
- Decision frameworks as they emerge
This isn't about being anti-Figma or anti-code or anti-anything. It's about giving people the information they need to make informed decisions instead of just following the latest trend.
Design Tool: Figma
- Native variables, no plugins unless absolutely necessary
- Show what the tool can and can't do without external dependencies
Code: Modern Web Platform
- CSS custom properties (no Sass, no CSS-in-JS, no Tailwind)
- Native CSS nesting
- Vue for components (clean templating)
- Nuxt for organization
- CodePen for isolated demonstrations
Tokens: JSON + Style Dictionary
- Platform-agnostic token definitions
- Build pipeline to multiple outputs
- Version control and diffing
Why these constraints:
- Teach principles, not framework specifics
- Show what the platform can do natively
- Avoid tooling that might be obsolete in 2 years
- Keep focus on systems thinking, not build configuration
/research/- Course references and methodology (read more)- Documentation files - Working notes and thinking process
- Project files - Actual implementations as they're built
This is a work in progress. I'll be updating the repository as I build, documenting discoveries and insights along the way.
Connect:
- Practical Education
- Updates posted as work progresses
I've been building design systems in HTML/CSS for a decade. When Figma variables launched, I recognized the patterns I'd already implemented in code — along with the same fundamental constraints.
This course is about sharing what I've learned: where systems work, where they break, and how to make strategic decisions based on your actual context rather than what's trendy.
This isn't a perfect system. It's an honest exploration of real tradeoffs.