4 Actividades UX Para Disolver Controversias de Desarrollo

Uno de los momentos claves en el trabajo de un UX Designer es presentar sus hallazgos de investigación y comunicar las soluciones propuestas. De su éxito depende que no se generen malos entendidos respecto a cómo debe funcionar el producto de software a desarrollar. Pero, ¿por qué esa habilidad es crucial y cómo afecta al resto del equipo? ¿Cómo podemos unificar esfuerzos y evitar confusiones?

¿Qué está sucediendo?

Comunmente Developers, QA Testers y Product Managers precisan un punto central de discusión del cual se desprendan las tareas individuales. Presumiblemente todos ellos trabajan bajo el mismo objetivo: crear el mejor producto y la experiencia más placentera para el usuario. Es fácil ver que esa pieza central puede ser el prototipo a desarrollar. El prototipo debe convertirse en el punto de partida para alcanzar un acuerdo común. De no hacerlo así se corre el riesgo de crear un monstruo sin pies ni cabeza.

Cuando los desarrolladores no conocen las razones detrás de las decisiones de diseño a menudo son reacios a implementar los cambios y solución planteada. Si el UX Designer falla en comunicar efectivamente su trabajo, enfrentará objeciones como “eso tardará varios meses”, “eso no es posible”. Si este es tu caso hay una manera sencilla de lograr el efecto opuesto.

La solución

Para pasar del “no se puede” al “sí, creo que esto traerá valor” simplemente debemos involucrar a todo el equipo desde el inicio. Desde la generación temprana de prototipos hasta las pruebas de usabilidad. De esta manera entenderán por sí mismos que las decisiones de diseño son soluciones a problemas reales de gente real.

Ver a los usuarios frustrarse con un software pobremente desarrollado y diseñado es la mejor manera de subir a todos al mismo barco. El problema adquiere rostro y es validado por observación propia. Presenciar cómo el producto en el que has trabajado arduamente pierde su valor por una característica mal implementada es un golpe psicológico contundente. Después de presenciarlo el equipo sentirá el impulso de corregirlo de inmediato.

1. Crear el prototipo

Un prototipo efectivo puede variar en sus niveles de fidelidad al producto real. Desde un dibujo hecho a mano, wireframes hechos en software de prototipado rápido, hasta prototipos de alta fidelidad ricos en color e interacciones.

Es altamente recomendado que el prototipo esté fundamentado en investigación previa sobre hábitos y expectativas de los usuarios. Para esto existen varias metodologías de UX que podemos aplicar. Hay que recordar que hacer investigación es salir a la defensa de los usuarios [1].

El nivel de fidelidad de tu prototipo depende de la etapa de desarrollo en la que se encuentre el producto. Aquí una guía rápida:

Es una buena práctica incluir a todo el equipo desde el primer día en que comiences a prototipar. Así nuestra solución irá creciendo siendo validada desde todas las perspectivas: la de negocios, la técnica y la de los usuarios.

Con prototipo en mano, el equipo ahora está listo para verlo en acción. Someterlo a pruebas tempranas nos permitirá:

• detectar errores críticos de conceptualización,
• corregir inmediatamente antes de gastar horas de producción,
• aprender más sobre el problema a resolver.

Al tener contacto directo con los usuarios notaremos que nuestro entendimiento del problema irá modificándose. Esto es absolutamente normal, se le conoce como la paradoja del problema/solución [2].

2. Reclutar usuarios

Ha llegado el momento esperado. Tienes un prototipo listo y estás ansioso por probarlo. Pero, ¿con quién y cómo?

Algunas recomendaciones para reclutar usuarios:

• Definir un perfil deseado en caso que el producto no tenga usuarios activos todavía.
• Ofrecer siempre una recompensa por el uso de tiempo que nos concederán.
• Brindar opciones de horarios previamente definidos, que ellos elijan.
• Hacerles saber que es una invitación abierta sujeta a quien responda primero.
• Usualmente de 5 a 8 usuarios por prototipo es suficiente [3].
• Pedir ayuda al departamento que ya tiene contacto con ellos, como ventas o soporte.

3. Probar prototipo

Estas son algunas recomendaciones básicas:

Preparar un guión. Hay ciertas consideraciones que los usuarios deben saber antes de iniciar la prueba. Por ejemplo: que hable en voz alta todo lo que piensa, que no recibirá ayuda durante la prueba, que no se le está evaluando a él/ella, que todas las preguntas serán resueltas eventualmente. En http://swgu.ru/qz hay una plantilla que puede ser útil. Es indispensable que el guión puntualice las tareas que el usuario ejecutará. Esta es la parte esencial de las pruebas de usabilidad: observar las maneras en que los usuarios se las arreglan sin ayuda para completar una tarea específica.

Grabar la sesión. Estamos en el entendido que los integrantes del equipo nos acompañarán como observadores durante las sesiones. Sin embargo es buena idea grabar en video la acción, o al menos la acción en pantalla. Esto servirá en el futuro cuando se necesite o alguien más quiera referenciar o recordar ciertos aspectos clave de la interacción.

Sesiones remotas. No descartar la posibilidad de probar el prototipo con usuarios no presenciales. Podemos hacer una videollamada y grabar la acción de la pantalla. Algunas herramientas como InVision nos permiten ver claramente los clics que realiza el usuario.

Aprovecha la oportunidad. Tener a un usuario que no tiene idea de todas las discusiones acaloradas en las juntas de equipo es invaluable. Es nuestra oportunidad de salir de cualquier duda y desechar supuestos. Los usuarios son despiadados y nunca quieren esforzarse de más. Es solo una interfase, ¿por qué habrían de meditar más de lo necesario en encontrar una opción? Simplemente guardemos silencio y observemos la ejecución de la tarea solicitada.

Prepararse para lo inesperado. Ley de Murphy. Todo aquello que pueda salir mal, saldrá mal. Se caerá la red, fallará la herramienta de prototipado, cancelará un usuario, nos daremos cuenta que el prototipo no contempla una parte esencial, etcétera. Todo puede pasar y hay que estar listo. Conservar la calma y ser honesto con lo que está sucediendo. No pasa nada.

4. Analizar resultados

La pregunta del millón es: ¿qué tan detallado debe ser un reporte de usabilidad? La respuesta es dependiendo de a quién va dirigido:

• Si es para nuestro equipo, un prototipo anotado, una lista de user stories, y clips de video es suficiente.
• Si es para top level executives debemos incluir la metodología utilizada, los descubrimientos, y los errores a corregir. En un formato muy puntual, no más de dos cuartillas.
• Si es para nuestro propio registro de documentación, puede ser tan extenso como el tiempo nos lo permita.

En todos los casos anteriores entre más visual sea la información es mejor. Nadie tiene tiempo de leer exhaustivos reportes. Al final es útil ser organizado, llegará el día en que cuestionen las razones detrás de una decisión de producto y es mejor estar preparado.

Ningún reporte de usabilidad es suficiente si solamente se queda en documento. Hay que transformarlo en un prototipo corregido y mejorado con las oportunidades encontradas. El reporte de usabilidad es siempre el inicio de la siguiente iteración.

Conclusiones

El prototipo es la pieza estratégica ideal de discusión del equipo de desarrollo. El prototipo es “tangible” porque es un artefacto concreto con ideas estructuradas. También representa la solución más aproximada en términos técnicos, de limitaciones de negocio, y de deseabilidad por parte de los usuarios, a problemas reales de los cuales se tiene evidencia.

La presencia del equipo de desarrollo como observadores durante las pruebas de usabilidad es una estrategia sabia para sintonizar los esfuerzos de todos hacia un mismo objetivo y agilizar el proceso mismo de desarrollo.

La aprobación de las soluciones de diseño propuestas no solamente depende de la efectividad del UX Designer para comunicarlas, sino también del entendimiento que todo el equipo tenga sobre el problema a resolver.

En Nearsoft tenemos una filosofía central. La mejor manera de hacer software es comenzar lento y avanzar rápido hacia el final [4]. Esto nos evita deshacer, rehacer, borrar y desechar código y esfuerzos.

Referencias

1. M. León. “A La Defensa De Los Usuarios: Siete Técnicas UX Para Cambiar El Mundo” SG #47. http://swgu.ru/qk
2. T. Wendt. “Design for Dasein: Understanding the Design of Experiences”. CreateSpace, 2015. http://swgu.ru/qw
3. J. Nielsen. “How Many Test Users in a Usability Study?” NN Group, 2012.
4. http://swgu.ru/qx
5. J. González. “Three Reasons Your Project Is Late and What You Can Do About It”. http://swgu.ru/qy