Design System: El Motor de Escala

Sin sistema compartido, diseño e ingeniería hablaban idiomas distintos. Cada componente existía en tres versiones simultáneas.

Cuando llegué a GroWrk, el producto era funcional pero frágil. Los diseños habían nacido en PowerPoint y Google Slides. Había una paleta de colores en Figma, pero ningún sistema real. Cada feature nueva requería reinventar decisiones ya tomadas.

El problema invisible se hizo evidente al tercer año, cuando quisimos actualizar la identidad visual: en producción existían decenas de versiones del mismo botón. Cada developer había resuelto el mismo componente a su manera. El Design System de Figma existía, pero para ingeniería, no existía.

Necesitábamos una sola fuente de verdad que diseño e ingeniería pudieran compartir, sin detener el producto.

Un Design System no se construye de una vez. Se cultiva.

Las decisiones que no están en las pantallas.

Un Design System no es una librería de componentes. Es una serie de decisiones sobre cómo quieres que un equipo trabaje. Estas son las más importantes.

01Tratar el DS como un producto, no como un entregable

Al inicio, el Design System era mi proyecto personal. Lo construía, lo actualizaba, pero nadie más lo usaba ni lo sentía suyo.

Empecé a exponer cada nuevo componente con el equipo de diseño antes de publicarlo. Workshops para decidir la funcionalidad del componente, sus variantes y sus estados. Si todos participaban en la decisión, todos lo usaban.

La diseñadora Jr. no solo adoptó el sistema. Empezó a proponer mejoras. Sus preguntas retroalimentaron directamente cada versión del DS. El debate sobre el outline del input no era pérdida de tiempo. Era el proceso de hacer que el sistema fuera de todos.

02El ProductCard: componente custom sobre base NUXT

NUXT UI tenía sus propios componentes. El problema era que las cards de producto de GroWrk necesitaban características específicas que UTable o UCard no resolvían nativamente.

Desarrollamos un proceso de workshops para crear componentes custom sobre la base de NUXT. El ProductCard combinó múltiples componentes de NUXT en uno nuevo con propiedades reutilizables en toda la plataforma. Si se necesitaba una característica extra, se agregaba como variante, no como componente nuevo.

El ProductCard se usa en todas las plataformas. Cuando necesitamos algo distinto, agregamos una variante al componente existente, no creamos uno nuevo. Eso redujo drásticamente la deuda de consistencia.

03Migrar a NUXT/Tailwind: dejar ir el DS custom

Teníamos un Design System de Figma bien construido. El problema era el responsivo, y ese era el dolor de ingeniería, no el nuestro. Cada componente custom requería mantenimiento en código que ningún diseñador controlaba.

La migración fue una iniciativa de ingeniería que decidí abrazar en lugar de defender el DS custom. Mi postura: buscar lo mejor para el equipo sin sacrificar el diseño. Adapté NUXT y lo brandeé a GroWrk, documentando cada ajuste en Figma y en código.

Por primera vez, diseño e ingeniería trabajaban sobre la misma base. El sistema bilingüe cerró un gap de 3 años. El responsivo dejó de ser un problema.

04Limpiar los iconos: de 330 a 234

La librería original tenía 330 iconos acumulados a lo largo de 2 años. Muchos eran redundantes, otros desactualizados, y algunos nunca se habían usado en producción.

En la V3 hicimos una auditoría completa de uso de iconos. Eliminamos redundancias, homologamos estilos y documentamos los 234 que sí estaban en uso activo. Cada icono tiene ahora un nombre consistente con el sistema de nomenclatura de NUXT.

Menos iconos, más claridad. El equipo ya no pierde tiempo buscando cuál de las tres versiones del icono de usuario usar.

¿Y si el Design System pudiera diseñar contigo?

Al tener toda la documentación del DS en Notion y Figma, surgió una pregunta natural: ¿podíamos convertir esas reglas en contexto para una IA que generara UI directamente?

En conjunto con el PM, construimos un AI Playground. Un proyecto en código que contiene todas las reglas del DS (design.md, rules.md, skills.md) como contexto inyectado. Cualquier miembro del equipo puede describir una pantalla en lenguaje natural y obtener una propuesta que sigue el sistema de diseño de GroWrk.

El proceso tomó alrededor de 2 meses trabajando en paralelo a nuestras responsabilidades normales. Conforme mejores modelos salían al mercado, la calidad de las propuestas generadas mejoró de forma notable.

Primer prompt: 80–90% de fidelidad al DS desde el primer output

Con auditoría IA: 99–100% de fidelidad tras revisión automatizada

"Creemos que es una herramienta que va a revolucionar la forma en que diseñamos." — PM, GroWrk Remote

"Ya quiero probarla, se ve que nos va a ahorrar mucho tiempo." — Sony, Diseñadora, GroWrk Remote

Lo que cambió, en números y en cultura.