Every eighteen months, with almost meteorological regularity, an authoritative article appears declaring the death of the design system. I have read the Sketch version, then the Figma version, then the AI-generated component library version, then the zero-config CSS framework version. Every time the funeral is premature. Every time there is something genuinely new in the problem being identified, and something wrong in the diagnosis.
I have built enterprise design systems for ten years. Tarvos for Exein — a design system for an IoT security infrastructure that had to be readable by firmware engineers and understandable by the board. The component system for Vodafone Italia. Frameworks for legal, medical, and financial products. I have seen what survives and what does not. And I will say this: the eulogists are always wrong about the patient, but almost always right about the diagnosis.
The pattern that repeats: new tools, same accusations
The recurring accusation is that design systems are too rigid, too slow, too disconnected from the reality of daily development. That product teams work around them instead of using them. That the Figma library is always three versions behind the code. That nobody knows who owns a component when it needs updating. That the Notion documentation was accurate the day it was written and useless six months later.
All true. But these are not design system problems — they are governance problems. And governance does not improve by switching tools. Moving from Sketch to Figma did not solve the stale documentation problem. Moving to Storybook did not solve the question of who makes the call when product and design system contradict each other. Moving to design tokens did not solve the question of who updates the tokens when the brand changes.
What dies cyclically is not the design system. It is the illusion that building it once means you have solved it.
What dies cyclically is not the design system. It is the illusion that building it once means you have solved it.
What is genuinely dead: the monolithic model
There is one thing that is genuinely dead, at least for mid-to-large enterprise teams. It is the model I call "the one ring" — a centralised system that claims to cover every product, every surface, every use case across the entire organisation.
The issue is not conceptual but operational. A centralised team cannot know every product well enough to make sensible design system decisions for all of them. A system generic enough to work everywhere ends up generic enough to be optimal nowhere. And every exception requested by a product team becomes a ticket sitting in a queue, generating frustration and unofficial forks that nobody documents.
The model I have seen work best over the last three years is federated: a small core of shared decisions — typography, semantic colours, spacing scale, mandatory accessibility patterns — and then a documented extension system that allows product teams to build their specific components while respecting the core contract. Not total freedom. Not total control. A clear perimeter with autonomy inside it.
What generative AI has actually changed
The promise was: with AI, generating components becomes instant, the design system becomes superfluous. The reality I have observed is more interesting and less dramatic.
Generative AI has made the creation of component variants and prototypes faster. But it has not solved — and could not solve — the upstream problem: deciding which components exist, what they do, which patterns they promote and which they exclude, how they behave on error, which accessibility requirements they meet. These are governance decisions that require organisational context that a generative model does not have.
What I have seen happen with teams that adopt generative AI without a design system: the speed of component production increases, but so does divergence. Every engineer generates their own slightly different modal component. Visual consistency decreases. Technical debt grows silently. And six months later someone like me needs to run an audit to restore order.
Paradoxically, generative AI has made the design system more necessary, not less. Because without an authoritative reference specification, rapid generation rapidly produces divergence.
The design system in 2025: smaller surface, stronger tokens
The enterprise design system I build today is structurally different from what I built in 2018. Not because the philosophy has changed, but because I have learned where to concentrate investment to maximise return.
The system's surface area is smaller. Fewer components, but better documented and more stable. The rule I use: a component enters the system only when it appears in at least three different products or contexts. Before that, it lives as a local solution. This drastically reduces maintenance burden and raises the average quality of components in the system.
Semantic tokens are the core. Not color-blue-500 but color-action-primary, color-feedback-error, color-surface-elevated. Tokens that encode semantic decisions, not visual values. When the brand changes — and it always does — the underlying values are updated, not the system rewritten. For Tarvos I used this approach and the dark theme migration took two days of work instead of three weeks.
Documentation lives in the code, not in Notion. Not because Notion is the wrong tool, but because documentation separated from the source of truth always becomes stale. Components are documented via Storybook with arguments, use cases and accessibility behaviours. If the component changes, the documentation changes with it — because it is the same file.
A component enters the system only when it appears in at least three different products. Before that, it lives as a local solution.
Governance: the only thing that truly matters
I have saved the most important thing for last, because it is the most tedious to read and the most critical to get right. Design system governance answers four questions, and if you have not answered all four before you start building, the system will fail regardless of its technical quality.
Who owns the system? Not a generic team — a specific person who responds when a component has a critical bug at 11pm on a Thursday. In the organisations where I have seen design systems survive longest, there is always a person with clear ownership, even if the work is distributed.
How are decisions made when the system conflicts with a product need? You need a documented process, not a case-by-case discussion. The answer could be a committee, an asynchronous process on GitHub, or a simple rule ("the system always wins on layout and typography, the product wins on specific flows"). What does not work is having no answer.
How is adoption measured? If you do not measure, you do not know whether the system is being used or bypassed. The metrics I use: component coverage (how many surfaces use system components vs custom ones), average implementation time for a new feature vs the pre-system benchmark, number of visual divergences flagged in design reviews. They are not perfect metrics, but they are better than nothing.
How is the system updated without breaking products? Semantic versioning applied to component libraries is not merely a technical detail — it is a promise to product teams that they can upgrade in a controlled way. If every update risks breaking something without warning, the system gets frozen out of fear and then abandoned.
Where this is heading
The next change I see coming is the use of AI for automatic consistency checking: tools that analyse production screenshots and identify where components diverge from the design system, without requiring a manual review. Technically it is already possible — some teams are experimenting with vision model approaches and automated visual tests. It is not yet an industry standard, but it will be.
The other trend I see is the encoding of design decisions directly into tokens, not just values. Tokens that carry metadata about context of use, contrast requirements, accessibility constraints. A token is not just a colour — it is a colour with its rules. This makes the system smarter and harder to misuse through carelessness.
The design system is not dead. It has evolved, as it always has. And those who declared the premature funeral now find themselves working with teams that have lost three years of visual consistency and are forced to rebuild from scratch what they dismantled chasing the trend.
If you are building or redesigning a design system for an enterprise team — especially if governance is the critical bottleneck — I can help you set the right structure before writing a single line of code. The first conversation is free.
Ogni diciotto mesi, con una regolarità quasi meteorologica, compare un articolo autorevole che dichiara la morte del design system. Ho letto la versione Sketch, poi la versione Figma, poi la versione libreria di componenti generata dall'AI, poi la versione framework CSS zero-config. Ogni volta il funerale è prematuro. Ogni volta c'è qualcosa di genuinamente nuovo nel problema identificato, e qualcosa di sbagliato nella diagnosi.
Ho costruito design system enterprise per dieci anni. Tarvos per Exein — un design system per un'infrastruttura di sicurezza IoT che doveva essere leggibile dagli ingegneri firmware e comprensibile dal board. Il sistema di componenti per Vodafone Italia. Framework per prodotti legali, medicali e finanziari. Ho visto cosa sopravvive e cosa no. E dirò questo: chi scrive i necrologi sbaglia sempre riguardo al paziente, ma quasi sempre ha ragione nella diagnosi.
Il pattern che si ripete: nuovi strumenti, stesse accuse
L'accusa ricorrente è che i design system sono troppo rigidi, troppo lenti, troppo scollegati dalla realtà dello sviluppo quotidiano. Che i team di prodotto ci lavorano intorno invece di usarli. Che la libreria Figma è sempre tre versioni indietro rispetto al codice. Che nessuno sa chi possiede un componente quando deve essere aggiornato. Che la documentazione su Notion era accurata il giorno in cui è stata scritta e inutile sei mesi dopo.
Tutto vero. Ma questi non sono problemi di design system — sono problemi di governance. E la governance non migliora cambiando strumenti. Passare da Sketch a Figma non ha risolto il problema della documentazione obsoleta. Passare a Storybook non ha risolto la questione di chi decide quando prodotto e design system si contraddicono. Passare ai design token non ha risolto la questione di chi aggiorna i token quando il brand cambia.
Ciò che muore ciclicamente non è il design system. È l'illusione che costruirlo una volta significhi averlo risolto.
Ciò che muore ciclicamente non è il design system. È l'illusione che costruirlo una volta significhi averlo risolto.
Cosa è davvero morto: il modello monolitico
C'è una cosa che è davvero morta, almeno per i team enterprise di medie e grandi dimensioni. È il modello che chiamo "l'unico anello" — un sistema centralizzato che pretende di coprire ogni prodotto, ogni superficie, ogni caso d'uso in tutta l'organizzazione.
Il problema non è concettuale ma operativo. Un team centralizzato non può conoscere ogni prodotto abbastanza bene da prendere decisioni sensate sul design system per tutti. Un sistema abbastanza generico da funzionare ovunque finisce per essere abbastanza generico da non essere ottimale da nessuna parte. E ogni eccezione richiesta da un team di prodotto diventa un ticket in coda, che genera frustrazione e fork non ufficiali che nessuno documenta.
Il modello che ho visto funzionare meglio negli ultimi tre anni è federato: un nucleo ristretto di decisioni condivise — tipografia, colori semantici, scala di spaziatura, pattern di accessibilità obbligatori — e poi un sistema di estensione documentato che permette ai team di prodotto di costruire i propri componenti specifici rispettando il contratto di base. Non libertà totale. Non controllo totale. Un perimetro chiaro con autonomia al suo interno.
Cosa ha davvero cambiato l'AI generativa
La promessa era: con l'AI, generare componenti diventa istantaneo, il design system diventa superfluo. La realtà che ho osservato è più interessante e meno drammatica.
L'AI generativa ha reso più veloce la creazione di varianti di componenti e prototipi. Ma non ha risolto — e non poteva risolvere — il problema a monte: decidere quali componenti esistono, cosa fanno, quali pattern promuovono e quali escludono, come si comportano in caso di errore, quali requisiti di accessibilità soddisfano. Queste sono decisioni di governance che richiedono contesto organizzativo che un modello generativo non ha.
Quello che ho visto succedere con i team che adottano l'AI generativa senza un design system: la velocità di produzione dei componenti aumenta, ma aumenta anche la divergenza. Ogni ingegnere genera la propria versione leggermente diversa del componente modale. La coerenza visiva diminuisce. Il debito tecnico cresce in silenzio. E sei mesi dopo qualcuno come me deve fare un audit per ristabilire l'ordine.
Paradossalmente, l'AI generativa ha reso il design system più necessario, non meno. Perché senza una specifica di riferimento autorevole, la generazione rapida produce rapidamente divergenza.
Il design system nel 2025: superficie ridotta, token più forti
Il design system enterprise che costruisco oggi è strutturalmente diverso da quello che costruivo nel 2018. Non perché la filosofia sia cambiata, ma perché ho imparato dove concentrare l'investimento per massimizzare il ritorno.
La superficie del sistema è più piccola. Meno componenti, ma meglio documentati e più stabili. La regola che uso: un componente entra nel sistema solo quando appare in almeno tre prodotti o contesti diversi. Prima di allora, vive come soluzione locale. Questo riduce drasticamente il peso della manutenzione e alza la qualità media dei componenti nel sistema.
I token semantici sono il nucleo. Non color-blue-500 ma color-action-primary, color-feedback-error, color-surface-elevated. Token che codificano decisioni semantiche, non valori visivi. Quando il brand cambia — e succede sempre — vengono aggiornati i valori sottostanti, non riscritto il sistema. Per Tarvos ho usato questo approccio e la migrazione al tema scuro ha richiesto due giorni di lavoro invece di tre settimane.
La documentazione vive nel codice, non su Notion. Non perché Notion sia lo strumento sbagliato, ma perché la documentazione separata dalla fonte di verità diventa sempre obsoleta. I componenti sono documentati via Storybook con argomenti, casi d'uso e comportamenti di accessibilità. Se il componente cambia, la documentazione cambia con esso — perché è lo stesso file.
Un componente entra nel sistema solo quando compare in almeno tre prodotti diversi. Prima di allora, vive come soluzione locale.
La governance: l'unica cosa che conta davvero
Ho tenuto la cosa più importante per ultima, perché è la più noiosa da leggere e la più critica da fare bene. La governance del design system risponde a quattro domande, e se non le hai risposto tutte e quattro prima di iniziare a costruire, il sistema fallirà indipendentemente dalla sua qualità tecnica.
Chi possiede il sistema? Non un team generico — una persona specifica che risponde quando un componente ha un bug critico alle 23 di un giovedì. Nelle organizzazioni dove ho visto i design system sopravvivere più a lungo, c'è sempre una persona con ownership chiara, anche se il lavoro è distribuito.
Come vengono prese le decisioni quando il sistema entra in conflitto con un'esigenza di prodotto? Serve un processo documentato, non una discussione caso per caso. La risposta potrebbe essere un comitato, un processo asincrono su GitHub, o una regola semplice ("il sistema vince sempre su layout e tipografia, il prodotto vince sui flussi specifici"). Quello che non funziona è non avere una risposta.
Come si misura l'adozione? Se non misuri, non sai se il sistema viene usato o aggirato. Le metriche che uso: copertura dei componenti (quante superfici usano componenti di sistema vs componenti custom), tempo medio di implementazione di una nuova funzionalità vs il benchmark pre-sistema, numero di divergenze visive segnalate nelle design review. Non sono metriche perfette, ma sono meglio di niente.
Come si aggiorna il sistema senza rompere i prodotti? Il versioning semantico applicato alle librerie di componenti non è solo un dettaglio tecnico — è una promessa ai team di prodotto che possono aggiornare in modo controllato. Se ogni aggiornamento rischia di rompere qualcosa senza preavviso, il sistema viene congelato per paura e poi abbandonato.
Verso dove sta andando
Il prossimo cambiamento che vedo arrivare è l'uso dell'AI per il controllo automatico della coerenza: strumenti che analizzano screenshot di produzione e identificano dove i componenti divergono dal design system, senza richiedere una revisione manuale. Tecnicamente è già possibile — alcuni team stanno sperimentando approcci con modelli di visione e test visivi automatizzati. Non è ancora uno standard di settore, ma lo diventerà.
L'altra tendenza che osservo è la codifica delle decisioni di design direttamente nei token, non solo dei valori. Token che portano metadati sul contesto d'uso, i requisiti di contrasto, i vincoli di accessibilità. Un token non è solo un colore — è un colore con le sue regole. Questo rende il sistema più intelligente e più difficile da usare male per superficialità.
Il design system non è morto. Si è evoluto, come ha sempre fatto. E chi ha dichiarato il funerale prematuro si trova ora a lavorare con team che hanno perso tre anni di coerenza visiva e sono costretti a ricostruire da zero quello che hanno smantellato inseguendo la tendenza del momento.
Se stai costruendo o ridisegnando un design system per un team enterprise — specialmente se la governance è il collo di bottiglia critico — posso aiutarti a impostare la struttura giusta prima di scrivere una singola riga di codice. La prima conversazione è gratuita.
每隔十八个月，以几乎气象学般的规律性，就会出现一篇权威文章宣告设计系统的死亡。我读过Sketch版本，然后是Figma版本，然后是AI生成组件库版本，然后是零配置CSS框架版本。每次葬礼都为时过早。每次在所识别的问题中都有真正新颖的东西，而在诊断中都有错误的东西。
我为企业构建设计系统已有十年。Tarvos为Exein——一个面向IoT安全基础设施的设计系统，必须对固件工程师可读，对董事会可理解。Vodafone Italia的组件系统。法律、医疗和金融产品的框架。我见过什么能存活，什么不能。我会这样说：写讣告的人对患者总是错的，但对诊断几乎总是对的。
重复出现的模式：新工具，相同的指责
反复出现的指责是设计系统太僵化、太慢、与日常开发的现实脱节太远。产品团队绕过它们而不是使用它们。Figma库总是比代码落后三个版本。当组件需要更新时没有人知道谁拥有它。Notion文档在写作当天是准确的，六个月后就毫无用处了。
都是真的。但这些不是设计系统的问题——而是治理问题。治理不会因为换工具而改善。从Sketch切换到Figma没有解决文档过时的问题。切换到Storybook没有解决当产品和设计系统相互矛盾时谁来拍板的问题。切换到设计令牌没有解决当品牌改变时谁来更新令牌的问题。
周期性死亡的不是设计系统。而是构建一次就意味着解决了问题的幻觉。
周期性死亡的不是设计系统。而是构建一次就意味着解决了问题的幻觉。
真正已死的：单体模型
有一件事确实已经死了，至少对于中大型企业团队而言。这就是我称之为"一环"的模型——一个声称覆盖整个组织中每个产品、每个界面、每个用例的集中式系统。
问题不是概念上的，而是运营上的。一个集中团队无法对所有产品了解足够深入，以便为所有产品做出明智的设计系统决策。一个足够通用以在任何地方工作的系统，最终会通用到在任何地方都不是最优的。而每个产品团队要求的例外情况都变成了队列中的工单，产生挫折感和没有人记录的非官方分叉。
过去三年我看到效果最好的模型是联邦式的：一个小核心的共享决策——排版、语义颜色、间距比例、强制性无障碍模式——然后是一个有文档的扩展系统，允许产品团队在遵守基本契约的同时构建其特定组件。不是完全自由。不是完全控制。一个有明确边界，内部有自主权的范围。
生成式AI真正改变了什么
承诺是：有了AI，生成组件变得即时，设计系统变得多余。我观察到的现实更有趣，也不那么戏剧化。
生成式AI使组件变体和原型的创建变得更快。但它没有解决——也无法解决——上游问题：决定哪些组件存在、它们做什么、它们推广哪些模式和排除哪些模式、它们在出错时如何表现、它们满足哪些无障碍要求。这些是治理决策，需要生成模型没有的组织背景。
我看到在没有设计系统的情况下采用生成式AI的团队发生的事情：组件生产速度增加了，但差异也增加了。每个工程师生成自己略有不同的模态组件版本。视觉一致性降低。技术债务悄然增长。六个月后像我这样的人需要进行审计来恢复秩序。
矛盾的是，生成式AI使设计系统变得更必要，而不是更少。因为没有权威的参考规范，快速生成会快速产生差异。
2025年的设计系统：更小的界面，更强的令牌
我今天构建的企业设计系统在结构上与我2018年构建的不同。不是因为哲学改变了，而是因为我学会了在哪里集中投资以最大化回报。
系统的界面面积更小。更少的组件，但文档更好、更稳定。我使用的规则：组件只有在至少三个不同产品或背景中出现时才进入系统。在此之前，它作为本地解决方案存在。这大幅减少了维护负担，提高了系统中组件的平均质量。
语义令牌是核心。不是color-blue-500，而是color-action-primary、color-feedback-error、color-surface-elevated。编码语义决策而非视觉值的令牌。当品牌改变时——它总会改变——更新的是底层值，而不是重写系统。对于Tarvos，我使用了这种方法，暗色主题迁移花了两天工作，而不是三周。
文档存在于代码中，而不是Notion上。不是因为Notion是错误的工具，而是因为与事实来源分离的文档总会变得过时。组件通过Storybook记录，带有参数、用例和无障碍行为。如果组件改变，文档随之改变——因为它们是同一个文件。
组件只有在至少三个不同产品中出现时才进入系统。在此之前，它作为本地解决方案存在。
治理：唯一真正重要的事
我把最重要的东西留到最后，因为它是最无聊的阅读但最关键的做好。设计系统治理回答四个问题，如果你在开始构建之前没有回答所有四个问题，无论其技术质量如何，系统都会失败。
谁拥有系统？不是一个通用团队——而是一个具体的人，当组件在周四晚上11点出现关键错误时会响应。在我见过设计系统存活最久的组织中，始终有一个人有明确的所有权，即使工作是分布式的。
当系统与产品需求冲突时如何做决策？你需要一个有文档的流程，而不是逐案讨论。答案可以是委员会、GitHub上的异步流程，或一个简单的规则（"系统在布局和排版上总是获胜，产品在特定流程上获胜"）。没有效果的是没有答案。
如何衡量采用率？如果你不衡量，你就不知道系统是被使用还是被绕过。我使用的指标：组件覆盖率（有多少界面使用系统组件vs自定义组件）、新功能的平均实施时间vs系统前基准、设计审查中标记的视觉差异数量。它们不是完美的指标，但比没有要好。
如何在不破坏产品的情况下更新系统？应用于组件库的语义版本控制不仅仅是技术细节——它是对产品团队的承诺，他们可以以受控方式升级。如果每次更新都有在没有警告的情况下破坏某些东西的风险，系统就会因为恐惧而被冻结，然后被放弃。
这将走向何方
我看到即将到来的下一个变化是使用AI进行自动一致性检查：分析生产截图并识别组件偏离设计系统的位置的工具，无需人工审查。从技术上说这已经是可能的——一些团队正在用视觉模型方法和自动视觉测试进行实验。它还不是行业标准，但将会是。
我观察到的另一个趋势是将设计决策直接编码到令牌中，而不仅仅是值。携带使用上下文、对比度要求、无障碍约束元数据的令牌。令牌不仅仅是颜色——它是带有其规则的颜色。这使系统更智能，更难因粗心而被错误使用。
设计系统没有死。它已经进化，一如既往。那些宣布过早葬礼的人现在发现自己在与失去了三年视觉一致性的团队合作，被迫重建他们追逐趋势而拆除的东西。
如果你在为企业团队构建或重新设计设计系统——特别是如果治理是关键瓶颈——我可以帮助你在写一行代码之前设定正确的结构。第一次对话是免费的。
Alle achtzehn Monate erscheint mit nahezu meteorologischer Regelmäßigkeit ein maßgeblicher Artikel, der den Tod des Design Systems verkündet. Ich habe die Sketch-Version gelesen, dann die Figma-Version, dann die KI-generierte Komponentenbibliothek-Version, dann die Zero-Config-CSS-Framework-Version. Jedes Mal ist das Begräbnis verfrüht. Jedes Mal steckt etwas genuines Neues in dem identifizierten Problem, und etwas Falsches in der Diagnose.
Ich baue seit zehn Jahren Enterprise-Design-Systeme. Tarvos für Exein — ein Design System für eine IoT-Sicherheitsinfrastruktur, das von Firmware-Ingenieuren lesbar und vom Vorstand verständlich sein musste. Das Komponentensystem für Vodafone Italia. Frameworks für Rechts-, Medizin- und Finanzprodukte. Ich habe gesehen, was überlebt und was nicht. Und ich sage das: Die Verfasser der Nekrologe liegen beim Patienten immer falsch, aber bei der Diagnose fast immer richtig.
Das sich wiederholende Muster: Neue Tools, dieselben Vorwürfe
Der wiederkehrende Vorwurf ist, dass Design Systems zu starr, zu langsam, zu weit von der Realität der täglichen Entwicklung entfernt sind. Dass Produktteams sie umgehen, statt sie zu nutzen. Dass die Figma-Bibliothek immer drei Versionen hinter dem Code ist. Dass niemand weiß, wer eine Komponente besitzt, wenn sie aktualisiert werden muss. Dass die Notion-Dokumentation am Tag ihrer Erstellung korrekt und sechs Monate später nutzlos war.
Alles wahr. Aber das sind keine Design-System-Probleme — es sind Governance-Probleme. Und Governance verbessert sich nicht durch einen Tool-Wechsel. Der Wechsel von Sketch zu Figma hat das Problem veralteter Dokumentation nicht gelöst. Der Wechsel zu Storybook hat nicht die Frage gelöst, wer entscheidet, wenn Produkt und Design System sich widersprechen. Der Wechsel zu Design Tokens hat nicht die Frage gelöst, wer die Tokens aktualisiert, wenn sich die Marke ändert.
Was zyklisch stirbt, ist nicht das Design System. Es ist die Illusion, dass man es einmal baut und damit gelöst hat.
Was zyklisch stirbt, ist nicht das Design System. Es ist die Illusion, dass man es einmal baut und damit gelöst hat.
Was wirklich tot ist: das monolithische Modell
Es gibt eine Sache, die wirklich tot ist, zumindest für mittelgroße bis große Enterprise-Teams. Es ist das Modell, das ich „den einen Ring" nenne — ein zentralisiertes System, das behauptet, jedes Produkt, jede Oberfläche, jeden Anwendungsfall in der gesamten Organisation abzudecken.
Das Problem ist nicht konzeptuell, sondern operativ. Ein zentralisiertes Team kann nicht jedes Produkt gut genug kennen, um sinnvolle Design-System-Entscheidungen für alle zu treffen. Ein System, das generisch genug ist, um überall zu funktionieren, endet damit, generisch genug zu sein, um nirgendwo optimal zu sein.
Das Modell, das in den letzten drei Jahren am besten funktioniert hat, ist föderiert: ein kleiner Kern gemeinsamer Entscheidungen — Typografie, semantische Farben, Abstands-Skala, obligatorische Barrierefreiheitsmuster — und dann ein dokumentiertes Erweiterungssystem, das Produktteams erlaubt, ihre spezifischen Komponenten unter Einhaltung des Grundvertrags zu bauen.
Was generative KI wirklich verändert hat
Das Versprechen war: Mit KI wird die Generierung von Komponenten sofort, das Design System überflüssig. Die von mir beobachtete Realität ist interessanter und weniger dramatisch.
Generative KI hat die Erstellung von Komponentenvarianten und Prototypen schneller gemacht. Aber sie hat das vorgelagerte Problem nicht gelöst — und konnte es nicht lösen: zu entscheiden, welche Komponenten existieren, was sie tun, welche Muster sie fördern und welche sie ausschließen, wie sie sich im Fehlerfall verhalten, welche Barrierefreiheitsanforderungen sie erfüllen. Das sind Governance-Entscheidungen, die organisatorischen Kontext erfordern, den ein generatives Modell nicht hat.
Was ich bei Teams beobachte, die generative KI ohne Design System einsetzen: Die Geschwindigkeit der Komponentenproduktion steigt, aber auch die Divergenz. Jeder Entwickler generiert seine eigene leicht abweichende Modal-Komponente. Die visuelle Konsistenz sinkt. Technische Schulden wachsen still. Und sechs Monate später muss jemand wie ich ein Audit durchführen, um die Ordnung wiederherzustellen.
Paradoxerweise hat generative KI das Design System notwendiger gemacht, nicht weniger. Denn ohne eine maßgebliche Referenzspezifikation produziert schnelle Generierung schnell Divergenz.
Das Design System 2025: kleinere Oberfläche, stärkere Tokens
Das Enterprise-Design-System, das ich heute baue, ist strukturell anders als das, was ich 2018 gebaut habe. Nicht weil sich die Philosophie geändert hat, sondern weil ich gelernt habe, wo ich Investitionen konzentrieren muss, um den Return zu maximieren.
Die Systemoberfläche ist kleiner. Weniger Komponenten, aber besser dokumentiert und stabiler. Die Regel, die ich verwende: Eine Komponente kommt ins System, wenn sie in mindestens drei verschiedenen Produkten oder Kontexten vorkommt. Davor lebt sie als lokale Lösung.
Semantische Tokens sind der Kern. Nicht color-blue-500, sondern color-action-primary, color-feedback-error, color-surface-elevated. Tokens, die semantische Entscheidungen kodieren, nicht visuelle Werte. Wenn sich die Marke ändert — und das tut sie immer — werden die zugrundeliegenden Werte aktualisiert, nicht das System neu geschrieben. Für Tarvos verwendete ich diesen Ansatz, und die Dark-Theme-Migration dauerte zwei Arbeitstage statt drei Wochen.
Dokumentation lebt im Code, nicht in Notion. Nicht weil Notion das falsche Tool ist, sondern weil Dokumentation, die von der Wahrheitsquelle getrennt ist, immer veraltet. Wenn die Komponente sich ändert, ändert sich die Dokumentation mit ihr — weil es dieselbe Datei ist.
Eine Komponente kommt ins System, wenn sie in mindestens drei verschiedenen Produkten vorkommt. Davor lebt sie als lokale Lösung.
Governance: Das Einzige, was wirklich zählt
Design-System-Governance beantwortet vier Fragen, und wenn Sie nicht alle vier beantwortet haben, bevor Sie mit dem Bauen beginnen, wird das System scheitern, unabhängig von seiner technischen Qualität.
Wer besitzt das System? Nicht ein generisches Team — eine spezifische Person, die antwortet, wenn eine Komponente um 23 Uhr an einem Donnerstag einen kritischen Bug hat.
Wie werden Entscheidungen getroffen, wenn das System mit einem Produktbedarf in Konflikt gerät? Sie brauchen einen dokumentierten Prozess, keine Fall-für-Fall-Diskussion.
Wie wird die Adoption gemessen? Wenn Sie nicht messen, wissen Sie nicht, ob das System genutzt oder umgangen wird. Die Metriken, die ich verwende: Komponentenabdeckung, durchschnittliche Implementierungszeit für ein neues Feature, Anzahl visueller Abweichungen, die in Design-Reviews gemeldet werden.
Wie wird das System aktualisiert, ohne Produkte zu brechen? Semantische Versionierung, angewendet auf Komponentenbibliotheken, ist nicht nur ein technisches Detail — es ist ein Versprechen an Produktteams, dass sie kontrolliert upgraden können.
Wohin das führt
Die nächste Veränderung, die ich kommen sehe, ist der Einsatz von KI zur automatischen Konsistenzprüfung: Tools, die Produktions-Screenshots analysieren und identifizieren, wo Komponenten vom Design System abweichen, ohne manuelle Überprüfung. Technisch ist das bereits möglich.
Der andere Trend ist die Kodierung von Designentscheidungen direkt in Tokens, nicht nur Werte. Tokens, die Metadaten über Verwendungskontext, Kontrastanforderungen und Barrierefreiheits-Einschränkungen tragen. Ein Token ist nicht nur eine Farbe — es ist eine Farbe mit ihren Regeln.
Das Design System ist nicht tot. Es hat sich weiterentwickelt, wie immer. Und diejenigen, die das verfrühte Begräbnis ankündigten, arbeiten jetzt mit Teams, die drei Jahre visueller Konsistenz verloren haben und gezwungen sind, von Grund auf neu aufzubauen, was sie auf der Jagd nach dem Trend demontiert haben.
Wenn Sie ein Design System für ein Enterprise-Team aufbauen oder neu gestalten — insbesondere wenn Governance der kritische Engpass ist — kann ich Ihnen helfen, die richtige Struktur festzulegen, bevor eine einzige Zeile Code geschrieben wird. Das erste Gespräch ist kostenlos.