Es bien sabido en el mundo del diseño de productos digitales que la conversación sobre el término UX es casi que prohibida. La evitamos como conglomerado y dejamos pasar porque se torna repetitiva, sin sentido y muchas veces hasta aburrida, llegando al punto de tratarlo como si fuera hablar de religión o política en una reunión familiar.

Sin embargo, cada cierto tiempo surgen preguntas, posiciones o cuestionamientos que merecen la pena volver a revisar.

Este post es una respuesta un poco más larga a la que Twitter me permite dar (sin pagar Blue), y que realmente merece un acercamiento a la pregunta que hace Franzia.

La pregunta de Franzia también referencia la siguiente imagen que estuvo rondando redes sociales y que destapó muchas críticas, entre ellas, lo corto que se queda para explicar la disciplina, sobretodo para los iniciados.

Entre otras cosas, mi principal crítica a este tipo de gráficas que intentan crear un framework para explicar algo mucho más complejo, es que hace difuso el panorama completo, y peor aún, se vuelve forzoso en los detalles.

Solamente con observar los cuadrantes y sus actores se puede inferir algunos sesgos del creador: UX Researcher cubre todo el cuadrante UX Research, Business Analyst cubre todo el cuadrante de Analysis, Design Ops con Operations; casi todos los especialistas de cada cuadrante cubren su cuadro por completo, excepto uno: el Interaction Designer.

Y ustedes dirán "Omar, te lo estás tomando personal, esto no es contra los IxD", pero es que nomás de observar los espectros propuestos para UX Designer y Product Designer caigo en cuenta: es el clásico sesgo de que los diseñadores de interfaz o los de interacción solo son "pixel pushers", meros peones dentro de la maraña complicada de problemas que al parecer solo un UXer puede tejer. 

La extraña idea de que estos roles no "tocan" el resto de los cuadrantes me parece siempre sorprendente porque habla de una total desinformación de la disciplina.

Pero volvamos a la pregunta inicial, empecemos con que es bastante complicado buscar una forma de simplificar o definir algo que sigue transformándose y encontrándose a sí mismo. La disciplina del diseño UX como lo conocemos aún no llega a su maduración, los más antiguos sitúan la disciplina en una línea de tiempo menor a 70 años.

Sabiendo esto podemos comenzar a hilar soluciones. Por la dificultad de explicar este tema con conceptos podemos hacerlo a partir de experiencias (no pun intended) propias o ajenas que ejemplifiquen lo que se intenta explicar.

La forma en como lo he hecho con mis alumnos y que mejor me ha dado resultado es partiendo de un contexto. Los equipos de diseño pueden llegar a ser multidisciplinarios y muy especializados, todo depende del problema que se quiera resolver en un tiempo determinado.

Esto puede llegar a ser caótico, pero aceptando el caos y dejándolo fluir es como he descubierto que se comprende mejor.

No es lo mismo una dupla que diseña una funcionalidad específica, a un equipo grande dedicado a sacar una aplicación completa; diseñar un sitio web con mucha información, a una aplicación con varias capas de navegación; diseñar para 10 millones de personas, a diseñar para 20 usuarios; diseñar para momentos de caos y estrés intenso, a diseñar una app para VR con el enfoque casi por completo de parte del usuario.

Lo importante de los escenarios y su variedad, es entender los diferentes tipos de problemas a los que un equipo de diseñadores se puede enfrentar (ver también AARRR).

Luego de especificar el escenario, toca explicar cómo funcionan los equipos a través de los roles. ¿Qué hace un diseñador de interacción con uno visual? ¿Cuál es el rol de un uxer en un equipo de producto? ¿Cómo deberían trabajar para lograr el objetivo propuesto? ¿Qué habilidades diferencian entre un diseñador visual y un arquitecto de información en los diferentes escenarios que pueden existir? ¿Cuántos diseñadores, investigadores, analistas necesitas para atacar el problema propuesto?

Es probable que un UX Designer (como la industria los hace llamar) con algunos de estos escenarios y roles se necesite sea más enfocado en crear artefactos que permitirá al resto del equipo construir una aplicación sólida y cimentada, o que en otra combinación de escenarios le toque ser un arquitecto de información, pero para otra combinación sea más cercano a un líder donde esté más cerca de las responsabilidades de un estratega que de un researcher, o quizá sólo quizá, en una de esas combinaciones le toque ser un simple pixel pusher.

Mostrar estos escenarios explicando las responsabilidades y jugando con las combinaciones puede llegar a ser muy didáctico. Personalmente he probado una presentación pequeña seguida de una actividad como un juego de roles, haciendo que la curiosidad de los participantes se agrande por las diferentes facetas que los diseñadores pueden llegar a vivir.

Al final, el mensaje principal es que no importan mucho los nombres de los roles, lo que importa es la combinación de habilidades que se pueden establecer en la creación de un equipo. Si los alumnes mantienen su mente abierta a esas posibilidades, habrán aprendido a lidiar con el caos que presenta una disciplina todavía joven, todavía en plena definición. 
 

Ya para terminar, quería compartirles uno de los primeros diagramas que vi sobre la disciplina por allá del 2013, no sin antes resaltar sus críticas que aún siguen vigentes. Es un diagrama que probablemente ayude para introducir algunos conceptos, pero no para ahondar con tanta versatilidad que podemos encontrar en esta disciplina.

Espero que esta respuesta sea de ayuda para Franzia que dió con la pregunta correcta para darle sabor a este humilde newsletter que apenas va en su tercera edición.

No olviden escribirme directamente en Twitter para seguir la conversación del tema.

Hasta la próxima.