Hacia una pedagogía UX

Mientras el mundo entero se re-inventa las formas de diseñar interfaces, experiencias de usuario, servicios y las cosas conectadas a internet, muy pocos se preocupan por reinventar la forma en que se explican, se muestran y se justifican los usos de las metodologías de diseño frente a aquellos que las contratan o se benefician de ellas.

Es como si se perdiera de vista el propio método para hacer comprensible lo complejo. Entonces aparecen en escena nuevos profesionales de la experiencia del usuario frente a sus clientes. Algunos sobre-actuados con herramientas que se ponen de moda y que casi siempre son bien difíciles de pronunciar… desde la desgastada palabra wireframe, pasando por las teatrales scenarios y storytelling, hasta el famosísimos y a veces ininteligible journey map.

Para hacer experiencia de usuario de verdad se deben tocar las fibras organizacionales de una compañía, y eso sólo se puede realizar si se lleva de la mano uno a uno de los miembros de un proyecto (stakeholders) para gestionar el cambio. De lo contrario todos los esfuerzos serán inútiles y seguirás vendiendo entregables, no experiencias.

Llevar de la mano implica generar empatía, comprender las debilidades y fortalezas de cada empresa, lidiar con temas que a veces no queremos, y sobretodo llevar al cliente a que haga preguntas sin temor. No hay nada peor para un líder tecnológico o de mercadeo que contratar un servicio sin comprender la totalidad de él y sentirse débil frente a su equipo.

He visto como algunas empresas de diseño y tecnología, de todos los tamaños, se aprovechan del desconocimiento digital y técnico del cliente, para enredarlo entre post-it y post-it, y extensos e impecables documentos que hasta parecieran oler bien, preocupándose más por la aprobación que por la apropiación de los mismos. Incluso aún después de 11 años dedicada a esto, sobre-caigo en este mal que me aqueja y por el cuál escribo esto.

Enseñar para transformar

A finales del 2010, siendo arquitecta de información freelance, tuve la oportunidad de trabajar en el diseño de un sitio web sobre el que se migraría un famoso e histórico libro de papel. Trabajé en la estructura preliminar y primeros bocetos (wireframes) un poco más de tres semanas hasta que me invitaron a presenciar la primera entrega. Nuestro público tenía poca, o casi nula, experiencia en diseño digital… (aunque de sus bolsillos sobresalieran los más costosos y últimos celulares de alta tecnología).

Cinco minutos después de la presentación, una colombo-española, líder interna del proyecto, me dijo cautelosamente al oído: “Joder, ¡pero no entiendo nada!”. En la pantalla se mostraban una jerarquía de elementos rectangulares, atados a otros por líneas, mostrando la relación jerárquica de secciones y capítulos. Todos miraban con atención pero hacían pocas preguntas, o preguntas descontextualizadas. Claramente nadie entendía nada.

Aunque en el proyecto yo era más una invitada y no expositora, por experiencia en situaciones similares sabía que mostrar un sitemap sin contexto (o con contexto) era un arma de doble filo. Es de los entregables más complejos de entender por cualquier persona que no se dedique al tema. Este instrumento sólo genera las más tediosas, largas y confusas discusiones.

Si el cliente viera el sitio web como una pieza industrial, o una obra de ingeniería, esto no sucedería porque las estructuras se levantan imponentes ante nosotros y nos acostumbramos a ellas…. Mientras no le aclaremos al cliente que la interfaz no es sólo lo que se ve y que la tecnología no es sólo funcional, sino también lo humano seguiremos recibiendo preguntas frente a sitemaps como: ¿Dónde está el formulario? o frente a wireframes: ¿El sitio va a quedar así?

¿Cómo así pedagogía UX?

No sólo se trata de enseñar a hacer UX sino de enseñar a comprender y valorar los instrumentos que se usan. Hacer que tu cliente te entienda y además se apropie de los conceptos, es lo que deberías considerar un éxito. Pero el tema no es fácil, nada fácil, menos en un mercado latinoamericano donde la venta de humo se cotiza a la alza.

Este año he tenido ganas de abandonarlo todo ante la frustración que me ha generado no poder comunicarme con interlocutores técnicos de la misma manera. Asumí que si los ellos trabajan en tecnología me entenderían, pero al parecer el lenguaje de la UX no es tan familiar como creemos.

Por eso recomiendo algunos aspectos claves que deberíamos tener en cuenta si es que queremos un proceso menos conflictivo de comunicación :

1. Identificar el público objetivo y segmentar las presentaciones según nivel de expertise de la audiencia: ¿Son ingenieros, diseñadores, administrativos?¿Han trabajado previamente como UX? ¿Conocen los conceptos UX?¿Qué entienden por wireframe, mockup, sitemap, blueprint? ¿Han utilizado herramientas para dar feedback de diseño?¿Están más adapatados a feedback remoto o presencial?¿Qué medios utilizan para hacer seguimiento a sus proyectos?
2. Explicar en el kick-off del proyecto qué se entregará en cada fase: Si es posible generar un documento físico que lo puedan tener como hoja de ruta o documento de referencia. (Como los handouts o programas de mano que te dan en un curso).
3. Evitar anglicismos y/o reemplazarlos con conceptos relacionados. En nuestra empresa, dependiendo del público objetivo a los wireframes los llamamos bocetos digitales o planos del sitio, eso ha mejorado la comprensión en varios escenarios. Así mismo siempre que utilicen una palabra nueva para el equipo, validar si todos manejan el concepto e incentivar a que hagan preguntas hasta aclararlas (es mejor tardarse más tiempo en esta reunión que irse tropezando todo el proyecto porque alguien no entendió)
4. Introducir cada presentación de un entregable explicando sus objetivos: Qué es, por qué lo hicimos, cuál es su objetivo, en qué se debe enfocar la revisión, que esperamos del cliente cuando lo revise.
5. Planear las reuniones con líderes de proyecto antes de que presenten resultados a stakeholders no técnicos: Dependiendo de la disciplina de origen o cargo en una compañía, la interpretación del diseño puede tomar muchísimo matices. He visto como grandes decisiones de diseño e innovadoras ideas UX, se vienen abajo porque el presentador (no directamente el diseñador) no pudo explicarle al cliente el beneficio de dichas decisiones. Planear y preparar al presentador debería ser parte de este ejercicio de mejorar la pedagogía de la experiencia.

Si bien el proceso educativo puede ser muy diferente según el tipo de cliente, este esfuerzo pedagógico debería transmitirse a todo el equipo que diseñará la experiencia. En Usaria, por ejemplo, dependiendo del tipo de cliente hemos empezado a desarrollar algunos protocolos para reuniones de inicio, talleres, revisiones, incluso paso a paso o tips para mejorar la forma en que el cliente da feedback y así aprenda y comprenda cómo podemos hacer más efectivo el tiempo de ajustes. Por ahora el camino es largo, pero vale la pena comenzar a andarlo y explorar de manera iterativa qué da mejores resultados, de tal manera que se pueda mejorar la experiencia del cliente y sobretodo el desempeño del equipo.