Nester no tenía design system porque nunca había tenido tiempo de necesitarlo.
Cuando entré en Nester, Figma apenas existía. El producto se construía directamente en código: sin documentación, sin librería de componentes, sin una única fuente de verdad visual. No diseñaba sobre un lienzo en blanco. Estaba sistematizando un producto que ya estaba en producción, con usuarios reales, mientras el roadmap seguía su ritmo normal.
Había que extraer un sistema coherente, no inventarlo, y dentro de un stack que no podía cambiar de un día para otro.
Poner orden en el caos
La pregunta no era “cómo diseño el sistema ideal”. Era: ¿cómo saco un sistema coherente de algo que nunca se pensó como tal, sin detener ni un solo sprint?
Diseñar dentro de Bootstrap 4
Todo lo que documentaba tenía que sobrevivir al stack actual. Nada de componentes que no pudiera soportar sin una reescritura importante. Más de una vez, eso significó documentar el patrón “correcto según lo que ya funciona”, no el patrón ideal en abstracto, sabiendo que esa concesión era temporal.
Cada pantalla ya contenía el sistema. Solo faltaba ponerle nombre.
Reconstruir el producto, pantalla por pantalla
No tenía el lujo de pausar el producto dos meses para definir primero los fundamentos. Así que fui por el otro camino: reconstruí en Figma cada pantalla existente, una a una —más de 80—, extrayendo los patrones reales sobre la marcha: qué espaciados se repetían, qué colores se usaban de verdad, qué variantes de botón existían aunque nadie les hubiera puesto nombre.
Mapear lo que ya existía en código
En paralelo, creé una base de datos en Notion que mapeaba cada componente que ya vivía en el código: qué era y dónde estaba.
Construir para lo que venía, no solo para lo que existía
Revisé directamente el roadmap de producto para anticipar lo que el sistema necesitaría antes de que se convirtiera en una urgencia, incluida la migración que sabíamos que llegaría, de Laravel a Next.js.
Un componente de menú de opciones. Veinte contextos distintos.
Fundamentos pensados para escalar
Colores, tamaños y espaciados se organizan como una escala real, no como valores sueltos. La mayoría de los componentes incluyen todos sus estados de interacción —hover, active, disabled— desde el principio.
Prueba a nivel de producto
El módulo de Propietarios: listado, creación, edición, detalle y subvistas, más de diez pantallas, todas construidas con las mismas piezas. La librería en sí son componentes maestros con variantes reales, organizados por dominio: un único componente de menú de opciones reutilizado en más de 20 lugares del producto: propietarios, contratos, incidencias, remesas y conceptos financieros.
Documentación al ritmo de los lanzamientos
Cada vez que salía una funcionalidad nueva, también se actualizaba la base de datos de Notion: cada componente, cada modal, cada vista, documentados a medida que se construían, no después. Ese archivo documenta cada release y genera los mocks que entrego a los desarrolladores en cada kickoff, donde la especificación se prueba pantalla por pantalla para que nada se pierda entre el diseño y el código.
Esa base de datos de Notion se mantuvo con la ayuda de un agente de Notion AI, que ayudaba a estructurar y actualizar las fichas de componentes a medida que salían pantallas nuevas, para que la documentación fuera al ritmo de los releases en lugar de quedarse atrás.
No todos los rincones están pulidos. Es una decisión, no un descuido.
Convivir con deuda visible
Algunas páginas crecieron como listas planas, según las iba necesitando. Hay frames duplicados donde deberían ir instancias de componentes: el coste de iterar rápido, sola, sin tiempo para formalizar cada pieza. Se reorganizará cuando llegue el próximo gran cambio.
Lo que viene después de Bootstrap 4
La migración de Laravel/Bootstrap 4 a Next.js ya está en marcha, y el siguiente capítulo es shadcn/ui, más flexible y consistente que lo que permite hoy Bootstrap 4. Ese cambio también es el momento en que el sistema deja de ser un archivo que mantengo sola y empieza a tener más manos.
El sistema ya estaba ahí. Solo necesitaba un nombre.
Construir un design system para un producto que ya está vivo es distinto de construirlo desde cero. No se trata de imponer el sistema “correcto”, sino de encontrar el patrón que ya existe, disperso y sin nombre, y ponerle nombre. La disciplina no fue dejarlo perfecto el primer día, sino mantenerlo vivo release tras release. Desde entonces, cada case study de Nester —Contract Templates, Digital Signature, Bank Reconciliation, Document Management— parte de esta misma base.
