Skip to content

Repository files navigation

Onboard Design System — case study

The design system extracted from Onboard, a mobile web app that teaches you a board game you already own. Tokens, foundations, components and a click-through UI kit — packaged so a design agent can produce on-brand screens without being told the rules twice.

The product it came from: onboard-board-game-teacher


What this repository is

A personal case study, published for review rather than reuse. It's the system, not the app: built by reading the product codebase rather than screenshots, so the tokens here are the tokens that ship.

No publisher artwork is included — the cover tiles are generated placeholders.

├── SKILL.md                     the agent entry point
├── styles.css                   one import manifest; link this file
├── tokens/                      colours, typography, spacing, effects, base — 54 tokens
├── components/
│   ├── actions/Button           primary / secondary / ghost, three sizes
│   ├── content/                 Card, SectionHeading, PileCard, GameTile
│   ├── feedback/                Badge, TrustBanner, ProgressBar
│   └── navigation/TopBar        back/exit · stage title · step count
├── guidelines/*.card.html       colour, type, spacing and brand specimens
├── ui_kits/onboard/
│   ├── index.html               interactive click-through in a phone frame
│   ├── screens.jsx              Home / Rules / GuidedSession + slide router
│   ├── diagrams.jsx             bespoke token-driven teaching SVGs
│   └── data.js                  two ported rule records + the roster
├── scripts/make_placeholder_covers.py
└── _adherence.oxlintrc.json     lint rules that enforce the system

The interesting parts

It's a design system built for a machine to consume. SKILL.md is the entry point, _ds_manifest.json the index, and every component ships a .d.ts contract, a .prompt.md usage note and a @dsCard demo. The _adherence.oxlintrc.json lints for drift. A human can read all of it; the point is that an agent can too.

The skin is deliberately near-greybox, and that's the argument. Warm off-white surfaces, near-black ink, exactly one muted charcoal accent, one soft shadow, three radii. It is intentionally "not styled yet" so the look never biases whether the concept works. Restraint is the aesthetic, and everything is token-driven so a re-skin is a config edit.

The system font stack is a decision, not a default. It signals greybox, costs nothing, and avoids Inter — the classic AI tell.

The avoid list survives any re-skin: violet-to-pink gradients and blob backgrounds, glassmorphism, Inter or Geist as the everything font, pill-shaped everything, emoji as interface icons, the centred gradient headline with three feature cards, drop shadows on everything, decorative 01/02/03 markers where nothing is sequential, copy that sells instead of guides. Writing down what the system must never do turned out to be more useful than any positive rule in it.

One colour carries meaning. An earthy ochre, reserved for the UNVERIFIED flag — the signal that a game's rules were generated rather than verified. In a teaching app that badge is the safety mechanism, so it gets the only non-grey in the interface.

Using it

Link styles.css; components live on window.OnboardDesignSystem_c6369e.*. Open ui_kits/onboard/index.html for the click-through.

Cover tiles in assets/covers/ are neutral placeholders at the 2:3 ratio GameTile expects. Drop real images over the same filenames to use your own; regenerate the placeholders with python3 scripts/make_placeholder_covers.py.

Licence

All rights reserved. Published for review, not for reuse — see LICENSE.

Game names, cover art and fonts: see NOTICE.md.

About

Design system for Onboard: 54 tokens, 10 components, specimen cards and an interactive UI kit, packaged for a design agent to consume. Personal case study.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages