Design system from scratch

Context

My role

I was the sole designer, which meant I drove the direction and priorities for the system.

There was no DS team. The monthly meeting with the engineering team was the governance mechanism, and I ran it.

I built the Figma component library, defined the token architecture, set up and evolved the token pipeline, and ran an ongoing product audit to close the gap between existing screens and the system. Product work ran in parallel throughout.

The problem

Fragmented implementation, no shared reference

The product had been designed without a systems mindset. Each engineer had implemented components independently, without a shared library or token reference. The result was visible inconsistency at the surface and no clear path to fixing it incrementally.

Color values differed across screens, component variants diverged between parts of the app, and Vuetify defaults filled the gaps where custom components hadn't been built. The inconsistency came from both sides. Screens had been designed one at a time, each defining its own rules, so the engineers had nothing stable to build against and every implementation went its own way.

There was also no Figma component library. Before I could propose any system, I had to build the raw material. Components needed to be defined, documented, and ready to reference before there was anything to systematize. That work ran in parallel with product design from the start.

Approach

Sequencing the work and adapting it to the team

A few weeks in, I proposed a two-tier token architecture. The more important decision was how to scope it.

I had run a similar process at a previous company and started with too large a token set, which created maintenance overhead before the system had meaningful adoption. At Remuner I started with a deliberately small set. A stable core of primitive and semantic tokens covered only what the product actually needed, with room to grow as usage made the gaps clear. The token set could expand from real pressure, not speculation.

Adapting the output to the team's existing conventions

The token pipeline was adapted from a setup I knew worked, and the engineering team translated it to match their stack. Remuner used Vuetify for components and Sass as the output format rather than CSS custom properties. That translation came out of the first monthly meeting where we talked through how the tokens would actually be consumed.

The decision that came from that conversation was to export tokens as both Sass variables and utility classes, following Vuetify's own naming conventions. Engineers already thought in that system. Rather than asking them to learn a new convention on top of the DS work, the token output met them where they were. That reduced friction on adoption without reducing the integrity of the system.

The monthly engineering meeting

Each month, the engineering team and I met to review progress, surface problems before they became blockers, and set goals for the next cycle. Everyone presented what they had done, including nothing if that was the case. Problems got discussed and solved together rather than escalated. Goals were agreed on, not assigned.

This cadence was the governance mechanism. There was no issue tracker, no formal review process. The meeting was where decisions got made and where the system evolved based on what was actually being built.

The ongoing product audit

The component library covered new work from the start. Closing the gap on the existing product was a separate, slower problem.

I ran an ongoing audit throughout my time at Remuner. I reviewed screens systematically, identified pattern inconsistencies, and captured every instance of each pattern across the product, going screen by screen through autocompletes, input states, and navigation variants. For each one, I defined the correct variants, states, and behaviors, then created a Jira ticket and shared it with the engineers for their input before anything went into a sprint.

Not every inconsistency was fixed immediately. If a part of the product was due for a feature addition, the DS work would be absorbed into that feature's scope rather than done twice. Fixing something that will change in a few months is waste, and this judgment call was part of the practice from the start. The audit identified what needed fixing; the timing was decided with the engineering team based on what was actually coming up in the roadmap.

The token pipeline and its evolution

The token repository matured over time. By early 2026, I worked with Codex to harden the repository. It gained a CI pipeline that validated every token update, build drift checks that kept the generated output from diverging from the committed artifact, smoke tests, an HTML preview for visual inspection without opening Figma, and a JSON output for JS consumers alongside the Sass files. Each change went through a PR reviewed by the engineering team before merging. Reviewing a PR became a question of whether a value was right, not whether the build had held together.

The icon library had its own repository and release cycle, separate from the component packages. This meant icons could be updated independently without introducing version conflicts or touching the component pipeline. The repository included automation for generating Vue components from SVG files, which made the process self-serve: an engineer could add an SVG file and get a usable component without a design handoff in between.