Los sistemas de diseño como medio, no como fin
Llevo tiempo dándole vueltas a una cuestión que me parece central en cómo estamos abordando los sistemas de diseño. Y es que, siendo algo tremendamente útil, especialmente para quienes trabajamos con mucho foco en B2B, donde la consistencia y la eficiencia son críticas, corremos el riesgo de perder de vista para qué diablos estamos haciendo todo esto.
Los sistemas de diseño industrializan el diseño. Eso es un hecho, no un juicio de valor. Nos permiten escalar, mantener coherencia, optimizar recursos. Perfecto. Pero aquí es donde empiezan mis dos grandes preocupaciones.
La investigación como fundamento ausente
La primera tiene que ver con los cimientos. Demasiadas veces me encuentro con sistemas de diseño que nacen huérfanos de investigación con usuarios. Se construyen sobre supuestos, sobre «mejores prácticas» copiadas de otros contextos, sobre la experiencia acumulada del equipo. Y todo eso está bien, pero no es suficiente.
Un sistema de diseño tiene que ser la respuesta articulada y sistemática a necesidades reales, descubiertas y validadas. Debería nacer de un proceso metodológico, iterativo y constante de investigación con usuarios que establezca el marco de juego: qué problemas estamos resolviendo, para quiénes, en qué contexto, con qué limitaciones y oportunidades.
Sin ese trabajo previo y continuado, el sistema de diseño se convierte en una biblioteca de componentes estéticamente coherente pero estratégicamente ciega. Es como construir una casa sin saber quién va a vivir en ella ni para qué la necesita.
El alma del proyecto
La segunda preocupación es más sutil pero quizá más grave: el riesgo de que el sistema de diseño se convierta en el objetivo, en lugar de ser el medio.
Me preocupa especialmente el papel del liderazgo de diseño en todo esto. Cuando la dirección de equipos de diseño no tiene clara, o no comunica con claridad, la función real de un sistema de diseño, se produce una deriva peligrosa a mi juicio. El trabajo se centra en mantener el sistema, en perfeccionar componentes y en evangelizar su uso. Y se pierde de vista aquello que justifica cualquier producto digital: satisfacer necesidades de usuarios, cumplir objetivos de negocio y hacerlo de manera sostenible en un mercado concreto.
El sistema de diseño no debería ser un fin en sí mismo. Es un medio. Un medio sofisticado, potente, que permite hacer mejor nuestro trabajo y que proporciona grados de sostenibilidad de producto nunca antes conocidos. Pero un medio al fin y al cabo.
Liderazgo deficiente, resultado deficiente
Aquí es donde el liderazgo de diseño se vuelve crucial. Si quien dirige no entiende esta distinción, o peor, si la entiende pero no actúa en consecuencia, el sistema de diseño puede convertirse en un obstáculo en lugar de en un catalizador.
He visto equipos completamente absorbidos por el mantenimiento de su sistema de diseño, incapaces de salir de ahí para hacer el trabajo de fondo: entender usuarios, validar hipótesis, explorar alternativas, cuestionar decisiones. El sistema pasa de ser una herramienta de eficiencia a convertirse en una cárcel autoimpuesta. Algo así como una cárcel de oro, que es cárcel al fin y al cabo.
Esto no es un problema técnico. Es un problema de dirección, de visión y de prioridades mal establecidas.
Volver a lo esencial
Los sistemas de diseño están aquí para quedarse, y me parece bien. De hecho hace tiempo que se han quedado. Pero necesitamos recuperar la perspectiva. Necesitamos líderes de diseño que entiendan que su trabajo no es construir el sistema más bonito o más completo, sino usar ese sistema como lo que es: una infraestructura que permite al equipo concentrarse en lo que importa.
¿Qué es lo que importa? Entender a los usuarios. Eso no es nuevo. Por lo menos en este blog. Lo que importa es resolver problemas reales. Lo que importa es crear productos que funcionen para las personas y para el negocio, de manera sostenible y alineada con el mercado.
El sistema de diseño es el andamio. Nunca debería confundirse con el edificio.
Accionables desde la experiencia
Diagnosticar problemas es fácil. Lo difícil es proponer soluciones que funcionen en el mundo real. Desde nuestra experiencia trabajando con equipos de diseño en organizaciones de todo tipo, estas son las prácticas que marcan la diferencia:
- Invertir en formación específica de liderazgo en UX. No basta con ser buen diseñador para liderar equipos de diseño. Las habilidades de gestión de producto, alineación estratégica y gobernanza de equipos se entrenan. Programas como la Certificación UX-PM Nivel 3: Liderar UX están diseñados precisamente para esto: para que quienes lideran equipos de UX entiendan cómo conectar el trabajo de diseño con los objetivos de negocio y sepan gestionar la complejidad organizacional que eso implica.
- Practicar la transparencia radical con los equipos. Los equipos necesitan saber por qué hacen lo que hacen. No sólo el qué, sino el para qué. Compartir contexto de negocio, explicar las decisiones, hacer visibles las restricciones y las oportunidades. Un equipo que entiende el marco completo toma mejores decisiones en el día a día y no se pierde en el mantenimiento del sistema por el sistema. Mención aparte, la confianza que se genera cuando este proceso tiene lugar con altas dosis de transparencia contribuye a algo que gusta mucho a quienes pagan las facturas: el equipo es más eficiente.
- Asegurar una comunicación fluida y constante con stakeholders. El sistema de diseño no vive en una burbuja. Necesita estar conectado con producto, con tecnología, con negocio. Eso nos obliga a establecer canales de comunicación regulares, no sólo reactivos. Reuniones periódicas de alineación, demos de evolución del sistema, espacios para recoger feedback. Sin esto, el sistema de diseño se desconecta de la realidad del producto, o por lo menos hay más probabilidades de que así sea.
- Implementar doble validación de requerimientos. Antes de que algo entre en el sistema de diseño, debería pasar por dos filtros: ¿responde a una necesidad real validada? y ¿está alineado con la estrategia de producto? Esta doble validación evita que el sistema crezca por inercia, por apatía, o por peticiones puntuales que no tienen visión de conjunto.
- Mantener viva la conexión con user research. El sistema de diseño debería evolucionar en función de lo que se aprende de los usuarios, no sólo de las peticiones del equipo. Eso implica establecer mecanismos para que los hallazgos de investigación alimenten las decisiones sobre el sistema: qué componentes priorizar, qué patrones revisar, qué nuevas necesidades cubrir.
- Medir el impacto, no sólo la adopción. Es tentador medir el éxito de un sistema de diseño por su uso: cuántos equipos lo adoptan, cuántos componentes tiene, cuántas descargas. Pero eso no dice nada sobre si está cumpliendo su función. Las métricas que importan son las de impacto: reducción de tiempos de desarrollo, mejora en métricas de experiencia de usuario, alineación entre equipos. Si no medimos esto, no sabemos si el sistema está funcionando o sólo existe. Cuidado, eso último también nos dará una métrica de la madurez en diseño de la organización: si con que el sistema de diseño exista es suficiente, red flag a la vista.
- Reservar tiempo para el trabajo estratégico. El día a día del mantenimiento de un sistema de diseño es absorbente. Bugs, peticiones, documentación, ramas, soporte. Si el líder de diseño no protege activamente tiempo para el trabajo estratégico como revisar la dirección, cuestionar decisiones o explorar evoluciones, el sistema se convierte en un monstruo que se alimenta a sí mismo y del que se puede perder el control fácilmente.
Ninguna de estas prácticas es revolucionaria. Pero todas requieren intencionalidad, disciplina y, sobre todo, claridad sobre cuál es el objetivo final. El sistema de diseño está para servir al producto y a los usuarios. No al revés.
Foto de portada de Denys Nevozhai en Unsplash.
