Puebas de Usabilidad

Una de las estrategias clave para hacer que las aplicaciones descentralizadas tengan éxito comercial es crear una experiencia de usuario intuitiva para diferentes audiencias.

Foto por Robin Worrall

En æternity, probamos todas las interfaces de usuario, que diseñamos contra las expectativas de los usuarios con diferentes niveles de experiencia con la tecnología blockchain.

¡La experiencia que tu, el usuario, tienes es de la mayor importancia en nuestro proceso de diseño!

Proceso de Prueba de Usabilidad

¿Cómo nos aseguramos de crear la experiencia de usuario más intuitiva? Nuestro enfoque consiste en identificar todas las áreas donde los usuarios pueden estar luchando contra la complejidad de las aplicaciones que se ejecutan en la blockchain y mejorar su experiencia. Hacemos esto siguiendo el proceso descrito a continuación.

Trabajo de Preparacion

Primero identificamos las vías de usuario que nos gustaría probar/mejorar. Luego preparamos un script con estas vías. En el script tenemos que articular los caminos como historias de usuario. Después de incluir todas las historias de usuario, que nos gustaría probar en el script, las usamos para crear un prototipo.

Seleccionando Testers

Dependiendo de qué æpp y qué funcionalidad de un æpp estamos probando, buscamos las audiencias adecuadas con las que nos gustaría probar. Como se mencionó anteriormente, queremos cubrir audiencias de todos los niveles de experiencia y diferentes características demográficas. Por ejemplo, al probar nuestra aplicación web Token Migration, nos interesaron los usuarios que son:

  • æternity token holders
  • extendido por todo el mundo
  • no usuarios super blockchain avanzados, ya que queremos asegurarnos de que la interfaz de migración sea intuitiva para todos los niveles de experiencia con la tecnología blockchain.

En general, siempre tenemos la opción de realizar sesiones de prueba de usuario en persona o virtualmente. En el ejemplo anterior, tenía más sentido para los testers de origen de todo el mundo y realizar las pruebas virtualmente.

Durante las Sesiones

Las sesiones se realizan siempre en tiempo real con grabación de pantalla y de audio. Durante cada sesión, un anfitrión de æternity le pide al tester que revise las historias de los usuarios en el script, que recopila comentarios sobre la fricción o la experiencia fluida de estas vías. Además, recopilamos comentarios generales y de forma libre, que los usuarios generalmente están dispuestos a proporcionar.

Captura de pantalla de una grabación de una sesión de prueba de usabilidad de nuestro prototipo click-through de la aplicación web Token Migration.

Analizando la Entrada

Después de realizar todas las sesiones, extraemos los comentarios recibidos durante las sesiones.

Priorizamos todos los puntos de entrada según la gravedad de las barreras con las que se encuentran los usuarios.

Por ejemplo, si una historia de usuario incluye al usuario que navega desde una sección de æpp, digamos el administrador de cuentas en Base æpp, a otra, el navegador de æpps, y por alguna razón no se dan cuenta de dónde tocar para abrir el navegador æpps, consideramos esto como una barrera bastante severa, ya que les impide completar la tarea descrita por la historia del usuario (en este caso, cambiar del administrador de cuentas a la funcionalidad del navegador æpps).

Una vez que tenemos una lista de elementos en los que nos gustaría trabajar, los convertimos en tareas concretas. Hacemos esto volviendo a la historia del usuario que dice que “como usuario me gustaría poder hacer X por razones Y, Z” e identificar la tarea de encontrar una solución diferente a la tarea que el usuario quiere completar.

Tipos de Ciclos

Elegimos diferentes tipos de iteración dependiendo de la severidad de las barreras/fricciones que los usuarios encuentran durante las sesiones de prueba. Por ejemplo, si un usuario no puede completar una ruta fundamental y necesitamos proponer una nueva solución a una historia de nuestro script, tiene sentido crear un nuevo prototipo y obtener su retroalimentación (flecha #2: prototipo => retroalimentación, en el diagrama de arriba).

Sin embargo, si no estamos cambiando fundamentalmente nuestro enfoque, digamos que estamos rediseñando un ícono, cuya función algunos usuarios pueden entender fácilmente, mientras que otros necesitan un poco más de esfuerzo para comprenderlo, podemos decidir simplemente solicitar retroalimentación interna sobre el rediseño y probar el ícono con los usuarios más adelante, cuando tengamos más barreras fundamentales para probar (flecha #1: diseño => retroalimentación). En algunos casos, solo necesitamos hacer pequeños refinamientos (por ejemplo, cambios de texto, agregar aclaraciones). Si este es el caso, podemos ajustar nuestros diseños y luego ir directamente a implementar los diseños y prepararlos para una nueva versión (flecha #3: diseño => construir => versión).

Iterar, Iterar, Iterar

Trabajamos utilizando un proceso altamente iterativo, en el centro del cual está el usuario: es fundamental para nosotros que los usuarios experimenten æpps intuitivos y sin interrupciones, que les permitan completar las tareas en las que están interesados. Según la æpp y la funcionalidad de æpp que estamos trabajando, podríamos pasar por múltiples iteraciones/repeticiones en los bucles ilustrados arriba hasta que alcancemos una versión del diseño y la compilación, que nos gustaría lanzar. Además, al final de cada sprint, presentamos las actualizaciones de diseño que hicimos a nuestras æpps y recibimos comentarios sobre ellas internamente.

El Valor de las Pruebas de Usuario

Las observaciones que ustedes, los usuarios, han proporcionado han sido invaluables.

Nos preocupa profundamente proporcionar una experiencia de usuario sin fricción y los conocimientos que hemos recopilado durante nuestras sesiones de pruebas de usabilidad han influido enormemente en nuestras decisiones de diseño de experiencia de usuario.

Conclusión

Esperamos que esta información sobre nuestro proceso de prueba de usabilidad haya brindado una oportunidad para que los lectores comprendan la importancia y el funcionamiento interno de nuestros ciclos de diseño y prueba. Si tienes alguna pregunta o comentario relacionado con esto, no dudes en preguntar en la categoría de æpps en el Foro.


¿Interesado en æternity? Síguenos:

GitHub | Forum | Reddit | Telegram | Twitter | Facebook | Mail


Leave a Reply

Your email address will not be published. Required fields are marked *