<aside> 💡 Traducido de https://www.nngroup.com/articles/interviewing-users/
</aside>
Lo que los usuarios dicen y lo que hacen son diferentes, como he dicho innumerables veces. Incluso escribí una columna titulada "¿La primera regla de usabilidad? No escuchar a los usuarios" que es tan relevante hoy como lo fue en 2001. (Los mejores métodos de usabilidad son muy estables, por eso aprender metodología válida tiene un ROI fuerte a lo largo de toda la carrera).
Los lectores observadores han señalado que violé mi propia prescripción en mi análisis reciente de los retrasos en los tiempos de respuesta. En ese artículo, reporté una serie de entrevistas que realizamos con usuarios cuando investigábamos el concepto de Marca como experiencia. Entonces, ¿por qué de repente preguntar a la gente lo que piensan en lugar de observar su comportamiento real?
La respuesta es que las entrevistas son en realidad un método apropiado de investigación de usuarios, si solo se usan en los pocos casos para los que generan datos válidos.
Antes de llegar al buen lado de las entrevistas, revisemos sus muchos puntos negativos. (Muchos de los cuales comparten con los grupos focales que se usan en exceso en proyectos de diseño web).
La falla crítica de las entrevistas de usuario es que estás pidiéndoles a las personas que recuerden el uso pasado o especulen sobre el uso futuro de un sistema. Ambos tipos de respuestas son extraordinariamente débiles y a menudo engañosas.
Imagina una línea de tiempo de los comentarios de los usuarios: solo un punto genera datos válidos: el presente, lo que el usuario está haciendo en este momento. Los usuarios que recuerdan mal el pasado o predicen mal el futuro deben ser evitados.
Una de las razones por las que las especificaciones no funcionan es que los usuarios (y la gerencia) no pueden decir si una especificación documenta algo que resolverá su problema una vez construido. Suena bien por escrito, pero hay innumerables estudios de casos de "representantes de usuarios" que aprueban cosas que terminaron siendo grandes fallas.
Por eso, el desarrollo ágil y los métodos de prototipado en papel son valiosos. Cuando los usuarios tienen algo concreto con lo que interactuar, generalmente es obvio cuando estás resolviendo sus problemas de una manera fácil y agradable para trabajar, y igualmente obvio cuando no lo estás haciendo.
La mayoría de las preguntas de diseño específicas no pueden ser respondidas entrevistando a los usuarios. Estas son algunas de las cosas que no aprenderás en una entrevista:
Claro, podrías hacerles a los usuarios cada una de estas preguntas, pero las respuestas no estarán relacionadas con un diseño efectivo para un sitio web real. Los dilemas relacionados con elementos de IU específicos solo se pueden resolver observando a los usuarios interactuar con un diseño que implementa una solución específica, para que puedas ver qué tan bien funciona en uso real. (O puedes implementar múltiples opciones y realizar una prueba comparativa).
De manera similar, no puedes preguntar "¿Usarías la función X (potencial futuro)?" porque los usuarios no pueden predecir algo que no han visto. Incluso no puedes preguntar "¿Qué tan útil es la función Y?" para características que ya existen. De hecho, en muchos estudios, los facilitadores les pidieron a los usuarios que comentaran sobre características específicas que no existían pero que se sembraron en las entrevistas como elementos de distracción; los usuarios proporcionaron muchos comentarios.