Cuando trabajas en un equipo pequeño, la palabra "sistema de diseño" suele sonar a algo enorme, burocrático y reservado para empresas con departamentos de diseño e ingeniería. En mi experiencia creando productos con recursos limitados, un sistema de diseño escalable puede ser compacto, pragmático y extremadamente útil: reduce decisiones repetitivas, acelera entregas y mejora la coherencia visual. Aquí comparto cómo estructurar uno que funcione para equipos de 2 a 10 personas, con ejemplos concretos y herramientas que realmente uso.
Por qué un sistema de diseño importa (incluso para equipos pequeños)
He visto equipos desperdiciar tiempo redibujando botones o discutiendo margenes en cada sprint. Un sistema de diseño no es sólo una guía estética: es una infraestructura para tomar decisiones rápidas y consistentes. Beneficios clave que he comprobado:
- Menos micro-decisiones: decisiones visuales comunes ya están resueltas.
- Onboarding más rápido: nuevos miembros entienden patrones y variables.
- Iteración más segura: cambiar un token actualiza componentes sin romper todo.
- Mejor comunicación entre diseño y dev: un lenguaje compartido.
Principios para un sistema escalable y ligero
Antes de diseñar nada, defino principios claros. Para equipos pequeños recomiendo:
- Pragmatismo: Priorizar lo que realmente se usa en producto, no teorías.
- Modularidad: Construir piezas reutilizables y combinables.
- Documentación mínima viable: clara y con ejemplos prácticos.
- Iteración rápida: versionado y mejoras incrementales.
Capas del sistema: tokens, componentes y patrones
Organizo el sistema en tres capas para mantenerlo simple y escalable:
| Capa | Qué contiene | Por qué importa |
|---|---|---|
| Tokens | Colores, tipografía, espaciamiento, radios, sombras | Variables atómicas que definen la apariencia base |
| Componentes | Botones, inputs, tarjetas, modal | Blocks reutilizables construidos con tokens |
| Patrones | Cabeceras, listados, formularios completos | Combinaciones de componentes para casos de uso |
Tokens: cómo crearlos y nombrarlos
Los tokens son el corazón. Mi recomendación práctica:
- Usa nombres semánticos más que visuales: --color-primary en vez de --color-azul-5. Si cambias tonos, los nombres semántos permanecen relevantes.
- Organízalos por tipo: color, tipografía, espacio, sombra, radio.
- Empieza con pocos: paleta primaria, secundaria, neutrales y un set de espacios (xs, sm, md, lg).
Herramientas: en CSS/JS uso variables CSS y en diseño tokens mantenidos en Figma con plugins como Design Tokens o exportaciones desde Figma Tokens. Para componentes, Storybook y Tailwind (si trabajas con utilidades) conectan muy bien con tokens.
Componentes: filosofía y checklist
Construyo componentes pensando en dos preguntas: ¿es reutilizable? ¿resuelve un patrón real en el producto?
- Empieza por el 80/20: botones, inputs, select, checkbox, tarjeta y avatar. Con eso resuelves muchas páginas.
- Cada componente debe tener: variantes (primario, secundario), estados (hover, disabled), accesibilidad (roles, labels) y ejemplos de uso.
- Documenta las props/variables esperadas para desarrolladores (por ejemplo en Storybook).
Documentación práctica (mínima pero útil)
No intentes escribir la guía definitiva desde el día uno. Documentación útil para equipos pequeños incluye:
- Guía rápida: cómo instalar tokens y dónde importarlos.
- Ejemplos de uso: snippets de HTML/React/Vue por componente.
- Reglas de diseño: cuándo usar X variante de botón o qué paddings aplicar en tarjetas.
- Changelog básico: dónde anotar cambios y versiones.
Un README claro en el repo del diseño + un Storybook sirven de base. Yo mantengo una página en Figma con ejemplos interactivos y un Storybook limitado con los componentes más usados.
Flujos y gobernanza: cómo mantener el sistema vivo
La parte más olvidada es cómo evolucionar el sistema sin que se convierta en un trasto inmutable. Para equipos pequeños propongo:
- Propiedad compartida: un "mantenimiento rotativo" donde cada mes un miembro revisa issues y mejoras.
- Pull requests como fuente de verdad: cambios en tokens/componentes via PRs que incluyan ejemplos y screenshots.
- Release semántico simple: tags como v0.1, v0.2 — no necesitas versionado complejo, pero sí trazabilidad.
- Feedback rápido: una etiqueta dedicada en el gestor de tareas para bugs o ideas relacionadas con el sistema.
Integración con el desarrollo: herramientas y hacks que uso
En mis proyectos pequeños suelo combinar estas herramientas:
- Figma para diseño y prototipos rápidos, con la librería de componentes y tokens exportables.
- Storybook como catálogo vivo para desarrolladores y diseñadores.
- Tokens como código: variables CSS, un paquete npm interno o un pequeño repo con tokens en JSON para importarlos desde cualquier app.
- Tailwind cuando busco velocidad: configuro la paleta desde tokens y construyo componentes utilitarios.
Casos reales y trucos prácticos
Un truco que me ha salvado tiempo: crear una "caja de patrones" con 10 páginas reales del producto y estandarizar sólo lo que aparece en esas páginas. Evita crear componentes hipotéticos que nunca se usan.
Otro: mantener un componente "Button" muy flexible con props para tamaño, variante y icono. En vez de 12 botones distintos, tienes uno con combinaciones parametrizables.
Métricas para saber si tu sistema funciona
No hace falta métricas complejas, pero conviene medir impacto:
- Tiempo medio para entregar una interfaz (antes/después).
- Número de reusos de componentes en el producto.
- Issues relacionados con inconsistencias visuales.
- Velocidad de onboarding de nuevos miembros.
Si quieres, puedo compartir una plantilla inicial de tokens y un Storybook básico que uso para arrancar proyectos pequeños. En Gomigo publico recursos y plantillas que ayudan a acelerar este tipo de trabajo — puedes encontrar más en gomigo.es.