TeachKit design system

One product, two visual scopes

The app gives creators a persistent workspace and learners a focused lesson player. Its warm canvas, quieter panels, Inter typography, and light/dark themes support daily work. The marketing site uses the same type family with larger, heavier headlines, pastel feature panels, and a light-only canvas. Those differences are intentional source distinctions, not interchangeable theme settings.

This is a retrospective portfolio reference to implemented software. It is not a claim that TeachKit previously shipped a separate component library or operated a formal design-system program.

What changed in this edition

Source baseline

Principles inferred from the implementation

• Keep the next action close to its context: a lesson’s completion control, its curriculum, and its resources belong together.
• Use one active editing surface instead of repeating every lesson’s controls at once.
• Show persistence honestly: pending changes, confirmed saves, and blocked edits have different meanings.
• Keep appearance preferences independent of the course or account record being edited.
• Preserve a recognizable course identity from discovery through enrollment and learning.

Evidence boundaries

All account, learner, course, review, progress, and revenue examples are deterministic fictional fixtures. Provider connections, media, saving delays, and conflict responses are local demonstrations. No live customer data, email delivery, checkout, enrollment, or database writes were used. Marketing copy and styling come from its repository; catalog examples are fictional.

Use the component contracts for composition, the patterns for complete tasks, and the readiness register for source limitations. Visual examples show implementation; they do not establish complete accessibility or production integration reliability.