Cómo escalar un sistema de diseño

Últimamente hemos hablado de los diferentes beneficios de aplicar un sistema de diseño a la hora de desarrollar productos consistentes y escalables. Hemos visto que, muchas veces, las grandes organizaciones (y no tan grandes) añaden más ingredientes a la mezcla en vez de mantenerlo y desarrollarlo desde una misma perspectiva para aprovechar todo su potencial.

Perfiles de UX que se encargan del diseño visual. Diseñadores que maquetan front-end. Desarrolladores que diseñan. Product managers que participan y ejecutan en cualquier parte del proceso… Y todo se complica si los equipos están distribuidos físicamente, siendo imposible estar al tanto de todo. Nadie es tan omnipresente, omnipotente u omnisciente. Se debe trabajar en conjunto para construir algo más grande y cohesionado.

Imagen de UX Planet

Entonces, ¿cuál es la mejor forma de crear un equipo que sea capaz de ayudar a crear y mantener un sistema de diseño coherente? Enamorada de que el trabajo colaborativo es la única forma de construir buenos productos, y obtener equipos implicados, me ha parecido inspirador el artículo que ha escrito Nathan Curtis. Es fundador de la firma Eight Shapes, y explica los tres tipos de aproximación que están tomando las empresas para lograr esto. Desde equipos en solitario a equipos centralizados focalizados en el desarrollo del sistema de diseño, pasando por un modelo mixto hacia un enfoque, más complejo y potente, que Curtis denomina federado.

Modelo en solitario de construcción de sistemas de diseño

El modelo de equipo solitario para construir un sistema de diseño es muy frecuente y, en determinados contextos, puede ser útil. Esta aproximación consiste en que un equipo desarrolle un sistema de diseño, pero con el esfuerzo enfocado principalmente en sus necesidades.
La biblioteca está disponible para todos, compartiendo ese valor: un sistema de componentes en producción, basado en un lenguaje visual aprobado, mantenido y desarrollado por el equipo.

Este modelo puede funcionar cuando el resto de los equipos carecen del talento y la capacidad de diseño y front-end. Tener esta fuente establecida proporciona un valor significativo. Siempre podrán tomar algunas partes que les ahorren tiempo, si está suficientemente modularizado. Sin embargo, no funciona cuando las necesidades de producto difiere bastante entre necesidades de los equipos. Por ejemplo, cuando un equipo está haciendo una app para el usuario final y otro está haciendo un aplicación de escritorio para usuarios internos de la organización.

Además, hay que aclarar que aunque el equipo comparta su biblioteca no significa que tengan que aceptar sugerencias del resto de los equipos. Están centrados en su propio producto, en crear componentes adaptados para lo que necesitan y las peticiones del resto de equipos son una distracción.

Cuando ocurre esto, como organización olvídate de mantener y crear un sistema coherente. El resto de equipos va por su cuenta, y si es capaz, dado que tiene que seguir entregando un trabajo y creando un producto, no puede estar parado y construye sus propios componentes.
¡Hola, aplicaciones monstruito! ¡Hola, usuarios que deben aprender a usar un patrón diferente para la misma tarea!

Modelo centralizado de construcción de sistemas de diseño

Un equipo centralizado consiste en un grupo de personas dedicado, que elaboran y difunden las decisiones y componentes del sistema de diseño para que otros equipos lo utilicen, pero puede que no estén diseñando ningún producto real. El sistema de diseño puede haber sido diseñado por ellos mismos, o tal vez estén implementando una visión producida por una agencia externa.

Parte de su obligación es ayudar a que el resto de unidades entienda cómo usar el sistema de diseño, y lo aplique de forma correcta, escuchando todas las necesidades que les puedan surgir al resto de equipos para seguir evolucionándolo en base a ellas.

El equipo del sistema centralizado debe:

• Difundir el lenguaje de diseño, componentes y patrones.
• Servir a muchos equipos de producto, sin estar condicionados por las prioridades de ningún producto.
• Identificar oportunidades y solicitar nuevas aportaciones para seguir haciendo crecer la biblioteca.
• Realizar pruebas de configuración y procesos para validar lo que realizan.

Sin embargo, los equipos centralizados a menudo carecen de:

• Contexto, las soluciones normalmente no abarcan las necesidades reales del producto.
• Poder, para fomentar la participación activa de los diseñadores de los otros equipos de productos.
• Visibilidad de los desafíos diarios específicos del producto.
• Influencia en el resto de los equipos para equilibrar las compensaciones entre los objetivos del producto y del sistema.

Este tipo de equipos puede conseguir dar un excelente servicio y crear valor de forma eficiente y consistente. Pero su posición puede no ser fuerte, y aquellos equipos de productos que desean mantener su autonomía es posible que no sigan sus directrices. No hay que olvidar que es un equipo el que diseña y construye lo que otros van a usar y esa imposición muchas veces no es bienvenida. Algo que no has creado tú, no lo sientes como propio ni te involucras en su evolución, lo cual va en detrimento del crecimiento del sistema de diseño en el largo plazo.

Modelo federado de construcción de sistemas de diseño

Este modelo es más complicado, y tiene sus detractores, pero puede servir para aquellas organizaciones con equipos más maduros y talento de alto rendimiento. Los mejores diseñadores deben estar trabajando en los productos más importantes para averiguar qué se necesita realmente, construir el sistema y distribuirlo entre todos los demás. Pero sin dejar sus trabajos diarios en los equipos de productos.

En los últimos años, gracias a Google, ha aumentado el pensamiento sistemático entre los diseñadores. Un grupo pequeño pero creciente de diseñadores empoderados formó lo que se convirtió en Material Design utilizando un enfoque «comité por diseño». Ese comité releva la dirección del diseño del sistema a un subconjunto representativo y facultado de diseñadores, líderes designados para colaborar en el sistema por un período de tiempo. Toman decisiones de diseño colectivamente, aunque luego sean otros los que las crean, desarrollan y comunican para que se propaguen a todos los equipos de productos y que aprovechan el resultado (o lo ignoren bajo su propio riesgo).

Por tanto, un equipo federado debe:

• Ampliar la visión parcial, para que las diferentes plataformas y líneas de negocios se vean representadas.
• Reducir las percepciones de sesgo al representar diferentes perspectivas.
• Facilitar la difusión del sistema entre los equipos al estar más implicados en su desarrollo y sentirlo como suyo.

El problema, puede ser que al haber tanta gente implicada, las decisiones sean difíciles de tomar. Cada conversación es una suma de conocimiento pero nadie realiza un seguimiento o puede recordar el camino que condujo a una decisión. Además, cada diseñador conserva la autonomía y la lealtad hacia su equipo de producto. Y es que, para participar en este modelo, un diseñador debe ser capaz de olvidarse de sus propias necesidades por conseguir un mayor bien común para lograr una experiencia de usuario coherente.

Formar un equipo bajo el modelo federado

Como comenta Curtis, un equipo federado está constituido por un conjunto de diseñadores designados por un comité durante un período de tiempo. Por ello, ¿quién está disponible? ¿Por cuánto tiempo? ¿Cuándo necesitamos el sistema? ¿Quién tiene las habilidades para identificar y construir las piezas que necesitamos? Lo ideal es que esté formado por una mezcla de diseñadores de los diferentes equipos, con gran experiencia, que sean capaz de movilizar y hacer (shakers y doers).

La amplitud del talento del equipo que diseña el sistema se verá reflejado en el alcance del sistema. Los implicados deben ser expertos en UX, arquitectos de información, diseñadores visuales y de interacción que trabajen conjuntamente para conseguir un producto que:

• Resuelva problemas de experiencia del usuario como navegación, flujos y tareas.
• Posea un estilo visual como color, tipografía e iconografía.
• Ofrezca interacciones con un enfoque particular en patrones de IU, animación y movimiento.

Mezcla de “doers” y “managers”

Para que un equipo federado sea efectivo se debe distribuir la toma de decisiones del sistema y su desempeño a lo largo de la jerarquía de gestión. Todo el mundo debe colaborar para sentirlo como propio.

Una posibilidad es integrar a managers de diseño (es decir, diseñadores que coordinaban equipos de 10 o más diseñadores) con los diseñadores que crean el sistema. Los directores trasladan el trabajo realizado a los diseños de sus equipos, ya que como habían participado lo sentían como suyo. También aportan personal talentoso de sus propios equipos, para trabajos puntuales centrados en el sistema.

Inversión en documentación y comunicación

Las guías que representan el sistema de diseño no se construyen solas. No aparecen mágicamente para mostrar a todos los equipos cómo pueden hacer las cosas. Cuando el sistema de diseño se estabiliza, debe haber un equipo de diseñadores que lo documente y mantenga.
Y conforme se van definiendo los elementos, los equipos deben descubrir cómo comunicar esos cambios de forma fluida y continua.

Por mi experiencia, éste es el punto donde más fallos aparecen en muchas organizaciones. Los buenos equipos tienen una idea clara de quién documenta estas decisiones y cómo se comunican manteniendo el sistema vivo. Los equipos de alto rendimiento establecen plataformas (como repositorios de GitHub u otras herramientas de publicación de contenido) que permiten que una serie de personas evolucione continuamente el sistema.

Un equipo federado necesita un componente centralizado de personal dedicado a la causa, lo que puede verse como un gasto en vez de una inversión. Es misión de los managers crear el espacio y disponer de las herramientas para las personas hagan su trabajo, asegurando que haya personal cuya responsabilidad prioritaria o parte de su trabajo sea mantener el sistema. Sin ese esfuerzo continuo, cualquier sistema de diseño puede ser inservible en pocos meses.

Contribución y autonomía

Los equipos federados no buscan que haya personas que se dediquen exclusivamente al sistema una vez que está creado. Prefieren la aportación de diseñadores periféricos dispuestos (y capaces) de contribuir. Aunque haya un equipo dedicado a crearlo, cuanto más se involucren los diseñadores externos y acepten el sistema, más tolerante e interesado estará el equipo que lo crea hacia las ideas que proponen los demás.

Crear, construir y mantener un sistema de diseño usable, potente, comprensible, que perdure en el tiempo es una tarea que requiere inversión. Especialmente, cuanto más complejos y amplios sean los productos y servicios. Pero, si no se consigue, la experiencia de usuario a lo largo de las interacciones con la empresa se percibirá desestructurada e inconsistente. Y eso solo puede derivar en usuarios insatisfechos que busquen otra compañía.

En Torresburriel Estudio contamos con los mejores especialistas en Experiencia de Usuario para realizar o mejorar tu proyecto o servicio siempre aplicando metodologías de diseño centradas en el usuario. Contacta con nosotros y cuéntanos tu proyecto.