A month on a ready-made library, then a design system of our own

Context: a design system for a public-sector HR platform Role: one of two designers on the system, at a design studio Team: two designers, the studio’s art director, about 20 developers (my estimate) When: 2025–2026, in active development

I went through 24 components of the library and wrote down what each one lacked. The notes repeated from component to component: spacing was not in tokens, there was no token for stroke width or for the hover background, typography was not in tokens, and icon color and size had no tokens either. Some components had to be detached before we could use them at all.

The library file confirms this. It has 2,462 variables but no breakpoints, no z-index values and no text styles. The button there is three separate component sets, one per size, with 655 variants each.

For the product screens, three things were missing: settings for a table cell with a second line and an avatar, a vacation card component, and tokens and settings for our version of the header.

I put one modal window into two columns: in one it is built as in our concept, in the other with the library. I also made a table of button settings with three marks: a token for each size, one token for all sizes, and no token.

Then the question went to the client’s leadership, and they decided that we would build our own system.

The second designer and I came up with the token scheme together. 208 role tokens are built on a palette of 153 colors, and each role has a light and a dark value. A separate collection of 138 variables switches typography and the grid between three screen widths: from 1280, from 768 to 1279, and up to 767. Another 105 variables hold the base numbers: spacing, sizes, radii, durations, z-index values and breakpoints. The system also has 30 text styles.

We have no component-level tokens. A component takes a role token directly. We chose this to build the system faster and to be able to extend it to other products later. So far two levels have always been enough. New components are quick to build, and I think the missing third level is the reason.

The header and navigation are my components. The header has to fit many links. It has versions for three screen widths, a dropdown menu with one to four columns, and a bottom sheet on a phone. In the file this is 7 component sets and 26 variants.

We looked at how other services solve this and agreed on one version as a team.

I built most of the basic components, and the button is one of them. Ours is one component set with 234 variants. The library had three sets, one per size, with 655 variants each. The button page also has usage rules: when to use it, anatomy, hierarchy, tone and placement. I wrote them together with the second designer.

Each component page has a status in its name: planned, in progress, needs review, or deprecated. The studio’s art director reviews a component first. Then we go through it with the developers on several calls. After that it either goes back for changes or counts as done. The developers use the same token names as in Figma.

The developers get the variables as a file exported from Figma, and they keep their own component library in code, built to match the system. When a component changes, we publish the library update in Figma and write in the team chat what changed. Besides the two of us, other designers at the studio build screens with the system.

Claude works directly in Figma, in our working account. For each component it makes the base and the property names, and I set up the rest myself. Most often I remove extra states, and sometimes I change the content of a component. I checked all of this work several times. I also used AI to compare other design systems.

The product is in active development, and the developers have already built screens with the system. The product file has 919 screens.

To see where the components come from, I counted the components placed directly on the screens of the workplace page. Of the 1,171 components, 1,071 are system components (I matched them by name), and 825 of those are table cells. 94 come from other linked files, such as the icon kit, and 6 are local. On the feed page the post, the comment thread and the post composer are still local blocks of the product, and they are in development.

My work now is mostly product screens built from the system, and I add the states that are still missing. On these screens I no longer stop to find out which color, type token or corner radius to use.

We took the color palette from another system, and in some places elements blend with the background. One example is the “working day” badge in the calendar card: its text has a contrast of 6.5 against the badge fill, but the fill has only 1.05 against the card background (my count from the file values). The alpha values also did not come out the way I wanted.

The file has no “done” status, so finished components still say “needs review”.

Next time I would work out the color palette in more depth and not take a ready-made one.

Next case: A robotics marketplace, designed alone in three months

All work · CV · hello@eugenesolomatin.com · Telegram