Mi app no tiene pulso

Posteado por
24Mar

¡Doctor, doctor, mi app no tiene pulso!

Ésta podría ser la frase que definiera la sensación al finalizar el modulo 3, donde hemos trabajado el Diseño centrado en el usuario en la plataforma Synctur.

Como en muchas ocasiones al principio los conocimientos nuevos que vamos adquiriendo quedan un poco en el aire, sin encajarlos del todo en su contexto. Y cuando los ponemos en la práctica es cuando empiezan a cobrar sentido, fuerza y validez. Apunto el concepto de validez, porqué al inicio del módulo no fui el único sorprendido al ver que los principios de Jakob Nielsen, que son el referente en diseño centrado en usuarios, tenían fecha de finales del siglo XX. Pero resulta chocante descubrir que después de tantos años y en un entorno tan evolutivo, unos conceptos genéricos para todos los sistemas encajen tan bien para los distintos proyectos del master de user experience de La Salle.

En una de las lecturas a los blogs que nos recomendaba el profesor de este módulo, Jordi Golobart, encontré una frase que me resulto tranquilizadora a medida que trabajábamos las metodologías del módulo, decía que el análisis heurístico es un sistema para detectar los problemas de los sistemas, no las virtudes, y que en consecuencia solo se descubrían fallos, y que no nos debía abordar una sensación de destrucción y derribo del proyecto analizado. A la vez, J. Golobart también nos aconsejaba ser sensibles, delicados y amables en la redacción de nuestros hallazgos de los problemas y debilidades que encontráramos en el proyecto Synctur (este punto seguro que necesita más años de experiencia), que tras la segunda pasada de los principios de J. Nielsen parecían ser bastante graves. Digo parecían porque tras el test de guerrilla, algunas hipótesis que valorábamos como de alta frecuencia, de gran impacto y de alta persistencia, resultaron no ser tan graves para los usuarios entrevistados. Otras hipótesis en cambio, sí fueron confirmadas.

En relación al test de guerrilla resultó fácil generar el guión después de definir los casos principales, y lo que resulto ser un reto, fue el ruido de la cafetería que no dejaba escuchar a la perfección al usuario, y la velocidad a la que transcurren los test, que hace muy necesario la participación de dos miembros del equipo. Uno para anotar y ver el comportamiento del usuario y otro para conducir el test y facilitar al usuario poder resolverlo. Hubiera estado bien documentar con unas fotos los dos usuarios en el momento del test para incorporar a este escrito, pero como he mencionado, todo sucede muy rápido, así que para el próximo artículo del blog estaremos atentos a documentar las fases del proyecto.

Albert Cid
MUX – Máster en User eXperience
Edición 2016-2017
La Salle Campus BCN – Universitat Ramon LLull
Archivado en:

Comentar

Tu dirección e-mail no se publicará.

Iniciar sesión