case-studyMay 20, 20266 min read

De design system a plataforma de product

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

Quan un equip ha de llançar una nova pàgina, adaptar un flux o obrir un producte a un altre context, el problema de vegades gairebé mai és “dissenyar una pantalla”. El problema real sol ser un altre: tornar a muntar la mateixa infraestructura, reinterpretar decisions ja presses i dependre massa d’una eina o d’un handoff fràgil.

Fa temps vaig començar a donar-li voltes a 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. Hauria de poder sobreriure a les seves eines, evolucionar amb el producte i servir com a base real per a disseny, frontend i tooling.

També vaig començar a veure el mateix moviment en altres equips: sistemes més estructurats, més preparats per escalar i, cada vegada més, pensats per ser entesos no només per persones, sinó també per fluxos assistits per LLMs.

Aquí neix la idea d’un sistema de disseny code-ready: no només documentat o implementat, sinó preparat per viure en codi, contractes, tokens i regles operatives que permetin construir, mantenir i estendre producte sense començar de zero cada vegada.

El problema real

Més enllà dels design systems clàssics amb components, llibreries, documentació i fins i tot un llenguatge visual bastant sòlid, quan toca construir producte de veritat, llançar una nova pàgina o adaptar una experiència a un altre context, masses vegades el sistema es queda curt.

No sol fallar per manca de peces. Sol fallar perquè mai arriba a convertir-se en infraestructura. És a dir, perquè no acaba sent la base real sobre la qual disseny, frontend i tooling poden treballar sense reinterpretar el mateix problema una vegada i una altra.

Més que un catàleg

Quan un sistema està pensat de forma code-ready, l’arquitectura ja està bastant lluny de la idea clàssica de “col·lecció de components”.

La base pot fer servir Astro com 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ó separa de forma explícita allò operacional, allò canònic i allò 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 és cada veritat, quina capa mana sobre una altra i com s’edita cada part sense introduir soroll ni duplicacions.

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 formen 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 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 afecta”.

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 és suficient 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 un sistema code-ready no es quedi en primitives. El sistema també pot contemplar sections com a composicions reutilitzables a nivell de pàgina, registrades i documentades dins del mateix marc que la resta del catàleg.

Aquí hi ha un canvi de mentalitat 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 una composició concreta per a pàgines de captació amb un objectiu principal de conversió i una estructura bastant reconeixible.

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

El més interessant és que el sistema no es 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 situa com una secció adequada per a contextos d’alta intenció, on el formulari forma part directa de l’objectiu de conversió. I també deixa clar quan no convé fer-la servir i quan és millor compondre primitives directament al consumer.

El sistema ja modela més que UI

Una de les coses que més canvia quan el sistema madura é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 contextos 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, sinó 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 forçar-la.

I tot això sense barrejar capes. La documentació està pensada precisament para 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 components

Un altre signe clar de maduresa està en com es resolen la marca i la internacionalització. La regla és senzilla, però important: els components React no haurien 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é un gran 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 hardcodats 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 quan el sistema no es queda tancat en el seu propi catàleg. Un design system code-ready es pot publicar com a paquet npm consumible per altres projectes i exposar 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ó quelcom 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. Una cosa defineix els tokens; l’altra aplica aquest contracte visual al layout i als elements base.

Pensat per a disseny, frontend i LLMs

Hi ha un altre detall que em sembla clau i que probablement marqui més sistemes en els pròxims anys: la documentació no està escrita només per a humans. El workflow, la separació per capes i els contractes fan que aquesta base també estigui pensada per a disseny, enginyeria i fluxos assistits per LLMs, con rutes d’edició 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í està la part que més m’interessa de tot això. Una vegada tens un design system publicat, amb un contracte clar, capes de metadata útils, sections reutilitzables i suport explícit per a marques i contextos, ja no estàs tan lluny de fer-lo servir com a base per arrancar 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ó quelcom bastant més estructurat: quin és l’objectiu, quin contingut tenim, quins idiomes suporta, quin context de marca aplica i quin nivell de composició encaixa millor.

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

Compondre al consumer

I això obre una possibilitat especialment interessant: no cal que cada nova pàgina existeixi prèviament 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 l’estructura, el contingut, l’objectiu, els idiomes i el context de marca.

Aquí el punt clau és que l’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é fer servir 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 de 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

Per això, si ho hagués de resumir en una sola idea, diria això: un sistema de disseny code-ready no hauria d’aspirar només a ser la font de veritat visual. Hauria d’aspirar a ser una base de veritat operativa per construir producte sense dependre d’una sola eina.

I per a mi, aquest és just el punt en el qual 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 en el 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ó.