Design
Construir un sistema de diseño para un equipo pequeño sin burocracia.
La mayoría de los consejos sobre sistemas de diseño están escritos para organizaciones con un equipo dedicado. Un equipo de tres personas no necesita un consejo de gobernanza, necesita un conjunto de decisiones compartidas que dejen de discutirse en cada sprint.
7 min
Empieza por los tokens y las restricciones, no por una librería de componentes
El primer paso de mayor impacto es acordar un conjunto pequeño y fijo de colores, valores de espaciado, tamaños de tipografía y radios, y hacer cumplir que nada se construya fuera de ese conjunto. Esta sola restricción evita la deriva lenta hacia veintitrés tonos de azul que ocurre naturalmente cuando cada desarrollador elige un valor que se ve 'suficientemente parecido'.
Una librería de componentes construida antes de que existan estas restricciones simplemente hornea la inconsistencia dentro de piezas reutilizables. Define bien los tokens primero, aunque sea de forma informal en un archivo compartido, antes de invertir tiempo en componentizar nada.
Documenta las decisiones, no solo los componentes
La parte más valiosa de un sistema de diseño para un equipo pequeño suele no ser el archivo de Figma, sino el registro escrito de por qué se tomó una decisión, como por qué los botones nunca usan estilo outline debajo de cierto tamaño, o por qué los formularios siempre muestran errores en línea en vez de un resumen arriba. Sin ese registro, el mismo debate resurge cada pocos meses y se decide de forma inconsistente.
Un documento breve y vivo que capture el razonamiento toma menos tiempo del que la gente espera mantener y ahorra mucho más tiempo del que cuesta al terminar con debates repetidos.
Reutiliza primitivas existentes en vez de construir una librería de componentes desde cero
Los equipos pequeños no tienen la plantilla para construir y mantener una librería de componentes completamente personalizada como puede hacerlo una empresa grande. Construir sobre una librería de primitivas accesibles sin estilos propios, agregando encima tus propios tokens visuales, le da al equipo la mayor parte del valor de un sistema propio sin la carga de mantenimiento de varios años.
La gobernanza debe ser un canal de Slack compartido, no un comité de revisión
Un equipo pequeño no necesita un proceso de aprobación para cambios al sistema de diseño. Necesita un hábito: cuando alguien quiere desviarse de un patrón existente, lo dice en un canal compartido antes de publicarlo, y el equipo decide rápido. Los procesos de gobernanza formal diseñados para organizaciones de diseño de cincuenta personas frenan activamente a un equipo de cinco sin sumar consistencia real.
Revisa el sistema cada trimestre, no de forma continua
Los equipos pequeños no tienen capacidad para mantener un sistema de diseño como un flujo de trabajo continuo. Establece una revisión recurrente y acotada en el tiempo, trimestral suele bastar, para corregir la deriva que inevitablemente ocurre entre revisiones, en vez de intentar forzar consistencia perfecta en tiempo real.
Want this applied to your own site?
We start with a free website and search audit, then show you exactly where the revenue is leaking.