AI-native process

Library or custom

Every project I work on gets a design system, or I help structure the one it has. It does not always start from zero: libraries such as shadcn/ui or Google’s Material are valid starting points. Mostly, though, I build custom, client-fitted systems that scale. Kiddosy is one of them, built from scratch.

How the system is built

1. 1

   Research sets the priorities

   Kiddosy started with several large quantitative surveys and at least 50 qualitative studies with parents and organisers. They decided which screens and components matter most, so the system grew around real tasks, not a generic kit.

   AIsynthesis of interviews and surveysMewhat to build first

2. 2

   Tokens first, in one file

   Colours, shadows, borders and shell sizes live in one token file; components only read roles. Tailwind’s defaults are switched off, so nothing outside the system exists.

   AIvariants of palettes and scalesMethe values and their names

3. 3

   Atoms → molecules → organisms → layouts

   Components are built in that order, each with every state from the catalogue. A component goes where its complexity puts it, not where it was first needed. Components are presentational: copy and links come from the app.

   AIcoded components and statesMeanatomy, states, review

4. 4

   One catalogue, decisions side by side

   Every example sits in a tile on the product background, and the 16 families stay together. When there are competing variants, they stand next to each other with the question “which one?” until I decide; nothing is assumed to be the standard before that.

   AIalternatives to compareMethe choice

5. 5

   Guarded by tests

   An end-to-end test changes a token and checks that it reaches the navbar, sidebar and bottom navigation, so a “one-line change” stays one line.

   AIwrites and runs the testsMewhat must never break

Consistency audit

The audit checks styling rules, not the pixels of a single view. The split of work is deliberate and keeps the cost low: code measures and counts, the model judges only what code cannot know, and I decide.

1. 1Measure

   A browser opens the catalogue and collects the computed style of every variant: height, radius, border, background, padding, type, shadow and focus state.

2. 2Flag

   Code flags deviations from each family’s reference variant and values outside the scale. Scanners compute WCAG contrast for every text and check control borders against WCAG 1.4.11 (3:1).

3. 3Judge

   A language model answers only what code cannot know: is this deviation justified by the variant’s function, and is this element interactive at all?

4. 4Decide

   The output is a list of candidates for my decision, not verdicts. A full run costs under $0.001.

Catalogue completeness

A second check, with no model at all, compares three sets of variants: defined in the stylesheet, used in the product and shown in the catalogue. Its first run found 16 variants living in the product but missing from the catalogue, and 10 defined but unused. Every product gap was added; the target is zero.

• 16gaps from the product, all closed
• 10unused stylesheet variants found
• 0target

Where I decide

The system is built in a multi-agent workflow I set up: agent roles, quality gates, independent evaluation and handoffs. My own Claude skills run design reviews, UX/UI audits, predictive heatmaps and design-system consistency checks. They speed up the work, and I make the decisions. AI output is validated by:

• Users

  Interviews and usability tests.

• Data

  Analytics, A/B tests, heatmaps.

• Heuristics

  Nielsen, WCAG, the system’s own rules.

• Reviews

  With the team, approvals, iterations.

By my own estimate, I deliver the same scope about 70% faster than three years ago, and reinvest that time in research and quality.