Skip to story

TE Design System

Keeping design decisions consistent, from Figma to code.

Personal project · Started 2024 · StyleX port in progress

I started TE Design System in 2024 to stop making the same interface decisions from scratch on each freelance project. I designed and maintain the Figma library. Now I’m porting it to StyleX for design engineers and developers working with coding agents.

The Figma library: foundations, component variants, and documented states. The StyleX port is in progress.

Make the recurring decisions once

I separated foundations from components. Color, typography, spacing, elevation, radius, and stroke establish the shared rules; navigation, inputs, feedback, and layouts use them. A new screen starts with those decisions already available.

In the button library, I documented appearance, interaction state, and icon placement together. A secondary button with a leading icon has a named hover variant; loading and icon-only treatments are documented too. Those details give someone implementing a screen less to guess.

My background in architecture shaped that emphasis on documentation. A drawing needs to communicate enough for someone else to build from it. I brought the same expectation to these components.

Keep a small inconsistency from becoming a pattern

Working with coding agents exposed another problem. In my Tailwind projects, I’ve seen styles drift even with instructions in CLAUDE.md or AGENTS.md. An agent makes one small exception; later changes reuse it. That exception can become the pattern across the interface.

I want the design system to give agents a consistent set of components and styles to reach for. The rules need to be present in the code they use, as well as in the documentation they read.

Bring the Figma system into StyleX

StyleX has been more consistent in my own agentic workflows, which is why I’m using it for this port. Its shared style references, typed boundaries, and predictable composition give me a foundation for carrying the Figma decisions into reusable code.

The design work now includes deciding which choices a component should expose and which should stay consistent. I’m aiming for enough flexibility to build different interfaces without reopening every spacing, type, and state decision during generation.

Where it stands

The Figma library exists today, and the import into StyleX is underway. The code library is still in development. My observations so far are the reason for pursuing it; I haven’t measured a reduction in design drift.

The next question is whether another developer and their agent can use the system consistently without me explaining each decision. That’s what I want this next version to make possible.

Close