Proponer amplio, entregar acotado
El Problema
En PariPassu, trabajando como una de las dos designers en dos productos, propuse un conjunto de componentes nuevos más amplio del que el equipo necesitaba, intentando anticipar edge cases entre Rastreador y CliCQ. En pocas semanas quedó claro que parte de las variantes nunca se usaba. Agregaban carga cognitiva sin retorno real, y la sensación de inflamiento ralentizaba la adopción.
Lo Que Probé
Mi enfoque fue completista: 'Vamos a anticipar todos los casos y construirlos de una vez.' Mapeé muchos estados de botón, variantes de card, tipos de input y edge cases basados en ejercicios de design thinking, plantillas previas y patrones de DS maduros de empresas más grandes.
Por Qué Falló
La premisa era errónea. PariPassu era una foodtech ágil sirviendo trazabilidad e inspección de calidad. Las necesidades reales a corto plazo eran una fracción de lo que había diseñado. '¿Uso CardStandard, CardCompact o CardMinimal?' Sin resolver problemas reales, estaba diseñando para futuros hipotéticos en vez de validar demanda actual.
La Lección
Los design systems crecen con el producto, no por delante. Los mejores DS que vi en empresas más grandes (Bridge, Multidrop) no salieron completos el día 1; empezaron acotados y escalaron a medida que los patrones aparecían en el uso real. Mantenerlo acotado significaba: (1) ingeniería entendía cada componente porque los usaba todos. (2) Iterábamos más rápido, menos decisiones, PRs más rápidos. (3) Cuando aparecían patrones nuevos, los agregábamos de forma deliberada.
El Resultado
Junto con la otra designer, podé la propuesta a los componentes que el equipo realmente usaba, mantuve la documentación enfocada en esos y hice pair con devs para ajustar tokens. La poda colaborativa facilitó la adopción e hizo que los componentes nuevos se agregaran solo cuando el uso real lo exigía.
Impacto
Handoff de diseño-ingeniería más rápido, menos parálisis por decisión y un sistema que reflejaba cómo se construía el producto, no cómo yo creía que debía ser.