Growing a design system while the product was being rebuilt

Where I started

When I picked up Spark, JobTeaser was moving its product to a new stack. The design system was half-built, and its lead had just left. So I took it over: the tokens in Tokens Studio, the component process, the roadmap. I worked hand in hand with a front-end developer.

The hard part was switching levels all day. One minute I was solving a very specific need on a page we were migrating. The next, I was asking what that need meant for the whole system.

Making decisions stick

People kept asking the same questions. Which component should I use? Highlight or default? What does accessibility require here? I put the answers in one place and made a call on each. We could revisit any of them later, but teams could move on today.

New components now go through the design system team first, then designers and front-end devs outside it. Once they pass, we announce them to everyone.

Badges were a good test. They were too heavy, especially in packed back-office tables. But the front office used them too, so any change hit the whole platform. I toned down the main variants and added a faded one for secondary info. The strong ones are still there when a page needs them.

Motion tokens

We had no motion tokens. Just animations hard-coded here and there, each built differently. I listed what existed, defined the tokens, documented them and shipped the PR myself, with a developer reviewing it. Then I applied them to Button, IconButton and Callout. They respect prefers-reduced-motion.

I wanted the product to feel warmer and less static. The best feedback came from other designers: they started adding motion to their own components and flows, because now they had a documented way to do it.

Page factory

The back office serves schools and recruiters. Two very different audiences, and no shared way to build a page. Every designer did it their own way, almost from scratch each time.

Spark was built for the front office, so I adapted it. I added new variants, then designed four templates (list, detail, create, edit) with navigation and states built in.

Now a designer picks a template and fills it in. On a list page, you choose the table columns. On a detail page, you split the content between two columns based on what matters most. On a create or edit page, you decide the blocks, what to call them and which form fields go inside.

Nobody rebuilds a page layout anymore before getting to the actual flow.

What it changed

We shipped six or seven pages with the templates, including one major feature migrated end to end. We didn’t touch a single backend call, which mattered because the backend team had no bandwidth.

I don’t have a before/after number, since there was no process to compare with. But designers and developers no longer rebuild structure, navigation and states for every page. The page factory is now the default for every new back-office product and redesign.

Next up

Designers, PMs and devs now prototype with AI agents, and those agents read the design system. I’m working with our front-end developer on clearer tokens and docs. I want agents to pick the right component for the same reasons a designer would.