Six months ago I opened Figma file for first time at VALK and felt something I did not expect. Not excitement. Just confusion.
The file had no structure. Components were scattered without any naming logic. Colors were hardcoded everywhere, not variables, just hex values copied and pasted into each element. Some screens were designed in Sketch and then exported as images and placed directly into Figma. Someone had clearly tried to make interface look more professional at some point, but result was patchwork of decisions that did not talk to each other.
This was the MVP. Functional, technically. From design perspective, it was starting point for everything.
I had been at Spacecode agency for two years before VALK. At agency, design system was already there when I joined. Somebody else made all difficult decisions, naming conventions, grid structure, component hierarchy. I worked inside established system. I complained sometimes that system was limiting, but I did not appreciate what it meant to have one until I arrived somewhere that did not.
What I inherited
The product at this point was deal management platform for institutional investors. Complex tables, data rooms, investor documents, financial reporting. Not simple consumer application with five screens. Dozens of flows, many edge cases, and user base that does not forgive mistakes, investment managers, compliance officers, people who care very much about precision.
The engineer-built interface worked. Buttons clicked, data loaded, forms submitted. But it was interface built by people whose mental model was the code, not the user. Information hierarchy made sense from database perspective. It did not make sense from human perspective.
Typography was inconsistent. In some places body text was 14px, in other places 13px, in other places 15px. No reason for any of these choices. Spacing between elements followed no grid. Some cards had 16px padding, some had 20px, some had 24px, all on same page.
For developer, these details do not matter much. Code is code. For designer who needs to create coherent system from this, every inconsistency is either problem to solve or problem to accept.
First instinct was wrong
My first instinct was to stop everything and build proper design system before touching any screens. Define tokens. Name colors. Create spacing scale. Build component library. Then design.
This is wrong approach. I know this now.
I spent almost six weeks trying to create complete foundation before designing actual product. I made beautiful token documentation in Figma. I wrote naming conventions. I created color palette with semantic names, color-primary, color-danger, color-surface. I built button component with all variants.
And then I had design system for product I did not understand yet.
The problem with building system first is that you do not know what system you need. Every decision you make is abstract. You name color “primary” but you do not yet know all contexts where primary color will be used. You build button component but you have not yet seen all the edge cases that will force you to add fifth variant you did not plan for.
After six weeks I threw away most of this work. Some decisions survived, but most of the early system was built on assumptions about product that turned out to be wrong.
What actually worked: pages first
After failed system-first approach, I changed method. I started designing individual pages with obsessive attention to detail, not thinking about reusability yet. Just making each screen as good as it could be.
I spent probably three days on single table component. Financial data tables in enterprise product have many states, empty, loading, sorted, filtered, paginated, error. Row with action. Row without action. Expandable row. And within each state, many combinations.
I documented all of these. Every variant, every edge case. For each page I did same thing.
Slowly, after two months, patterns started to appear. I noticed I was making same table component over and over with small differences. Button styles were same across all pages. Spacing decisions I made on page one were becoming unconscious standard for pages that came after.
Design system emerged from this. It was not planned, it was discovered.
This approach has name. I learned later it is called “extract, not prescribe.” You design real things, then extract the patterns into system. You do not prescribe patterns before you have evidence for them. For someone coming from agency where system already existed, this was uncomfortable. It felt wrong to copy component from one page to another without having proper component library. But it was correct approach for where we were.
Figma organization for one person
When you are solo designer in startup, Figma organization matters more than people think. Not because you need to share files with other designers, there are no other designers. But because you will return to files you made six months ago and need to understand them immediately.
My Figma structure at VALK went through three iterations.
First iteration: one big file for everything. This is terrible. Do not do this. Second iteration was separate file per product area, which was better, but component sharing became problem. If I updated button component in one file, I had to manually update it in others.
Third iteration, which I am still using now: two files. One “master” file that contains all components, tokens, and shared styles. One file per product page or flow that uses instances from master. Updates in master propagate everywhere.
For component naming, I adopted convention that I now defend very strongly. Every component has name in this pattern: Category/Subcategory/Variant/State. So button is not called “button”; it is called Action/Button/Primary/Default or Action/Button/Primary/Hover. Table row is Data/Table/Row/Expandable.
This feels excessive at first. But when you have fifty components and need to find specific one at 11pm before deadline, you appreciate the structure.
Color styles follow different convention. Every color token has two names, technical name and semantic name. I use semantic name in all actual designs: Color/Surface/Background, Color/Text/Secondary, Color/Status/Error. Technical names exist only in master token documentation.
Getting the dev team to actually follow specifications
This was, honestly, harder problem than building the system.
At Spacecode, handoff process was established. Developers knew to look at Figma, knew what redlines meant. They had been doing it for years before I arrived. At VALK, developers did not have strong culture of checking design specifications in beginning. They were building quickly, product was moving fast. Sometimes they would look at design, sometimes they would make their own decisions about spacing or color or behavior.
I do not blame them for this. It is natural in early startup where design is often treated as last step before shipping, not first step in planning.
What changed it was not confrontation. I do not like confrontation and I also did not think it would work. What changed it was making specifications impossible to ignore, making design so detailed that following it was easier than making own decisions.
I started writing very specific Figma notes on every component. Exact CSS values, interaction behavior, hover state timing, disabled state rules. I made Figma prototype in Principle for complex interactions so developer could see exactly what animation should look like. And I started joining technical discussions earlier, when frontend engineer was about to build new feature, I would bring Figma file to that conversation before any code was written. When design is shown before coding starts, developer thinks about implementation while looking at design. When design is shown after coding starts, developer is defending work already done.
Our frontend engineer Alex told me at some point that specific Figma annotations saved him maybe one hour per week because he did not have to guess or send questions. Small thing, but it built trust.
What I got wrong about scale
When I was building component library, I made mistake of trying to create every possible variant immediately. Better to have everything ready, I thought, so I do not have to go back and update component later.
Result was button component with eleven variants, most of which we never used.
Unused components are not neutral. They take time to maintain. When you update design language, you update every variant. When someone new looks at your system, they wonder why there are eleven button types and which one to use. Complexity creates confusion even when it is hidden in component library.
Better approach: build what you need, when you need it. Do not preemptively build.
I read something from designer at large company around this time that stayed with me: “A design system is not a dictionary where you put in all possible words. It is grammar, rules that let you make new words correctly when you need them.”
I think this is right.
Six months in, honest assessment
I am writing this from my apartment in Russia. I came back here after Bali in March when COVID made continuing remote travel complicated. Less movement, more deep work, it has actually been good for focus.
The design system at VALK is now functional. Not perfect, but functional. Consistent typography, spacing grid, color system with proper semantic naming. Component library covers probably 70% of UI elements we use regularly.
More important than the system itself: the product looks like product now. There is visual logic. Investor who opens deal page sees same design language as one who is looking at portfolio dashboard. This sounds obvious but it is not obvious when you are building feature by feature in startup.
What I would tell myself six months ago: do not start with system. Start with pages. Let system find you through repetition. Documentation is not bureaucracy, it is communication with future version of yourself and with developers who need to implement your work. Perfect component library that ships in four months is worse than good-enough component library that ships in four weeks.
And the most uncomfortable truth: when you are sole designer at startup, you will spend significant time on things that are not product design. Pitch decks. Marketing materials. Social media graphics. This will feel wrong if you care deeply about product. But resisting it wastes energy better spent elsewhere.
The component library is not finished. Probably it is never finished. But it is solid enough to build on, and that is what matters at this stage.
Originally published on kargaev.me. Imported to blog.deeflect.com archive.