4

Prototipado en Agile UX y la lucha con los HIPPOs

Mi papel en este momento es de “Agile UX Designer“, trabajo en estrecha (estrechísima) colaboración con equipos de desarrollo. Hago la investigación de usuarios recopilando información de soporte de tickets de Uservoice, de Twitter, de emails de usuarios y de pruebas de usabilidad de guerrilla y creemos en el binomio despliege-feddback.

El “método” JIT (just in time) es a veces un proceso muy común en el que me veo envuelto, la verdad es que es fascinante sentir la vorágine del desarrollo de features.

Con el equipo de desarrollo el prototipado en papel es mi arma principal, acompañada de iteraciones continuas ya que las ideas se generan de forma mucho más fluidas, no suelo hacer test de usuarios en papel, a pesar que es una buena práctica la complejidad de la propia herramienta en la que trabajo lo haría un tanto difícil así que lo dejo para cuando hablo con los desarrolladores, que, por cierto también participan. Es una sensación de completo bienestar trabajar codo a codo con ellos al mismo nivel de opinión y dejando de lado el eterno “issue” diseño/desarrollo, el papel es el rey aquí. Existen apps como POP para darle la interacción que desees si quieres usar de todas formar algo de tecnología, pero trata de dejarlo de lado, papel y lápiz es mejor.

Por otro lado he descubierto que con el equipo de MKT funciona de maravillas pedirles siempre moodboards, de esta forma los contenidos que generan y me envían cuando vienen acompañados de ellos me simplifica el trabajo a realizar ya que me dicen del estilo que se busca y el tono en el que se quiere proyectar el mensaje. Luego de ello uso InvisionApp para pulir los visuales que se generan, eso sí, dejando en claro que el equipo de diseño es el que diseña, porque cuando el HIPPO se apodera del proceso, las cosas no funcionan nada bien.

Los wireframes de baja fidelidad y mockups los utilizo en su mayoría cuando tengo que interactuar con el equipo de Londres y cuando entran en escena el CEO y CTO, obviamente el prototipo en papel no es lo más indicado, así que para ello me basta usar Pencil (mucha agencias o headhunters hablan sobre usas Axure o similares, están bien, pero no los necesitas obligatoriamente) e InvisionApp, esta última es genial para comentar y decidir en tiempo real sobre los layouts que estén en discusión y más aún cuando se trata de diseños visuales (los mockups estos que a la gente de Marketing o al mismo CEO les gusta más ya que les cuesta hacerse la idea con un wireframe o un sketch…), así mismo, sirve mucho para hacer test con usuarios en modo guerrilla (tanto wireframes como mockups)… recuerda aplicar el concepto CRAP en todos tus visuales ya que no se trata de demostrar lo bueno que eres diseñando si no lo centrado que estás en la tareas de usuario cuando diseñas.

Cuando llego al prototipado en HTML y CSS en Sublime (luego de las iteraciones continuas con el equipo de desarrollo, el equipo de diseño y vencer los HIPPPOs) de las funcionalidades, éstos deben estar lo suficientemente pulidos para que los desarrolladores front-end comiencen su particular “cirugía” y le den a esas etiquetas de maqueta la lógica que les corresponde, yo no utilizo javascript para maquetar a pesar que incomprensiblemente muchas empresas lo piden, claro que sé “leer” javascript pero no necesito desarrollarlo porque para ello cuento con un desarrollador dedicado a hacer ese trabajo, si que “desarrollo” lógica, pero refiero que sea diseño de interacción en papel que de código. Cuando el HTML ha sido “traducido” al lenguaje de desarrollo (sea el que sea, AngularJS, PHP, ASP, etc…) las comunicaciones con el equipo de desarrollo se hace casi exclusivamente usando el control de versiones GIT y comentando lo que se necesite en Pivotal Tracker y chats de voz o texto. Salvo que haya que volver a iterar se regresa al papel y lápiz.

Cuando tenemos listas las “betas” es cuando se hacen los test de usabilidad con los betatesters y utilizando herramientas como UXline. Cuidado aquí que no es que se hagan los test una vez se despliegan las betas, estos test como se lee antes se producen durante el proceso, en mi caso de forma de guerrilla y muchos A/B ya que en el entorno startup es lo que toca y para qué quejarme, funciona muy bien este método.

Vengo trabajando en UX desde hace un tiempo. Debo decir que a veces ha sido un trabajo duro, no es fácil convencer a los directores generales y jefes de equipo para aplicar los métodos UX, a veces ese propósito falla… los HIPPOs en ciertos casos son insalvables…pero no todo el tiempo, he salido victorioso muchas veces y tengo que decir que los resultados fueron fantásticos, cabe decir que cuando no, pues ahí están los HIPPOs preguntándose en qué momento falló la idea si el concepto era bueno… claro, el concepto puede ser bueno hasta que enferma de “featuritis” y deja de centrarse en las tareas del usuario y se enfoca a las tareas que el CEO hace…

Como dice Michael Lai, yo no soy un mago UX, no puedo responder cuáles son las necesidades de los usuarios o lo que los usuarios quieren y cuando la gente me pregunta ello (sólo porque yo soy el tipo UX), únicamente puedo decir lo que pienso que los usuarios piensan, y eso es por eso tenemos que probar y ver y escuchar a los usuarios.

Debo decir que en los últimos tiempos he trabajado haciendo Agile UX en startups, y llevar una gran cantidad de iteraciones con equipos de desarrollo, de diseño y equipos de marketing, no es fácil, pero creo que estoy haciendo un buen trabajo. Siempre son reticentes al inicio pero luego, cuando realmente quieren ver las ventajas se consiguen buenos resultados, cuando no, pues va todo al garete. En un mundo maravilloso si dan el tiempo, los recursos y la voluntad de hacer un buen trabajo UX, entonces cualquiera puede convertirse en el buscado unicornio, esto lo saben los UXers que trabajan en empresas consolidadas y con amplísimos recursos a disposición, usualmente terminan convirtiéndose en Gurupollas (término derivado el españolísmo “gilipollas”), estos mismos colegas sufren mucho cuando “vuelven a las trincheras”.

Dos ejemplos de qué pasa cuando no dejas trabajar al UX que tienes en el equipo:

Una vez trabajé en una aplicación de “gestión integral del conocimiento” o como ellos se llamaban: information and knowledge integral management, o algo así, vamos todo un trabalenguas, el concepto de que el proyecto era bueno, de hecho una idea muy prometedora y llegué a creer en ello, pero algunas personas en esta startup pensaron que la UX era ” algo que podemos agregar más tarde , la “featuritis” en esa empresa se volvió algo peligroso y en cierto punto se dejó de lado el centrarse en las tareas de usuario…, llegó a ser inviable responder preguntas sobre dónde poner un botón o de qué color tenía que ser una zona o cómo se podría mostrar mejor la información si no se daba acceso a ningún usuario a la herramienta y las pocas personas que gestionaban las limitadísimas betas desplegadas no querían entender ni aplicar métodos que de otra forma hubiesen mejorado ostensiblemente la herramienta. No puedes pretender hacer un producto basado en lo que tu CEO usa, tu CTO propone y el CBO proyecta (HIPPO, ¿lo recuerdan?)… no puedes hacer un producto sin usuarios, sin que lo prueben y trasteen con ello y te devuelvan información valiosa, es decir, ni esconder a los usuarios que utilizan la herramienta a tu UX ni esconder, que es peor, la herramienta a los usuarios, la UX puede ser una clave para el éxito cuando las personas en cargo tienen la voluntad de darle la importancia que se merece, como consejo en todo caso, asegúrate que si te unes a un equipo como UXer ten presente que si contratan a una consultora externa para hacer tu trabajo, es un bueno momento de decir adiós, ya que una vez más puedes convertirte en el photoshop de alguien.

Trabajé en otra startup basada en recomendaciones o: social recommendation network focused on discovering and sharing products/services…(pff qué difícil es explicar en lenguaje sencillo lo que “sabe hacer bien” una app), el proyecto aún permanece en fase beta, y creo que seguirá así una vez más porque, otra vez, un producto no se puede desarrollar basado en la opinion de tres personas o cuatro en meets de inversores y fundadores, se necesita la opinión de usuarios que retuerzan y expriman la herramienta, sin ello sólo vas a tener un MVP eternamente… y si llevas a tu equipo un UXer para que haga diseño gráfico según el HIPPO de turno pues ahorra dinero y llévate un becario para que haga sus pinitos.

Te digo esto porque quiero que sepas que tengo experiencia en una variedad de proyectos con diferente grado de compromiso con respecto a la UX, no soy un gurú de la UX que lo sabe todo, sino un tipo que hace UX y que sabe lo que es trabajar desde las trincheras y si te interesa comentar tus experiencias y vivencias, no dudes en comentar!

Fatal error: Uncaught Exception: 12: REST API is deprecated for versions v2.1 and higher (12) thrown in /web/htdocs/www.uxinperu.com/home/wp-content/plugins/seo-facebook-comments/facebook/base_facebook.php on line 1273