Jeff Atwood: "Repito: No escuchen a sus usuarios!"

Menuda coincidencia, después del post sobre Usuarios, leí en Coding Horror un post titulado "I repeat: Do not listen to your users" ("Repito: no escuchen a sus usuarios"). Jeff Atwood es el autor, y como la mayoría de sus posts, no tiene desperdicio. Este en particular fue escrito a raíz de Listening to Users ("escuchando a los usuarios") de Paul Buchheit. Tiene un enfoque más amplio y general que lo que yo escribí, pero sigue con el tema de la relación con el usuario.

Cito algunos fragmentos para agregar más al tema:

"Escuchar a los usuarios es algo tramposo. Los usuarios generalmente no saben lo que quieren, y aunque supieran, la comunicación probablemente se entrevere en algún momento entre ellos y ustedes. De ninguna manera deberías ignorar a los susuarios sin embargo. La mayoría de las personas se irá silenciosamente para siempre si tu software o sitio web no satisface sus necesidades. Los usuarios a los que le importa lo suficiente para darte retroalimentación merecen tu atención y respeto. Están esencialmente encargándose de diseñar tu producto. Si no escuchas atentamente y respondes educadamente a todo el feedback de los clientes, te estás preparando a tí mismo eventuales fallas.

Es mala educación no escuchar a tus usuarios. Entonces cómo reconciliamos esto con la primera regla de usabilidad-- No escuchamos a los usuarios?

Para descubrir qué diseño funciona mejor, observa a los usuarios mientras intentar realizar tareas con la interfaz de usuario. Éste método es tan simple que muchas personas lo pasan por alto, asumiendo que debe haber más en el testing de la usabilidad. Se concentra en las reglas básicas de usabilidad.
-Ver a la gente hacer
-No creer lo que la gente dice que hace.
-Definitivamente no creer lo que la gente predice que pueden hacer en el futuro.

Creo que Paul acertó, pero es fácil de errar. La frase relevante en el post de Paul es que vemos qué cosas trabajan, lo que implica medida y correlación. No hay necesidad de mirar directamente a los usuarios (aunque nunca hace daño) cuando tienes logs detallados mostrando lo que hicieron actualmente. Junta feedback del usuario, luego correlacionalo con la información de lo que esos usuarios están haciendo.

No solo implementes pedidos de funcionalidades de "representantes de usuarios" o "analistas de negocios". La forma más común de errarle en la usabilidad es escuchar lo que los usuarios dicen en vez de realmente mirar lo que hacen. Las especificaciones de requerimientos siempre están mal. Debes prototipar los requerimientos rápidamente y mostrarle a los usuarios algo concreto para encontrar lo que realmente necesitan.

Es cuestionable actuar únicamente en el feedback de usuario. No importa con cuánta buena intención, estás adivinando. ¿Porqué adivinar cuando puedes tomar acciones basado en información fría y persistente? Actuar en base al feedback del usuario y métricas detalladas de uso para tu aplicación o sitio web -- ese es el estándar dorado.

El post continua comentando ejemplos en las compañías de videojuegos Valve y Bungee, con ejemplos de datos reales y cambios aplicados a los productos finales en base a dicha información.
Finaliza con:

"Asegurate que tu aplicación o sitio web esté capturando la actividad del usuario en una manera útil y significante. El feedback del usuario es importante. No me malinterpreten. Pero nunca trabajen únicamente basado en el feedback del usuario. Siempre tengan algún tipo de información de la actividad del usuario para corroborar y apoyar el valioso feedback que están obteniendo del usuario. Ignorar el feedback de usuario puede estar aprontándote a un eventual fracaso, pero actuar ciegamente para cada requerimiento del usuario ciertamente es un fracaso."