There is a specific kind of frustration that comes from looking at your own work and realizing it does not function the way you intended. Not broken, just not working. Two years ago, I built a design system for VALK from the beginning, including components, tokens, documentation, spacing rules, color semantics, and typography scale. Last month, I went through the actual product screens in production and compared them against what lives in Figma. They do not match as much as I thought they would. working I am writing this from a rented place in Krasnaya Polyana, a small mountain town in southern Russia near Sochi. It is quiet here, good for thinking. I came to clear my head after a long stretch of work, and instead, I keep opening Figma and staring at the gap between what the system says and what ships. This article is not about how to build a design system. There are many good resources for that. This is about what happens after you build it, specifically when you are the only designer on the team. Two years of systematic thinking, delivered inconsistently. When I joined VALK in late 2019, there was no design system. No design anything, really. I started from scratch, which sounds exciting, and in some ways it was. I could make decisions without inheriting someone else's bad choices. By mid-2020, I had a working component library in Figma. By the end of 2020, it was well-documented. By mid-2021, it covered almost every UI pattern we needed, data tables, form elements, modal variants, notification states, empty states, financial charts styling, and investor card layouts. I was proud of it. But over time, something strange happened. The system was comprehensive, and the product was inconsistent. Both things were true at the same time. Some buttons in production have a different border-radius than the design spec. Some form labels use a slightly different gray than what I defined. Spacing between elements in certain sections is close but not exact, 14px where it should be 16px. Nothing catastrophic. But enough that when you look carefully, the product does not feel as precise as it should. The code and the components diverged. Gradually, quietly, without any single moment of failure. The documentation nobody reads. I wrote good documentation. I know this because I spent real time on it, explaining not just what each component is, but why it works a certain way. Why the primary button has that specific padding. Why we use that particular blue and not the one that looks similar. The reasoning behind decisions. why Our frontend engineer has not read most of it. I say this not as criticism; he is good at his job, and he works fast. But the documentation lives in Figma, and when you are writing code, you are not in Figma. You are in your editor, you are in the codebase, you are looking at existing components that are already there. That is your reference, not some nested Figma page with annotations. I realized this late. I thought documentation was a solution. It is not a solution; it is evidence that you thought carefully. That is different. The people who read design documentation are other designers. Developers read code. This sounds obvious when you write it out, but when I was building the system, I was thinking like a designer, not like a developer. The Solo Designer Paradox When you are the only designer, you build the system, and you also break the system. You are the only person who could enforce the rules, and you are also the person most likely to ignore them when you are moving fast. There were times when I was designing a new feature quickly, and I made a component that did not properly follow the system. Maybe I created a new variant instead of using an existing one. Maybe I used color in a way that was not quite right for the context. In a larger team, another designer might catch this in review. At VALK, there is only me. So the mistake goes into the file, and sometimes it goes into production because my Figma frame became the reference. At Spacecode, the agency in Moscow where I worked before this, there was a dedicated person whose primary job was maintaining the design system. She was not designing product features; she was reviewing components, keeping the library clean, and doing audits. That structure works. When the system has an owner who is separate from the people building it, the system stays healthier. At VALK, I am the owner and the primary user. The conflict of interest is permanent. Figma Components vs. Coded Components I have a Figma component. It has variants, auto layout, handles different states, default, hover, focus, error, and disabled. It looks correct in every combination I tested. The developer implements this component in React. The implementation is based on looking at the Figma component and understanding its behavior. But interpretation is involved. And every time I update the Figma component, the coded component does not automatically update. Someone has to notice that I changed something and then decide if the code needs to change too. Nobody has that job at VALK. I do not always announce small design system changes. The developer does not always check the Figma library after every update. So they drift. An extra state I added that was never coded. A spacing adjustment I made when refining the grid. A new color semantic I introduced. Each seems minor. Together for over two years, they create a real gap between the design system and the actual product. I have seen solutions to this, design tokens that feed directly into code, tools that try to sync Figma variables with CSS variables, and processes where every component change triggers a development task. These solutions require organizational buy-in and time investment from developers. In a small startup moving fast, that investment is hard to justify. The product keeps moving, and the system maintenance falls behind. Naming conventions that made sense to me. I named things the way a designer thinks about them. Colors like color-primary-action, color-feedback-success, color-text-secondary. Spacing tokens like space-component-padding-m, space-layout-section. These names describe the purpose, not the value, which is the correct approach according to everything I read about design tokens. color-primary-action color-feedback-success color-text-secondary space-component-padding-m space-layout-section But when the developer looks at this and then looks at what actually exists in the codebase, which predates some of these naming decisions, the mapping is not always clear. The coded variables have different names because they were named earlier, before I standardized my system. Now there are two naming conventions existing in parallel. The design says one thing, the code says something different; they refer to the same value, but you have to already know this. I should have involved the frontend engineer in creating the naming conventions from the beginning. He is the one who has to live inside the code. If the names feel foreign to him, he will name things his own way, which is exactly what happened. The political reality of design systems. I avoided thinking about this for a long time, but the real problem with our design system is not technical. It is political. A design system is a set of rules. Rules only have power if there is some enforcement mechanism. In a design team of eight people at a larger company, enforcement comes from peer review, from design leadership, and from cultural expectations that you use the system. When you deviate, someone notices. In a startup with one designer and one frontend engineer, there is no enforcement mechanism except my own attention. And my attention is spread across product design, pitch decks, social media graphics, investor materials, and many other things that have nothing to do with maintaining component consistency. So when the developer needs to ship a feature quickly, and the right component does not quite cover the case, he improvises. And I am often not looking carefully enough to catch it. The improvisation becomes the precedent. Other similar features get built the same way because now, that is what exists in the code. The system erodes not through anyone's failure, just through the natural pressure of shipping product at a startup pace with a very small team. What I would do differently. If I could start over, the first thing I would do is sit down with the developer before writing a single component. Not to show him the design system and explain it. To ask him how he builds things. What naming makes sense to him. What patterns he reaches for naturally. What the existing codebase already has that I should preserve rather than replace. Then I would build the system around those answers. Designers build design systems for designers. The artifacts are Figma files, component pages, usage guidelines. But the actual users of the system, the people whose work is most directly constrained by whether they follow it, are the developers. They are the ones translating it into real product. Building design system without deeply understanding how your developers work is like designing product without understanding how your users work. You make reasonable assumptions, and then you are surprised when behavior does not match expectations. I also think I built too much too fast. Smaller, more stable system would have been better than comprehensive one that overreached. When the system covers everything, it is harder to maintain everything. Some of our components are used constantly and are very solid. Others were built speculatively for cases that barely exist in the product. Those are the ones most out of sync. What is actually working. The core components, button variants, form system, data table, modal pattern, color palette, are stable and mostly consistent in production. When I look at the main flows of the product, they feel coherent. Users navigating the core journeys have a consistent experience. The system succeeded where I invested most consistently and where the developer and I had most direct conversations about implementation. The problems are at the edges, new features, edge cases, and rarely-used components. That tells me the mechanism for a working design system is not documentation. It is a conversation. Ongoing, regular conversation between designer and developer about specific components and how they translate to code. Not one-time handoff. Not the Figma library and hope that the developer finds the right components. Where things stand now. I think the system needs a partial reset. Not a full rebuild, that would be wasteful. But an audit where I identify components that are actually in use and well-implemented, and let go of the parts that exist in Figma but nowhere else. I also want to try exporting design tokens in a format the developer can actually use directly, something we agree on together, rather than something I designed and handed over. A few hours of coordination, but it might close some of that drift. The deeper lesson I am sitting with here in the mountains is that design systems are not deliverables. You do not finish them and move on. They are infrastructure, and infrastructure requires ongoing maintenance and people who are responsible for that maintenance. In a small company with one designer, that responsibility cannot be distributed, which means it will always be underpowered compared to what the system actually needs. I am not sure there is a perfect solution to this when you are solo. But understanding the actual problem, it is organizational, not technical, at least helps you stop looking in the wrong places for the fix.

Figma

Accessible Data Visualization in Fintech: Why It Matters

Portfolio

Your Design System Doesn't Work: Here's Why

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Accessible Data Visualization in Fintech: Why It Matters

The Developer Experience Tax Hidden Inside Your Design System

10 Knowledge Base Software Best Practice Examples

5 reasons to ditch the paper and start document automation

5 Software Documentation Tools That Make Managing Technical Documentation Easier

6 Ways Digital Document Management Will Empower Your Business

Accessible Data Visualization in Fintech: Why It Matters

The Developer Experience Tax Hidden Inside Your Design System

10 Knowledge Base Software Best Practice Examples

5 reasons to ditch the paper and start document automation

5 Software Documentation Tools That Make Managing Technical Documentation Easier

6 Ways Digital Document Management Will Empower Your Business

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps