From 15 years of inconsistency to a system the whole team relies on.

Problem

Stuvia's product carried 15 years of accumulated inconsistency. No designer had ever worked there full-time. Components, spacing, and colors varied across every surface, with no documentation and no shared language between design and development.

Approach

I audited the product, introduced the concept of a design system to a team that had never encountered one, built the system in Figma alongside live project work, and got eight developers to adopt a structured workflow for the first time.

My role

Sole designer. I owned the audit, the pitch, the build, the documentation, and the ongoing evolution of the system — including extending it to support AI-assisted development.

Result

Projects that once took months now ship in one to two weeks. Design reviews land faster. The system has been extended to support AI-assisted development with Claude Code. Two years later, no one at Stuvia can imagine working without it.

Stuvia had been building its product for fifteen years without a dedicated product designer. When I joined as their first, I found a product that looked like it was built in 2009, because most of it was. Tabs that did not function. Screen readers that did not work. Contrast ratios that failed accessibility standards. No clear directional logic through the core user journeys. These were not edge cases. They were the baseline.

The design files that freelancers had left behind were minimal. No component library. No documented color palette. No spacing rules. Each freelancer had handled their project in isolation, with no reference to what came before. Fifteen years of one-off decisions had stacked on top of each other with nothing tying them together.

This was the environment I inherited. The inconsistency was not just a cosmetic problem. It was structural. And it was going to take more than polished screens to fix it.

The visible symptoms were everywhere: buttons with different border radii on adjacent screens, font sizes that varied by a pixel or two for no reason, colors that looked similar but were different hex values. Visually distracting, but not the core issue.

The deeper problem was that the development team had no reference to build from. They received image exports and had to guess at font sizes, padding values, and spacing rules. Every handoff was ambiguous. Every implementation was a judgment call. That meant even careful, well-intentioned developers were introducing inconsistency just by doing their jobs.

There was no shared language between design and development, because there was no design infrastructure to anchor one. The inconsistency was the symptom. The missing system was the cause. Once I understood that, the solution became obvious.

I raised the idea in a product meeting with the management team. I opened with a simple question: “Have you heard of a design system?” They had not. Before I could pitch a solution, I had to explain what one was, walk them through what it looked like in practice, and make the case for why consistency at the component level would save time across every future project.

My PM understood it immediately. He had pushed for hiring a designer in the first place, and the value of the system landed without much effort. Management followed once they saw the time and consistency argument clearly laid out. The harder conversation was with the developers.

The dev team had been working in a specific way for years. I was new, and I was pushing on details they had never had to think about before: “This font should be 12px, not 13px.” Small corrections, but to a team used to moving without a design reference, they felt like friction. Some were not happy about it.

The shift happened once I introduced them to Figma as a handoff tool. Before, they received image files and had to interpret values from screenshots. With Figma, they could click any component and read every value directly: padding, font size, color, border radius. The guesswork was gone. One by one, they started to prefer the new way of working. That was the moment the system stopped being my project and started becoming theirs.

I owned this project entirely. No second designer, no design ops support, no dedicated sprint. I ran the discovery, built the component library, structured the Figma workspace, wrote the Notion documentation, introduced the team to Figma as a handoff tool, and maintained everything as the product grew. All of it ran in parallel with regular product design work.

Having worked as a developer before moving into design gave me an advantage here. I understood what the team actually needed from a handoff: consistent naming, readable values, no ambiguity in the specs. I built the system with their workflow in mind, not just my own.

That constraint, building in parallel with live work, shaped every decision I made about scope and prioritization. The system had to be practical before it was perfect.

Starting with the audit

I started by working through the existing product to understand what was there. The honest assessment: very little consistency to document. Some colors existed, but not as a defined palette. Buttons existed, but in multiple versions across different screens. Spacing had never been specified anywhere.

Rather than spending weeks cataloguing every inconsistency in exhaustive detail, I identified enough to understand the scope and the starting point. My CTO was direct about expectations: he did not want me disappearing into documentation. The team needed something usable, not a comprehensive audit report.

What the audit confirmed was that I had near-complete freedom to establish the foundations from scratch. There was nothing systematic enough to preserve. That was clarifying. It meant I could build the right thing rather than inherit the wrong one.

Deciding what to build first

I started with foundations. Colors first, because they fed into everything downstream and were the most visible inconsistency across surfaces. Then typography. Then the button component, because buttons appear in every flow and were the clearest example of how one element could look five different ways across the same product.

Once the foundations were stable, I shifted approach. Rather than building the full component library upfront in isolation, I tied new component work to active projects. Every time a project required a component that did not exist yet in the system, I designed it for the library first, then applied it to the project. This kept every component grounded in real use. Nothing was speculative. Every decision had a live context to validate it against.

From audit to system

I set up a structured Figma workspace: a team with separate projects for different product areas, files organized by function, and a master overview file where every finalized component lived in one place. The developers always knew where to look. That master file also served as a living record. Every time a component was finalized and tested in a real project, it went there.

The first version I was genuinely confident in took between six and twelve months to reach. That timeline stretched because the system was evolving alongside the product. Components were added, tested in real projects, and revised. Some developers adopted the new workflow faster than others. A significant part of the work was not building components. It was coaching a team of eight through a new tool and a fundamentally new way of working.

Adoption did not happen through a single handoff. I ran a live walkthrough where the team could watch me navigate the system and ask questions in real time. My background in development gave me credibility in that room. I knew what they actually needed: consistent naming, clear component states, no ambiguity in spacing and sizing values. I built the Figma structure with those priorities in mind from the start.

The Notion documentation covered the essentials: naming conventions, component usage guidelines, where to find things in Figma. The CTO’s direction was to keep it practical, so I focused on what a developer would actually open and reference during a build, rather than writing a full specification library that nobody would maintain.

Over time, the system stopped needing explanation. Questions about font sizes and padding values stopped coming. The shared language between design and development was in place, and it held.

Two years after the first version was live, the system is still active and still growing. The product has changed significantly in that time. New flows, new components, new surfaces. Each addition went through the system first. Consistency is no longer something the team negotiates. It is built into the process.

The most significant evolution came as AI-assisted development tools became part of the workflow. I extended the design system to be compatible with Claude Code. The component structure and naming conventions are now organized so that developers can generate UI programmatically and stay within the design language without manual checks. A system that started as a way to standardize buttons and colors became part of an AI-augmented build pipeline.

The speed gains came from removing ambiguity at every stage of the build process. Developers no longer interpret handoffs. They read values directly from Figma. Design reviews take less time because implementations land closer to specification on the first pass. When a new component is needed, there is a defined process for adding it to the library rather than making a one-off decision that creates new inconsistency.

The consistency improvement is visible across the product. Fifteen years of accumulated variation is being progressively replaced by a single reference point, one screen at a time. That is not a change that happens all at once. It happens every time a flow is redesigned, a feature is added, or a page is rebuilt on top of the system’s foundations.

The clearest signal that the system works: the team no longer questions whether to use it. It is the starting point for everything they build.

The hardest part of building a design system from zero is not the design work. It is the education. I spent as much time explaining why consistency matters as I did building components. That was the right investment. Adoption requires understanding, and understanding takes patience. Pushing on a 1px font size difference in week three of a new job is uncomfortable. It is also necessary, and it compounds over time.

Building the system in parallel with live project work was both a constraint and an advantage. The constraint was obvious: the timeline stretched. A system built in a dedicated sprint would have been more complete earlier. The advantage was that every component was built because something real needed it. Nothing was hypothetical. The system stayed grounded in actual use cases rather than anticipated ones, which made adoption easier because the components already matched what the team was building.

Extending the system for AI tooling was a decision I made proactively. No one asked for it. Staying ahead of where the team is heading, rather than behind where they have been, is how infrastructure work creates lasting value.

The immediate focus is deepening the AI integration. As Claude Code and similar tools become more embedded in the development workflow, the system’s naming structure and component organization need to stay aligned with how those tools interpret and generate code. That is an ongoing process, not a one-time update.

The second priority is documentation depth. The current Notion setup covers the essentials well for the current team. As Stuvia grows and new developers join, more thorough usage guidelines will reduce the time it takes for someone new to get up to speed and contribute to the system correctly from day one.

The design system is no longer a project. It is infrastructure. The work now is maintaining it, evolving it, and making sure it scales alongside the product and the team that depends on it every day.