02 mayo 2018

Como ya sabemos los que nos dedicamos a la experiencia de usuario, siempre ha habido mucha confusión sobre el término y sobre los aspectos que intervienen. De hecho es un tema recurrente tanto en congresos como en artículos, y estoy segura que much@s en nuestro día a día seguimos evangelizando y enseñando a los clientes sobre ello.


Foto de Susan Greig

Donald A. Norman, quién crea la idea del diseño de la experiencia del usuario, comenta sobre esta problemática la siguiente frase que ya habréis leído:

Inventé el término porque pensé que la interfaz humana y la usabilidad eran demasiado limitadas. Quería cubrir todos los aspectos de la experiencia de la persona con el sistema, incluida la parte gráfica del diseño industrial, la interfaz, la interacción física y manual. Desde entonces, el término se ha extendido ampliamente, tanto que está empezando a perder su significado. 

De hecho, en 2016, vuelve a hablar sobre este tema en este vídeo explicando que cuando pensaron en el término y crearon “User’s Experience Architect’s Office” en Apple, se referían a que la experiencia de usuario es todo lo que está relacionado con un producto.

Hoy en día, nos referimos a nosotros mismos o vemos ofertas de empleo, cosas como “UX Visual Designer“, “UX Interaction Designer“, “UX Services Designer“…cuando simplemente se refiere a diseñar una web o app, sin tener en cuenta el resto de la experiencia. Como dice Norman la experiencia de usario es todo, la manera en la que se experimenta el mundo, la vida, un servicio o si, una web o app, pero no de forma aislada sino como un conjunto.

Y es que como muchas veces digo cuando hablo sobre el tema, no sirve de nada, invertir mucho dinero en tener la mejor web o app del mundo, si luego cuando los usuarios van a al restaurante o al hotel, o llaman a atención al cliente, el servicio es pésimo.

Volviendo al tema, descifrar como se entiende la experiencia de usuario (UX – User eXperience) hoy en día requiere comprender la historia del diseño y el desarrollo desde la década de 1990. Están intrínsecamente vinculados, y es muy importante conocer los desafíos que supuso y supone la tecnología en su relación con los humanos.

Proceso UX en cascada

En su forma más pura, el diseño de la experiencia de usuario está basado en un formato de trabajo en cascada. Llega un cliente con una serie de requerimientos y el equipo intenta aprender e investigar todo lo que pueda antes de construir incluso el prototipo más sencillo. La investigación, aunque se hable de tests de guerrilla lleva su tiempo, y los resultados indican lo que contendrá el contenido, la interacción…

Seguro que te suena el proceso siguiente:

  1. Investigar para descubrir cuál es el problema
  2. Categorizar los problemas descubiertos y priorizarlos
  3. Crear Personas y Journey maps
  4. Ejecutar ejercicios de ideación para generar ideas
  5. Construir y probar un prototipo
  6. Envíar el prototipo final a desarrollo
  7. Lanzar el producto
  8. Volver al paso 1 para la siguiente iteración en base a lo que hacen los usuarios

Diseño no accede al trabajo hasta que es su turno y lo mismo sucede en desarrollo, igual que sucede con los elementos que definió Jesse James Garret que componen la Experiencia de usuario.

ElementosUX Jesse James Garret

The elements of USer Experience by Jesse James Garret

Agile

Esta forma de trabajar es incompatible con Agile. Durante mucho tiempo, la innovación en Silicon Valley fue impulsada por la Ley de Moore, la cual establece que la cantidad de transistores en un circuito se duplica aproximadamente cada dos años. Pero un día, Sony, Toshiba e IBM (The STI Alliance) cambiaron la historia.

STI creó el primer chip de celda, que juntaba 8 núcleos de microprocesador en un solo componente, y eso revolucionó todo. La velocidad y la flexibilidad reemplazaron la precisión y la previsibilidad como ventajas competitivas. Entramos en la era del consumismo puro y el cliente quiere cosas nuevas, ya no existe una necesidad básica de tener un coche y cojo el único que hay en el mercado, sino que quiere elegir que coche comprar. La famosa frase de Henry Ford “A customer can have a car painted any color he wants as long as it’s black” deja de tener sentido. El ritmo de trabajo y de producción se aceleró y si querías que los consumidores usarán tu producto debías de ofrecer siempre lo último. Sino, clic, nueva pestaña, y se van a comprar a la competencia.

Las empresas (sobre todo las grandes) con muchas capas jerárquicas y con toma de decisiones lentas estaban perdidas si seguían trabajando asi, y se puso de moda otra metodología de desarrollo ya conocida pero que no se empleaba bien: Agile.

Agile se centra en la iteración constante. Proporcionar valor añadido cada 2-4 semanas, evolucionando un producto a lo largo del tiempo en lugar de hacerlo todo a la vez ya que es imposible saber lo que va a suceder de aqui a más de 2 semanas. Está basado en hipótesis, experimentación, lanzar en producción de forma rápida y medir en tiempo real.

Con estos ciclos de lanzamientos de una o dos veces al mes, no había tiempo a que los diseñadores de UX ejecutaran todo el proceso. UX en algunos casos se veía como un elemento de bloqueo y ante eso, la mayoría de los equipos contrataron a diseñadores gráficos (o algunos viejos se adaptaron), bajo el nombre UI/UX Designer, que fueran capaces de generar los entregables necesarios cada 2 semanas. Esos diseñadores no eran UX reales en el sentido clásico, pero sabían lo suficiente sobre el diseño centrado en el usuario para evitar cometer los peores errores.

Por que claro, con la iteración en real, saldrían el resto de problemas.

Esto tuvo un impacto, distorsionando la percepción del mundo de los negocios de lo que hace un diseñador de experiencia de usuario. Hasta hoy en día, muchas empresas todavía piensan en UX como una disciplina visual.

Lean UX

En 2013 Jeff Gothelf escribe Lean UX (uno de mis libros favoritos) hablando sobre como integrar UX en un entorno ágil. Jeff presenta una serie de actividades de estrategia y alineación, que permiten a UX operar dentro del entorno de incertidumbre de ágil y actualizar rápidamente los diseños en función de los usuarios.

Lean UX se basa en los resultados, pero cuando el producto estaba vagamente definido, muchos ciclos de desarrollo se quemaban en características que nunca llegaban al producto final. El emparejamiento Lean UX/Agile parece que generaba un alto volumen de residuos y retrabajo cuando no se hacía bien.

En un producto maduro, al tener ya comentarios de los usuarios (si se les escucha) es más sencillo llegar al ciclo iterativo que impulsa a Lean UX. Sin embargo, en equipos nuevos, el ciclo de retroalimentación del usuario aún no se ha activado y es tarea de producto y UX encontrar esos usuarios fuera de mercado y testear el producto que están construyendo con sus necesidades y expetactivas. Pero ya sabemos como son los ciclos de trabajo de una startup y los recursos que suelen disponer, y antes contratan otro programador (que saque funcionalidades) que un UX (para eso ya tienen al diseñador).

Jake Knapp y Google Ventures escriben “Sprint Design” que aunque ya era algo más o menos inventado (Design Studio, Gothelf en el libro de Lean UX ya lo menciona) se pone de moda al estar enfocado sobre todo en Startups.

Design Sprint de Google Ventures

Si lo miras bien, un sprint de diseño es solo UX clásico rápido. La diferencia es el grado de detalle al que se trabaja, de una obra maestra a un boceto en una servileta, pero que si se hace bien, funciona.

El objetivo es validar lo más rapidamente una hipótesis, antes de invertir muchos recursos en ello. En 5 días, se deben realizar todas las investigaciones sobre un problema, trabajarlo en un grupo diverso e idear el máximo número posible de soluciones para desarrollar una de ellas y testearla. Los resultados de la prueba, si son positivos, crean un objetivo para avanzar hacia la alta fidelidad; alimentando así el ciclo Lean UX / Agile.

Esto como habrás adivinado tambien tiene un coste de tiempo y recursos. Necesitas bloquear a 5-6 personas del equipo una semana entera de 8:00 a 17:00 para que realicen el sprint, lo cual muchas empresas no están dispuestas a asumir. Por ello en el libro ya lo dicen, elige el problema más importante que tengas y un buen moderador que sepa sacar jugo al proceso.

Dual Track Agile

Popularizado por el gurú del product management Marty Cagan, Dual Track Agile intenta realizar un proceso de descubrimiento de producto continuo y entrega para los equipos de Scrum. El equipo maneja 2 backlogs, uno de descubrimiento y otro de entrega, pasando sólo los items validados en el primero al segundo. Bien ejecutado es a donde muchos equipos intentan llegar.

Visto de otra forma, la línea de investigación impulsa un sprint de diseño y la línea Lean UX/Agile potencia la experimentación iterativa, estando desarrollo trabajando en ésta segunda.

Pero, claro, es muy complejo gestionar este trabajo si el equipo está programando, por lo que se suele poner un equipo dedicado en exclusiva a la investigación. Un equipo formado por diseño y desarrollo saca el backlog de entrega, generando iteraciones, mientras que un equipo de investigación investiga los resultados de lo lanzado probando también nuevas ideas.

Esto, desde mi punto de vista, puede funcionar pero se pierde el valor añadido de colaborar y generar entre los miembros del mismo equipo, aunque también depende de cómo de trabajado llegan las user stories al backlog de desarrollo. ¿Llegán con una solución ya definida y acotada que solo se debe implementar? Porque entonces ya volvemos al proceso de cascada y a ser “doers”.

Sería genial si entre los miembros de los dos equipos pudieran irse alternando e ir cambiado de roles, para no alejarse del contacto con el usuario y la generación de inputs. Sino el proceso de comunicación entre investigación y el resto debe ser muy fluido y constante para que no se note ese gap.

Otra cosa es que se investiguen conceptos e ideas generales a alto nivel, cuyo proceso de trabajo pueda ser 1,2,3 meses, y que ya si se decide su implementación, la idealización de la mejor solución entre a formar parte del trabajo del equipo de backlog de entrega formado por los stakeholders necesarios en cada caso: UX, marketing, devs…

En este caso, cada “X” meses entrarán nuevos conocimientos, llenando el backlog con nuevas ideas para la experimentación.

¿Qué opinais? ¿Cómo abordais el proceso de investigación y creación de producto en vuestras empresas?

Este post está inspirado en este articulo escrito por Ian Armstrong: “The Evolution of UX Process Methodology. The UX Process is Confusing, Even to Most Designers” aunque complementándolo desde mi punto de vista. Gracias Ian por compartir tu visión del proceso.

En Torresburriel Estudio desarrollamos las capacidades técnicas de tu equipo en temas de usabilidad, experiencia de usuario y diseño de producto a través de nuestros cursos online y presenciales.