Design system · 2026 · LessonCruncher
LessonCruncher Design System
An open, school-agnostic design system for K–12 lesson creation — semantic tokens, composable patterns, and shared components for teachers, schools, families, and district governance.
Summary
Executive summary
Problem
K–12 lesson tools multiply across teacher workflows, school contexts, family communication, admin dashboards, and buyer evaluation. Without a shared language, accountability UI becomes one-off: retroactive standard tags, inconsistent trust signals, and chat-first layouts that districts cannot govern.
Approach
Built LessonCruncher as a code-first, open design system: semantic color and type tokens in lessoncruncherUi.ts, a composable component set (loop stepper, standard chips, blocked CTAs, trust badges), and five cross-surface patterns — standards gate, practice loop, family summary, admin rollup, and trust pack — shipped across lessoncruncher.com and portfolio interactives from the same React source.
Outcome
One token file and shared components power the product and the public design-system site. Code links and a Figma-ready pattern spec make the system inspectable while the portfolio demo and production app run the same educator loop prototype.
Problem
Diagnosis
The system problem was defining how K-12 lessons get created, reviewed, shared, and governed across many schools while encoding accountability as repeatable UI behavior.
Pattern drift
Without shared components, every new screen risked a fresh chat layout, a new standards treatment, or a new compliance badge — none of which would roll up to admin coverage maps.
Multi-audience density
Teacher workflows need warmth and guidance; admin dashboards need scan density. The system had to share tokens and components while supporting school-level adaptation and district-level governance.
Engineering handoff
Props, states, blocked behaviors, and pattern dos/donts had to ship with the spec. A Figma-only library would not survive the speed of a solo build or the need for portfolio interactives to match production.
Constraints
What was fixed
Semantic tokens, not page palettes
Color roles — primary, primary-container, secondary, muted, border, success — map to intent in lessoncruncherUi.ts so marketing, app, and checkout surfaces do not fork hex values per screen.
Ubuntu type scale
Display, headline, body, and label roles load through next/font. Standards codes and trust labels use consistent weight and tracking so compliance copy reads as system UI, not marketing fine print.
8px spacing grid
Cards, steppers, and form fields align to a single spacing rhythm so teacher and admin layouts compose from the same grid without per-page padding experiments.
School-agnostic content slots
Lesson hooks, examples, standards packs, and family copy use structured slots so one district can support many schools without hard-coding a single classroom context.
Principles
Design principles
01
Compose, don't fork
New screens assemble from existing components and patterns. If a surface needs a new treatment, extend a variant before inventing a parallel component.
02
Accountability is behavior
Standards alignment is not decoration — it is a blocked CTA state, selectable chips, and an audit hook that admin rollup consumes. The system encodes the rules; pages do not re-negotiate them.
03
One loop, many surfaces
The five-step practice loop is a single stepper component with compact and full variants, reused on marketing hero, demo, and in-app wayfinding.
Exploration
Concept exploration
Four architectural directions were explored for how lesson creation, accountability, and district trust should appear in the UI. Two consumer-style patterns were rejected because they could not be systematized across schools. The shipped system centers on a standards gate pattern and companion teacher, family, admin, and trust patterns built from the same token set.
- Rejected — not composable
Anti-pattern A
Chat-first generator layout
Optimized for speed but impossible to govern — every session invents a new conversation chrome with no reusable accountability primitives or admin rollup contract. - Rejected — accountability after the fact
Anti-pattern B
Post-hoc alignment panel
Standards appear in a side panel after generation. Familiar to ship fast, but the chip-and-gate pattern cannot enforce alignment before content exists — a system rule, not a styling choice. - Shipped — system primitive
Pattern C
Standards gate
Framework picker, lockable standard chips, formative bridge, and a blocked generate CTA until teachers confirm alignment — the core accountability primitive reused across every lesson-drafting flow. - Shipped — companion pattern
Pattern D
Admin rollup and trust pack
Coverage maps, activity tables, trust badges, and checkout compose from shared tertiary and border tokens so district buyers read governance as part of the same lesson system teachers use.
Specification
Standards gate — pattern anatomy
The standards gate is the highest-leverage pattern in the system: it turns lesson-quality requirements into composable UI regions engineering can estimate once and reuse across flows.
- Framework picker — scoped selection control, not free text
- Standard chip — selectable, lockable, with code + description slots
- Formative bridge — rubric and exit-ticket hooks tied to each chip
- Teacher confirm — explicit approval state before draft unlock
- Blocked CTA — primary action disabled until alignment is locked
- Audit hook — alignment state exposed for admin coverage rollup
Guided Flow
From prompt to lesson — Great Recession unit
Follow a 10th-grade US History teacher planning a lesson on the creation of the Great Recession: capture the unit goal, lock standards before generation, review the drafted plan, then run the practice loop. The core path from idea to lesson — without every downstream step.
Decision
System architecture decisions
| Option | Consistency | Extensibility | Shareability | A11y risk |
|---|---|---|---|---|
| Per-screen design mocks | Low — drift per surface | Poor — no shared API | Poor — cannot download a system | High — untested per page |
| Token + component library | High — one source of truth | Strong — variants compose | Strong — code and docs are inspectable | Lower — states spec'd once |
| Pattern docs only (no code) | Medium — depends on discipline | Good for discovery | Medium — portable but not executable | High — implementation gap |
Open code-first token + component library
Open code-first tokens and components won because the portfolio had to prove the same system readers inspect is the system users touch on lessoncruncher.com. Pattern-only documentation would have separated design review from production reality.
Outcome
What shipped
The design system ships as a live product and a public library — not a slide deck. Tokens, components, and patterns cover the surfaces a teacher, school leader, family, and district buyer encounter.
- Surfaces
- 5
- Core patterns
- 4
- Shared stepper
- 1
Marketing, demo, teacher app, admin, checkout
Gate, loop, family, rollup, trust
Compact + full variants across hero and app
The useful systems work was making accountability feel native — not bolted on per screen. By pairing semantic tokens with behavioral components (blocked CTAs, lockable chips, trust badges), new flows compose instead of reinventing. Family, checkout, and admin surfaces inherit the same language teachers see in the standards gate.
Reflection
Looking back
LessonCruncher is the kind of systems project that does not announce itself — until a district buyer, administrator, school leader, teacher, and family all recognize the same product in different densities. The job of a lead design systems IC is not to ship the prettiest screen; it is to decide which behaviors are primitives, document the anti-patterns, and keep code and critique pointed at the same source. Next maturity step: a published Figma community file and contribution checklist for new patterns.
Available
Need something similar?
Best fit for platform UX, growth systems, internal tools, and teams that need a senior IC who can shape the problem and ship the details. I respond to most inbound within a day.
