Pekka Oskari Puhakka 反思设计系统变体膨胀与 LLM 治理潜力

Almost eight years ago, I started working on a design system that I got the opportunity to revisit just a few years later. The second round became as big a push with far fewer people. Now, three years after ending the work I’m finally ready to share that experience.

My thesis:

• A rigid design kit is a cache of design decisions, prone to becoming obsolete with the requirements constantly evolving.
• Documenting practices and boundaries leaves powerless responsibility for upholding coherence to designers and developers.
• Governing an LLM skill could be a better basis for an evolving design system than components, code or documentation alone.

Back when I wrote my first Medium article about design systems, I was in the middle of a year spent extending a design system towards more consumer-driven businesses. Since then, I have wandered off to design other types of products and services, some design languages too. I changed employers twice before I got handed the chance to return to work on the next version of the very same design system I had stopped working on a few years prior. That work extended for another 12–18 months, after which it has continued its life without me knowing much about it. Almost ever since, I’ve had this article as an early draft that I’m now ready to fill in. Only now, with the latest technological advances, do I think I have found a way around the biggest challenge with the work delivered: it simply grew massive by having too many variants to answer the backing requirements.

Where my first leg was about expanding the design language to new market segments, the task for the second leg was to consolidate various design kits into a single kit. First expanding, then converging. This is nothing new for a design consultant such yours truly.

The concepts from my previous work for this client had helped the design core group to form a “Style evolution” booklet guiding future projects, after which the core group dissolved as the company restructured itself. Since then the business units had taken it forward to form their own design kits, some ending up being more advanced than others. In practice the design had divided into multiple design kits, with each business unit aiming for the future cloud-based software on its own. Each design kit relied on the same core tokens and design drivers from earlier. What differed from earlier was a design council with representatives from each business unit responsible for design decisions, instead of a single centralised group.

Personally it was delightful to see that the concepts from the first leg had lived on. But unlike earlier, it seemed that the goal of having a single code-based truth had been abandoned in favour of aligning the work through design phases. This felt odd, since their move to browser-based cloud applications would favour a shared codebase compared to the embedded nature of software from earlier, built on three code frameworks: WPF, Angular and React. Given the magnitude and scale, simply focusing on the design aspect might have seemed the more accessible path to take. But in retrospect, the intricate variations and complexity would have been managed much more easily in code. Especially now, when an LLM helps draft many of these.

The time was not ready for any of this when we started the consolidation work in 2022. Our task was to consolidate the individual kits manually into a single company-wide design kit. During less than a year of crafting, with help from a few colleagues at DK&A, we ended up designing and documenting around 40 components, applicable to theming and mode switching through native Figma library swaps. There was a structure of core components distributed to each design kit file, making the whole system a bit more manageable, but also prone to break. With everything wired, the overall structure delivered was comprehensive but demanding to govern. We even delivered skeleton models of the components to be handled similarly with a library swap. The end result was a sound number of components with a massive number of variations and properties, such as Focus, baked into each of them. Not hundreds of variants, but nearly two thousand in total.

Variations themselves had been a staple of the system from the get-go. To handle the multiple different size variants in Figma you still had to have multiple assets to apply these values feasibly. This was the main cause of massiveness with the kit, which in coded components could be overcome with a simple set of token variables. When we started the project, Figma already had boolean component properties to simply turn items on and off within the components. At its heaviest the working file held around 4,000 variants, with the delivered design kit holding 1,786 variants. A reduction of just over half. With typography variables launched in April 2024, less than a year after our project ended, most of the size variants could have been handled similarly to tokens. The 1,786 variants could have been cut to as little as a fifth by just handling the size and typography variations with variables alone.

The most absurd example of all the delivered components was the button. In total 260 variants of it. Three behaviours: default, split and toggle all divided into 5 different sizes with a varying number of properties in them. Only 15 of those needed real thinking: text sizes, spacing, proportions. The other 245 were arithmetic. Arithmetic can express a decision. It cannot make one.

Not all of the roughly 40 components were similarly burdened with variants. Some could be mostly handled by boolean component properties, others being complex for the sake of flexing Figma to its limits. We even experimented with a card component, which in the end was deemed too impractical for scaling due to the sub-component structure. Looking back, it would have been much easier to describe the desired function as a prompt, but it would surely have left some memorable moments in problem solving unexperienced.

Nonetheless, since then I’ve heavily streamlined the design kits I’ve worked with. Thinking from a lean, progressive perspective rather than aiming to bake all the requirements in. Nowadays the components can be very crude, but in their simplicity capable of taking in many variations without sacrificing the base functionality. Figma has since launched slots: virtually fully editable frames inside a component that users are free to play around with without meddling with the core component. Even the card component, which was deemed too impractical earlier, became feasible just a few years later.

During the project Figma slots were only dreamed of and sub-components were the standard way forward. This was a technical limitation more than a design decision. Had it been possible to approach the task with a more lightweight structure and fewer variables, I would have leaned even then towards such a structure. This would have asked more of the documentation setting boundaries for edits, and of the stakeholders managing them. Having an LLM in the mix, you could have baked the limits into a skill, but would testing the limits have been a less demanding task than crafting the needed variants? Maybe, but needs confirmation.

Replacing the native Figma library swap with Figma’s native variables for theming would have made the total number of system files a lot lighter. We know this because Figma released variable theming midway through the process. We tested it, but could not pivot the system to use it. It was too late to turn the ship around and start refactoring everything. In a third iteration, variable theming would be an obvious choice. Though the skeleton components would then need to be applied differently. I’m questioning whether they were required to be supported in Figma at all.

For a design council, a true cross-organisation ownership requires a lot from the individual stakeholders and their communication skills. An almost altruistic mindset towards decision making is needed to overcome otherwise natural group dynamics. Another key for a global design council to function is to have a shared culture taking into account the diversity of team members in different time zones, cultural environments or calendar routines. Democratic decision-making needs time, so a slower pace should not be made an issue. Too fast movements and non-holistic design choices become a mess over time. Group governing design is always a delicate process as designers tend to fall in love with their creations. Me being not much different.

We were the hired hands doing the actual consolidation work, so much of the decision-making was in the end in our hands. You need to be hands-deep in solving the challenges to be able to call the shots. And to do a lot of lobbying to get stakeholders invested in design decisions. Still, it was consolidation work and a single design kit could only bend in so many ways back in 2023.

Though the consolidation task was a challenge, by no means do I regret doing it. It has shaped my approach for similar tasks ever since, something I touched in on my previous article. With what is possible nowadays, I’m able to put what I learned into action in my design process.

A lot has been written in hindsight already, but I want to conclude this writing with a “what if”. Technically I have already brought up several Figma-specific updates that would allow building things differently nowadays. But it has to be questioned: does anybody use Figma anymore? Reading almost any designer’s LinkedIn would incline so. I have long been inclined to think that a true design system only lives in code format. Anything else is just middleware. But nowadays, when code and design can be produced on the fly, is code just an output format among others? Compared with Figma assets, it is still a step closer to the end users. But is it the single source of truth anymore? If an LLM could be used to produce components and layouts as well as design assets for any given design software through MCP, should it be considered the single source of truth instead? Another project to rebuild an existing system for the LLM age would be needed to prove any of this. If not for the very same design system, then any other of similar size. You can call me up.

Next, I will revisit my first Medium article and write about how design systems could become the best enablers instead of limiting designers’ freedom in problem solving. Thanks to my ex-colleague Konrad Wysokinski for fact-checking this article and to Claude for the proofreading and sparring.