case-study May 20, 2026 6 min read

De design system a plataforma de producte

#design-systems#producte#frontend#tooling#operacions

Des de fa temps em venia ressonant una idea bastant concreta: un design system no hauria de dependre d’una eina concreta per existir, ni d’un flux tancat per mantenir-se útil. La governança que havia vist en altres equips grans ja apuntava en aquesta direcció: més contracte, més criteri compartit i menys dependència d’una única interfície o d’una única font visual de veritat.

També vaig començar a veure el mateix moviment en diferents entorns de producte a gran escala. Alguns equips estaven replantejant els seus sistemes perquè fossin accessibles, consistents i consumibles per LLMs; altres ja treballaven amb sistemes directament code-ready, més a prop d’infraestructura que d’escaparata visual.

En paral·lel, em va passar una cosa que segurament reconeix qualsevol que hagi treballat amb tooling de disseny dependent de tercers: una actualització em va fer notar com de fràgil pot ser construir sobre una plataforma que no controles del tot. Al final es va resoldre, però la intuïció va quedar clara: si l’eina canvia, el sistema no pot estar atrapat en ella.

Així que vaig decidir muntar alguna cosa amb el que ja tenim avui —LLMs, documentació, experimentació i experiència propera— per crear una base de travail que no depengui d’una sola interfície, sinó d’un contracte de sistema capaç d’evolucionar amb nosaltres.

El problema real

Molts design systems tenen components, llibreries, documentació i fins i tot un llenguatge visual bastant sòlid. Però quan toca construir producte de veritat, llançar una nova pàgina o adaptar una experiència a un altre context, massa vegades el sistema es queda curt.

No sol fallar per falta de peces. Sol fallar perquè mai arriba a convertir-se en infraestructura. És d’aquí, perquè no acaba sent la base real sobre la qual disseny, frontend i tooling poden treballar sense tornar a interpretar el mismo problema una vegada i una altra.

Més que un catàleg

A Code Ready, l’arquitectura ja està bastant lluny de la idea clàssica de “col·lecció de components”.

El sistema utilitza Astro como a shell del catàleg i de les pàgines, React per als components interactius i Base UI com a capa de primitives headless accessibles quan encaixa amb el problema a resoldre.

Això, per si sol, encara podria descriure una llibreria ben muntada. El que canvia realment la naturalesa del sistema és una altra cosa: el registry JSON actua com a contracte central i la documentació actual separa de forma explícita l’operacional, el canònic i el referencial.

Aquest matís importa. Significa que el sistema ja no viu repartit entre codi, pantalles i coneixement tàcit de l’equip. Hi ha una estructura clara sobre on està cada veritat, quina capa mana sobre una altra i com s’edita cada part sense introduir soroll o duplicació.

El registry com a contracte

La idea més potent de tot això és que el registry deixa de ser un inventari per convertir-se en un contracte. No només diu que existeix un Button, un Dialog o una HeroLeadForm; també fixa com es descriu, quines props i estats forman part de la seva API, quin exemple el representa i quina documentació l’acompanya.

Però l’evolució més interessant és que aquest contracte ja no cobreix només la implementació tècnica. La documentació canònica nova afegeix capes específiques per modelar decisió, qualitat, criticitat, negoci, marca i locale directament a les entrades del registry.

Això canvia bastant la conversa. El sistema ja no només pot respondre “quin component faig servir”, sinó també “quin nivell d’abstracció té”, “què passa si falla”, “en quin context hauria d’aparèixer” o “quina part del producte toca”.

De peces a decisions

Durant anys hem pensat els design systems com a caixes de peces. Botons, inputs, modals, menús, pestanyes. Tot això continua sent necessari, clar. Però no n’hi ha prou per accelerar la feina real si cada vegada que apareix una pàgina o flux nou l’equip ha de tornar a interpretar des de zero com compondre, quin patró encaixa i quines decisions ja estaven resoltes.

Per això em sembla tan important que Code Ready no es quedi en primitives. El sistema ja contempla sections com a composicions reutilizables a nivell de pàgina, registrades i documentades dins del mateix marc que la resta del catàleg.

Aquí hi ha un canvi de mentalidad important. Una section no és una demo vistosa ni una plantilla informal. És una composició que el sistema considera prou estable i reutilitzable com per convertir-la en un actiu compartit.

Un exemple concret

HeroLeadForm resumeix bastant bé aquesta evolució. No pretén resoldre qualsevol hero ni qualsevol formulari: està pensada com a composició concreta per a pàgines de captació amb un objectiu principal de conversió i una estructura bastant reconeixedora.

Interfície documentada de HeroLeadForm com a secció del sistema

El més interessant és que el sistema no se queda només en la capa visual. També comença a situar components i seccions en el seu context real: on es fan servir, quin objectiu ajuden a complir i quin compte cal tenir a l’hora de canviar-los.

La pròpia documentació la descriu com a secció pensada per a contextos d’alta intenció, on el formulari forma part directa de l’objectiu de conversió.

El sistema ja modela més que UI

Una de les coses que més canvia amb la documentació actualitzada és que el registry ja no descriu només la interfície. També descriu el context. Hi ha una capa per decidir si quelcom ha de ser primitive, section o composició manual; una altra per modelar criticitat i impacte; una altra per ubicar peces dins del funnel; i una altra per declarar compatibilitat de marca, claus d’i18n i contexts d’ús.

Jerarquia i capes d’abstracció dins del Registry

Això converteix el design system en una eina molt més útil per a equips sènior. Ja no serveix només per alinear la UI, sino també per prendre millors decisions de producte i de manteniment. Pots discutir si una peça mereix pujar al sistema, quant costa trencar-la, on es fa servir bé i on convé no forzar-la.

I tot això sense barrejar capes. La documentació està pensada precisament per evitar que el sistema derivi en una sopa de metadades sense criteri: cada dimensió té la seva doc canònica, la seva semàntica i el seu lloc d’edició.

Marca i locale sense contaminar componentes

Un altre signe clar de maduresa està en com es resolen la marca i la internacionalització. La guia actual ho deixa bastant clar: els components React no han de conèixer ni la marca activa ni el locale actiu. Reben props, consumeixen tokens semàntics i renderitzen; la variació visual es resol en la capa de tokens i la variació d’idioma en la capa d’integració abans d’arribar al component.

Sembla una regla petita, però té bastant impacte. Quan la lògica de marca o copy entra en components compartits, el sistema es torna més fràgil, més difícil de mantenir i més propens a excepcions locals.

Aquí l’aposta és la contrària. Els tokens són la font de veritat visual, amb una cascada explícita entre core, col·leccions de marca i modes, i els components només consumeixen noms semàntics com --color-primary o --color-bg, mai valors hardcodejats ni tokens de marca concrets. Això permet que un mateix component s’adapti a diferents marques o modes sense haver de saber res sobre elles.

Publicar per reutilitzar

Tot això guanya encara més sentit perquè el sistema no es queda tancat en el seu propi catàleg. Code Ready ja es publica com a paquet npm consumible per altres projectes i exposa entrypoints separats per a components, sections, styles, base, brands i types.

Arquitectura d’empaquetat i entrypoints independents

Això canvia la naturalesa del design system d’una forma important. Ja no és només una cosa que l’equip consulta per implementar, sinó una cosa que altres projectes poden importar com a base real. La diferència entre “mirar la documentació” i “consumir el sistema” és enorme.

També m’agrada que aquesta publicació no barregi coses diferents sota una mateixa etiqueta. Els entrypoints de styles i base, per exemple, separen la definició del sistema visual de la seva aplicació al DOM, cosa que fa més clar quina part aporta tokens i quina part aporta comportament base.

Pensat per a disseny, frontend i LLMs

Hi ha un altre detall que em sembla clau i que probablement marqui més sistemes els propers anys: la documentació no està escrita només per a humans. El README i el workflow deixen clar que aquesta base està pensada per a disseny, enginyeria i flurs assistits per LLMs, amb rutes d’edició, contractes i regles prou explícites com perquè una màquina també pugui operar sobre elles sense inventar semàntiques pel camí.

No es tracta d’eliminar eines de disseny. Es tracta que el sistema sobrevisqui a elles.

Cap a nous projectes

I potser aquí hi ha la part que més m’interessa de tot això. Una vegada tens un design system publicat, amb un contracte clar, capes de metadades útils, seccions reutilitzables i suport explícit per a marques i contexts, ja no estàs tan lluny de fer-lo servir com a base per engegar projectes nous.

Workflow complet des del Briefing inicial fins a la pàgina generada

En aquest escenari, l’input ja no és “dibuixem una pàgina des de zero”, sinó una cosa bastant més estructurada: quin és l’objectiu, quin contingut tenim, quins idiomes suporta, quin context de marca s’aplica i quin nivell de composició encaixa millor.

Això no substitueix el treball de disseny. Però sí que canvia molt on comença. En lloc de començar refent la infraestructura, comences prenent decisions sobre una base que ja existeix.

Compondre en el consumer

I això obre una possibilitat especialment interessant: no cal que cada pàgina nova existeixi per endavant com una plantilla tancada. En molts casos, un consumer podria muntar-la dinàmicament a partir de components del sistema, sempre que el briefing inclogui estructura, contingut, objectiu, idiomes i context de marca.

Aquí el punt clau és que el LLM no hauria d’inventar la interfície des de zero. Hauria de compondre sobre un contracte ja definit: quines peces existeixen, quin nivell d’abstracció tenen, quan convé utilitzar una section i quan convé muntar la pàgina manualment al consumer.

Això desplaça el valor del design system. Deixa de ser només una llibreria d’UI i passa a ser una base estructurada perquè equips i LLMs muntin producte amb més velocitat i menys ambigüitat.

El que realment estem construint

Por això, si hagués de resumir-ho en una sola idea, diria això: Code Ready no vol ser la font de veritat visual. Vol ser la base de veritat operativa per construir producte sense dependre d’una sola eina.

I per a mi, aquest és just el punt en què un design system deixa de ser una llibreria i comença a convertir-se en plataforma.

El següent pas natural en aquesta sèrie és entrar al nucli d’aquesta idea: per què el registry importa tant i com deixa de ser un inventari per convertir-se en contracte i capa de decisió.