The foundation under every new LogicTrade module — started as support while building the first next-gen screens, grown into a living system with three working prototypes.
Born from necessity, not a briefing
The design system didn't start as a separate project — it emerged while I was building the first next-gen modules. To design Quote quickly and consistently, I needed reusable building blocks: colors, type, components, behavior patterns. What began as practical support grew into a full-fledged system, with me as its creator, guardian, and owner.
Two drivers, one urgency
Without a shared system, every new module — Quote, Service, Planning, and the 10+ that would follow — would develop its own color choices, button styles, and loading behavior. That drifts apart within just a few modules.
That need became more urgent when the whole product team switched to an agentic way of working: developers now work with Claude and Codex, at high speed. That way of working was mandated by the organization — developers aren't designers, and at that speed, inconsistency is a constant risk. A classic design system, aimed at people reading it at their own pace, was no longer enough.
Every building block, plus the proof that they work
Not just tokens and rules on paper, but a system that proves itself in real working software and is usable by the agents now helping to build it. Alongside the design principles (brand, color, typography, loading and empty states), I built three working prototypes — Quote, Service, Planning — that tested the system directly against a real flow, instead of an isolated style guide.
Not a classic design system
The result consists of three layers, each with its own audience — human, machine, or both.
Working screens where I, as a designer, can see and feel whether the system holds up in practice — the human check.
Reusable building blocks that apply directly in both Figma and code, for designer and developer alike.
Rules and guidelines, written in markdown, specifically structured so Claude and Codex can read and follow them.
From Claude Code to Lovable
The prototypes were built with Claude Code. At my manager's request, the whole thing was moved to Lovable, so the system is easily accessible to development and other stakeholders within the organization — no local setup needed, just a link.
The obstacles along the way
Developers now iterate incredibly fast with Claude and Codex. Rules that lag behind practice are outdated within days — so the MD structure had to be updatable just as fast as the development team itself works.
With a growing system, you can't formalize everything at once. I prioritized what development actually needed, rather than chasing a complete but too-late system.
Every subsequent module (Service, Planning, and beyond) brought its own edge cases, which the system had to absorb without becoming inconsistent.
What drives the system
"Every color, every component has a meaning — not decoration, but behavior."
That principle is written down literally: brand blue is reserved for interaction, magenta exclusively for status, green only for confirming actions. The same goes for behavior — skeletons over spinners, a fixed 400ms delay before a skeleton appears, visible for at least 500ms to prevent flickering. Not aesthetics, but rules that both a designer and an agent can apply without doubt.
Brand blue = interaction, magenta = status, green = confirmation. Never decorative.
Timing, states, and transitions are exact rules, not approximate guidelines.
Every rule must be just as unambiguous for a designer as for an AI agent.
A glimpse of the system
The documentation and the prototypes live in the same environment: one SPA shell where you can click straight from a color token to the screen where that color does its job.
The entry point — downloads, prototypes, and system pages together
Quote prototype — proof that the separate pieces form a screen together
Colors — every token with a usage rule, not just a hex code
Inputs — two flavors of fields, with every state spelled out
UI elements — component next to the specs that go with it
Click an image to view it at full resolution and browse through the set.
The foundation under everything still to come
The system grew alongside what the organization actually needed from it — from style guide to a buildable, agent-readable foundation under everything LogicTrade builds now and later.
What I take from this
When development turned out to need more than visual guidelines, I could have kept the project strictly within its original scope. Instead, I let the system grow into a hybrid with a component library — because the request came from a genuine usage need, not scope creep without reason.
With development's agentic way of working, the system also had to become readable for Claude and Codex, not just for people. That changed what "good documentation" means — structure and consistency became even more important than visual clarity alone.