Situación
Las superficies de producto compartían marca sobre todo en aplicaciones Angular—con un PoC corto en React—mientras tokens y componentes tendían a divergir si cada consumidor los evolucionaba por su cuenta.
Tarea
Establecer una base de design system: tokens semánticos, reglas de composición y packages versionados que los equipos pudieran adoptar sin atar cada producto a un único runtime de UI.
Acción
Dejé el núcleo en tokens, reglas de composición y primitivos; los widgets de negocio quedaron fuera de la library. Generé tokens semánticos desde un JSON de configuración vía pipeline de build, publiqué packages versionados con review, changelog y deprecations, y documenté el uso con demos en la library y Storybook.
Resultado
Las apps Angular pudieron migrar a la v3 módulo a módulo en lugar de un big bang; un PoC corto en React validó el consumo cross-framework sin forzar paridad total.
Forma del sistema
En el núcleo: tokens de color, tipografía y espacio; reglas de composición; componentes primitivos (button, input, card y similares).
Fuera de la library: widgets de negocio atados a un dominio de producto.
Cómo se aprendía: sección de demos en la library (forms, layout, etc.) más Storybook para documentación.
Quién lo consumía: Angular era el camino de producción. React fue un PoC corto de viabilidad—señal útil, no la inversión principal.
Decisiones
Tokens semánticos desde una fuente generada
Elegimos: tokens semánticos definidos en un JSON de configuración y producidos por un pipeline de build/generación. Rechazamos: copiar a mano valores crudos en cada app o package de framework. Por qué: una sola fuente de verdad alinea nombres y valores; los packages consumen artefactos en lugar de forkar la paleta.
Inversión asimétrica Angular vs React
Elegimos: adopción profunda en Angular; React solo como PoC cuando el cliente preguntó si funcionaría. Rechazamos: forzar paridad total Angular/React desde el día uno. Por qué: la mayoría de consumidores reales eran Angular. Un PoC corto respondió la pregunta React sin retrasar el sistema que las apps de producción necesitaban.
Packages versionados, no un mega-bundle
Elegimos: packages versionados de forma independiente (core + packages de componentes). Rechazamos: un solo mega-package sin versionado que cada app tuviera que tragar entero. Por qué: los consumidores actualizan con criterio; los majors se anuncian antes de romper builds.
Gobernanza y versionado
- Los cambios pasaban por review antes del merge.
- Los releases iban versionados; los majors se notificaban al cliente con anticipación para que las apps consumidoras pudieran planear.
- Cada release exigía changelog y deprecations explícitas—sin breaking changes silenciosos.
Camino de adopción
PoC React (corto): un demo greenfield instaló core más packages de componentes (button, inputs, cards, etc.) solo para validar viabilidad.
Angular (adopción real): el cliente ya tenía dos generaciones previas del design system. La v3 fue un rediseño completo, así que la migración fue módulo a módulo en apps que lanzaban superficies nuevas—no un big bang de cada pantalla. El equipo de DS y los devs de módulos de app mantuvieron un feedback loop cerrado: los issues tempranos se resolvían con patches rápidos y robustos, no con forks eternos.
Qué rechazamos
Desde el inicio rechazamos:
- Meter widgets de negocio en el núcleo de la library
- Copiar tokens a mano en cada app
- Forzar paridad total Angular/React desde el día uno
- Publicar un mega-package sin versionado
- Saltar changelog o deprecations en los releases
Lección transferible
Antes de tocar un design system existente, entiende su documentación—y deja el sistema mejor documentado de lo que lo encontraste. Crear “algo nuevo” sin ese ciclo solo reproduce el drift.
Límites de este texto
Esta narrativa está anonimizada. No se muestran archivos de tokens propietarios, nombres internos de packages, screenshots de producto ni marcas de clientes. Trabajo de cliente bajo NDA — se muestra la arquitectura y las decisiones, los detalles de producto quedan fuera por diseño.
