case-study May 20, 2026 6 min read

De design system a plataforma de producto

#design-systems#producto#frontend#tooling#operaciones

Cuando un equipo tiene que lanzar una nueva página, adaptar un flujo o abrir un producto a otro contexto, el problema rara vez es “diseñar una pantalla”. El problema real suele ser otro: volver a montar la misma infraestructura, reinterpretar decisiones ya tomadas y depender demasiado de una herramienta o de un handoff frágil.

Hace tiempo empecé a darle vueltas a una idea bastante concreta: un design system no debería depender de una herramienta concreta para existir, ni de un flujo cerrado para mantenerse útil. Debería poder sobrevivir a sus herramientas, evolucionar con el producto y servir como base real para diseño, frontend y tooling.

También empecé a ver el mismo movimiento en otros equipos: sistemas más estructurados, más preparados para escalar y, cada vez más, pensados para ser entendidos no solo por personas, sino también por flujos asistidos por LLMs.

Así nació la intención detrás de Code Ready: dejar de pensar el design system como un catálogo de piezas y empezar a tratarlo como una base operativa para construir producto.

El problema real

Muchos design systems tienen componentes, librerías, documentación y hasta un lenguaje visual bastante sólido. Pero cuando toca construir producto de verdad, lanzar una nueva página o adaptar una experiencia a otro contexto, demasiadas veces el sistema se queda corto.

No suele fallar por falta de piezas. Suele fallar porque nunca llega a convertirse en infraestructura. Es decir, porque no termina siendo la base real sobre la que diseño, frontend y tooling pueden trabajar sin reinterpretar el mismo problema una y otra vez.

Más que un catálogo

En Code Ready, la arquitectura ya está bastante lejos de la idea clásica de “colección de componentes”.

El sistema usa Astro como shell del catálogo y de las páginas, React para los componentes interactivos y Base UI como capa de primitives headless accesibles cuando encaja con el problema a resolver.

Eso, por sí solo, todavía podría describir una librería bien montada. Lo que cambia realmente la naturaleza del sistema es otra cosa: el registry JSON actúa como contrato central y la documentación separa de forma explícita lo operacional, lo canónico y lo referencial.

Ese matiz importa. Significa que el sistema ya no vive repartido entre código, pantallas y conocimiento tácito del equipo. Hay una estructura clara sobre dónde está cada verdad, qué capa manda sobre otra y cómo se edita cada parte sin introducir ruido ni duplicación.

El registry como contrato

La idea más potente de todo esto es que el registry deja de ser un inventario para convertirse en un contrato. No solo dice que existe un Button, un Dialog o una HeroLeadForm; también fija cómo se describe, qué props y estados forman parte de su API, qué ejemplo lo representa y qué documentación lo acompaña.

Pero la evolución más interesante es que ese contrato ya no cubre solo la implementación técnica. La documentación canónica añade capas específicas para modelar decisión, calidad, criticidad, negocio, marca y locale directamente en las entradas del registry.

Eso cambia bastante la conversación. El sistema ya no solo puede responder “qué componente uso”, sino también “qué nivel de abstracción tiene”, “qué pasa si falla”, “en qué contexto debería aparecer” o “qué parte del producto toca”.

De piezas a decisiones

Durante años hemos pensado los design systems como cajas de piezas. Botones, inputs, modales, menús, tabs. Todo eso sigue siendo necesario, claro. Pero no alcanza para acelerar trabajo real si cada vez que aparece una página o flujo nuevo el equipo tiene que volver a interpretar desde cero cómo componer, qué patrón encaja y qué decisiones ya estaban resueltas.

Por eso me parece tan importante que Code Ready no se quede en primitives. El sistema ya contempla sections como composiciones reutilizables a nivel de página, registradas y documentadas dentro del mismo marco que el resto del catálogo.

Ahí hay un cambio de mentalidad importante. Una section no es una demo vistosa ni una plantilla informal. Es una composición que el sistema considera suficientemente estable y reutilizable como para convertirla en un activo compartido.

Un ejemplo concreto

HeroLeadForm resume bastante bien esa evolución. No pretende resolver cualquier hero ni cualquier formulario: está pensada como una composición concreta para páginas de captación con un objetivo principal de conversión y una estructura bastante reconocible.

Interfaz documentada de HeroLeadForm como sección del sistema

Lo interesante es que el sistema no se queda solo en la capa visual. También empieza a situar componentes y secciones en su contexto real: dónde se usan, qué objetivo ayudan a cumplir y qué cuidado merece cambiarlos.

La propia documentación la sitúa como una sección adecuada para contextos de alta intención, donde el formulario forma parte directa del objetivo de conversión. Y también deja claro cuándo no conviene usarla y cuándo es mejor componer primitives directamente en el consumer.

El sistema ya modela más que UI

Una de las cosas que más cambia con la documentación actualizada es que el registry ya no describe solo interfaz. También describe contexto. Hay una capa para decidir si algo debe ser primitive, section o composición manual; otra para modelar criticidad e impacto; otra para ubicar piezas dentro del funnel; y otra para declarar compatibilidad de marca, claves de i18n y contextos de uso.

Jerarquía y capas de abstracción dentro del registry

Eso convierte al design system en una herramienta mucho más útil para equipos senior. Ya no sirve solo para alinear UI, sino también para tomar mejores decisiones de producto y de mantenimiento. Puedes discutir si una pieza merece subir al sistema, cuánto cuesta romperla, dónde se usa bien y dónde conviene no forzarla.

Y todo eso sin mezclar capas. La documentación está pensada precisamente para evitar que el sistema derive en una sopa de metadatos sin criterio: cada dimensión tiene su doc canónica, su semántica y su lugar de edición.

Marca y locale sin contaminar componentes

Otro signo claro de madurez está en cómo se resuelven marca e internacionalización. La regla es sencilla, pero importante: los componentes React no deberían conocer ni la marca activa ni el locale activo. Reciben props, consumen tokens semánticos y renderizan; la variación visual se resuelve en la capa de tokens y la variación de idioma en la capa de integración antes de llegar al componente.

Parece una regla pequeña, pero tiene bastante impacto. Cuando la lógica de marca o copy entra en componentes compartidos, el sistema se vuelve más frágil, más difícil de mantener y más propenso a excepciones locales.

Aquí la apuesta es la contraria. Los tokens son la fuente de verdad visual, con una cascada explícita entre core, colecciones de marca y modos, y los componentes solo consumen nombres semánticos como --color-primary o --color-bg, nunca valores hardcodeados ni tokens de marca concretos. Eso permite que un mismo componente se adapte a diferentes marcas o modos sin tener que saber nada sobre ellas.

Publicar para reutilizar

Todo esto gana todavía más sentido porque el sistema no se queda encerrado en su propio catálogo. Code Ready ya se publica como paquete npm consumible por otros proyectos y expone entrypoints separados para componentes, sections, styles, base, brands y types.

Arquitectura de empaquetado y entrypoints independientes

Eso cambia la naturaleza del design system de una forma importante. Ya no es solo algo que el equipo consulta para implementar, sino algo que otros proyectos pueden importar como base real. La diferencia entre “mirar la documentación” y “consumir el sistema” es enorme.

También me gusta que esa publicación no mezcle cosas distintas bajo una misma etiqueta. Los entrypoints de styles y base, por ejemplo, separan la definición del sistema visual de su aplicación al DOM. Una cosa define los tokens; la otra aplica ese contrato visual al layout y a los elementos base.

Pensado para diseño, frontend y LLMs

Hay otro detalle que me parece clave y que probablemente marque más sistemas en los próximos años: la documentación no está escrita solo para humanos. El README y el workflow dejan claro que esta base está pensada para diseño, ingeniería y flujos asistidos por LLMs, con rutas de edición, contratos y reglas suficientemente explícitas como para que una máquina también pueda operar sobre ellas sin inventar semánticas por el camino.

No se trata de eliminar herramientas de diseño. Se trata de que el sistema sobreviva a ellas.

Hacia nuevos proyectos

Y quizá ahí está la parte que más me interesa de todo esto. Una vez tienes un design system publicado, con contrato claro, capas de metadata útiles, sections reutilizables y soporte explícito para marcas y contextos, ya no estás tan lejos de usarlo como base para arrancar proyectos nuevos.

Workflow completo desde el briefing inicial hasta la página generada

En ese escenario, el input ya no es “dibujemos una página desde cero”, sino algo bastante más estructurado: cuál es el objetivo, qué contenido tenemos, qué idiomas soporta, qué contexto de marca aplica y qué nivel de composición encaja mejor.

Eso no sustituye el trabajo de diseño. Pero sí cambia mucho dónde empieza. En vez de empezar rehaciendo la infraestructura, empiezas tomando decisiones sobre una base que ya existe.

Componer en el consumer

Y esto abre una posibilidad especialmente interesante: no hace falta que cada nueva página exista de antemano como una plantilla cerrada. En muchos casos, un consumer podría montarla dinámicamente a partir de componentes del sistema, siempre que el briefing incluya estructura, contenido, objetivo, idiomas y contexto de marca.

Aquí el punto clave es que el LLM no tendría que inventar la interfaz desde cero. Tendría que componer sobre un contrato ya definido: qué piezas existen, qué nivel de abstracción tienen, cuándo conviene usar una section y cuándo conviene montar la página manualmente en el consumer.

Eso desplaza el valor del design system. Deja de ser solo una librería de UI y pasa a ser una base estructurada para que equipos y LLMs monten producto con más velocidad y menos ambigüedad.

Lo que realmente estamos construyendo

Por eso, si tuviera que resumirlo en una sola idea, diría esto: Code Ready no quiere ser solo la fuente de verdad visual. Quiere ser la base de verdad operativa para construir producto sin depender de una sola herramienta.

Y para mí, ese es justo el punto en el que un design system deja de ser una librería y empieza a convertirse en plataforma.

El siguiente paso natural en esta serie es entrar en el núcleo de esa idea: por qué el registry importa tanto y cómo deja de ser un inventario para convertirse en contrato y capa de decisión.