La única forma de hacer que un sistema sea útil, es conociendo los dolores y necesidades de quienes lo usarán. Te proponemos un método para lograrlo.
Una de las principales razones para crear un sistema de diseño (design system) es agilizar la creación y la mejora de un producto o servicio para eliminar tareas repetitivas, no duplicar esfuerzos y no gastar tiempo en discutir decisiones ya tomadas. Esto permite que el equipo se enfoque en solucionar problemas reales de los usuarios, en vez de buscar resultados que otro equipo de trabajo ya resolvió.
Momentos incómodos en la adopción
Implementar un sistema de diseño implicará un cambio en la forma de trabajo de algunas personas: quizás, el equipo de desarrollo tenga que usar una nueva librería para adaptarse al sistema de diseño; tal vez, marketing tendrá que adecuar el estilo de redacción en redes sociales, o uno de los diseñadores tenga que desechar plantillas que armó por sí mismo. A lo anterior, debemos sumarle tener que aprender desde cero cómo usar un sistema de diseño, consultar constantemente la documentación, entre otras situaciones que pueden generar malestar entre los colaboradores.
Todo esto crea el escenario ideal para que estas personas empiecen a crear funcionalidades, componentes o reglas que se subirán a producción, pero no serán actualizadas en el sistema de diseño. Y una vez que la versión en producción de nuestro producto o servicio está algunos pasos más adelante que nuestro sistema de diseño, este último deja de tener sentido.
Esto evidencia que nuestro sistema de diseño solo está añadiendo límites que restringen la capacidad del equipo a crear con libertad sin agilizar el trabajo. Entonces el aspecto colaborativo y el objetivo de enfocarse en actividades más productivas a partir del uso de un sistema de diseño se pierde por completo.
Si creemos que los usuarios finales no tienen la culpa por no saber o no querer usar nuestro diseño, ¿por qué los colaboradores de nuestra organización serían culpables si son usuarios de nuestro sistema de diseño y no lo usan?
Un sistema de diseño con enfoque en los stakeholders
Al igual que en un proyecto de UX o service design, la única forma de hacer que un sistema de diseño sea útil, es conociendo los dolores y necesidades de quienes lo usarán. Por eso, debemos entrevistar a los usuarios que, dentro o fuera de la organización, interactúan con dicho sistema. Así, identificamos oportunidades de mejora que faciliten su adopción.
No hay duda de la importancia de hacer entrevistas y test de usuarios, antes y durante la creación de un sistema de diseño. Si bien puede haber beneficios al entrevistar a toda la organización, posiblemente sea mejor que nos enfoquemos solo en algunos usuarios.
Una forma de determinar a quiénes entrevistar y con quiénes probar un sistema de diseño es usando un stakeholder map.
El stakeholder map para nuestro sistema de diseño
Existen muchos formatos de esta herramienta, pero nosotros utilizaremos el formato de matriz. Cuenta con dos ejes: el horizontal corresponde al nivel de interés en un proyecto y el vertical, al nivel de influencia o poder de decisión. Se colocan en post it los nombres o áreas de la organización que serán afectados por ese proyecto. Entonces, quienes tienen mayor poder de decisión o influencia y poco interés se ubicaran en el cuadrante superior izquierdo. Si por el contrario, quienes tengan poco influencia pero mucho interés deberán ser colocados en el cuadrante inferior derecho.
Lo que haremos ahora es darle un giro a su uso tradicional. Nuestro objetivo será enfocarnos solamente en el nivel de influencia e interés. Por ello, vamos a retirar las rejillas que definen los cuadrantes y desestimar los nombres de los cuadrantes.
Hacemos una lista de los stakeholders que se ven o verán afectados e involucrados en nuestro sistema de diseño. Incluyamos roles gerenciales pero también a personas responsables de crear, hacer o intervenir en los productos o servicios de la organización, así como a quienes tercerizamos labores.
En nuestro caso la vertical influencia significa 2 cosas: la influencia en la organización y el poder de decisión sobre el sistema de diseño. Mientras que el interés, es el grado en que el sistema afecta el trabajo de los stakeholders una vez implementado.
Ahora para definir a quienes entrevistamos y con quien probaremos el sistema de diseño, trazamos una línea diagonal desde la mitad de la parte superior de la matriz, hasta el punto más extremo de la parte inferior derecha.
Todos los puntos que entren en el espacio que generó la línea diagonal (área resaltada en rosado en el gráfico) son los principales stakeholders de nuestro sistema de diseño.
Pensar primero en los equipos de desarrollo, equipos de diseño y altas gerencias de la organización como grupos de interés claves es lo común. Sin embargo gracias al ejercicio anterior, podemos visualizar otros actores que pasan desapercibidos pero son importantes.
Poner todos los stakeholders primero y trazar la diagonal después, nos permite reducir el sesgo. De este modo, podemos preguntarnos si realmente debemos incluir o no, a aquellos que no son la opción más obvia. Consideremos además, que el espacio generado por la diagonal no es estricto, por lo que es importante revisar las opciones que quedaron fuera de él pero impactan notablemente en nuestro sistema.
Como vemos, la importancia en el uso de esta herramienta no solo radica en sus resultados, sino también que nos da la oportunidad de generar conversación y debate sobre ellos, así como comprender que un sistema de diseño no solo afecta a desarrolladores y diseñadores.
En Continuum, abordamos tus desafíos de negocios uniendo el poder del diseño con el desarrollo tecnológico y el conocimiento de negocios. ¿Tienes un desafío donde estas disciplinas marcan la diferencia? Conversemos en hola@continuumhq.com.
