¿Comportamiento del usuario que te pilló desprevenido?

Este me sorprendió mucho cuando lo encontré por primera vez:

Los usuarios no leen los cuadros de diálogo de confirmación.

Como desarrollador, siempre he hecho un esfuerzo considerable para asegurarme de que el texto en mis cuadros de diálogo sea claro y preciso. Pero, mis usuarios finales (casi) nunca los leen.

Simplemente hacen clic en "Aceptar" o "Sí" tan rápido como pueden encontrarlo.

Hacer clic, hacer doble clic - En una aplicación basada en web tener que agregar código para manejar el caso en el que el usuario insiste en hacer doble clic en los botones/enlaces y enviar el mismo formulario/consulta dos veces ... lo que causa errores divertidos cuando el usuario intenta eliminar dos veces algo, etc.

Peor aún, es para todos los usuarios que si/cuando encuentran que el sistema es lento o no responde ... hacen clic varias veces en un intento de decirle a la "computadora" que se apure. Mientras tanto, varias solicitudes para ejecutar la "consulta de informe masivo" se ponen en cola haciendo que la aplicación rastree. ;-)

Una pequeña pieza de software de escritorio que escribí busca nombres en una base de datos de archivo (tiene alrededor de 57k registros de nombres).

El formulario tiene un único cuadro de texto con el texto: "buscar por apellido o parte de un apellido". Codifiqué la consulta de la base de datos para que agregara automáticamente un comodín al final. Entonces, en mi caso, si me estuviera buscando, podría haber ingresado "har", y el software realizó una búsqueda "har *" de la base de datos. Todo funcionó bien y no tuve quejas de nadie.

Un día, estaba mirando por encima del hombro de un compañero de trabajo, y la vi ingresar no solo un apellido, sino también un nombre: estaba buscando "apellido, nombre". Por supuesto, lo que eso significaba era que la cadena de búsqueda estaba buscando el apellido de "apellido, nombre *".

Huelga decir que agregué una comprobación adicional para buscar la coma, y ​​ahora puede buscar por nombre exacto o comodín tanto en el nombre como en el apellido (también agregué un enlace "mostrar ejemplos" después del texto de instrucciones).

Lo que siempre me sorprende es lo difícil que es convencer a los usuarios de que el sistema se comporta de cierta manera cuando, a través de la observación, de alguna manera han construido un modelo incorrecto de la operación.

Como ejemplo simple, debido a un error que tuvimos durante un tiempo, una entrada que se realizó en un formulario (este es un software de escritorio) no se reflejó inmediatamente en la vista de lista adecuada. Pero para los usuarios, el cambio en la vista de lista indicaba que el registro se había guardado. Ingresarían datos y cambiarían entre dos registros para hacer que esa entrada apareciera y, por lo tanto, estaban satisfechos de que todo su trabajo se había guardado, no podríamos convencerlos de lo contrario.

Esta es simple, pero pude ver a un usuario haciendo doble clic en una lista de información resumida, luego frustrado, yendo a una pantalla diferente que muestra más detalles sobre una parte particular de ese resumen. Parecía que esperaban el doble clic para navegar directamente allí. Lo hace ahora y él no es el más sabio, para él, siempre funcionó así.

Lo que me sorprendió es la diferencia incluso retrasos muy pequeños (medidos en milisegundos ) responder a una solicitud del usuario puede hacer una diferencia medible en la retención y participación del usuario . Vea la publicación de Google en Speed ​​Matters . Es por eso que herramientas como Yahoo YSlow , Google Page Speed y Webmaster Site Performance son tan valiosas para entender qué páginas son lentas - porque estas páginas lentas probablemente están afectando el compromiso .

Tanto en el diseño basado en pantalla táctil como en diseños web normales, a menudo tenemos botones grandes con un pequeño botón de radio o casilla de verificación dentro (por ejemplo, cuando un usuario tiene que elegir entre 2 o más opciones u ofertas). Cada vez que veo que los sujetos de prueba hacen clic o seleccionan uno de estos botones de gran tamaño, 9 de cada 10 tienden a presionar el pequeño botón de radio o la casilla de verificación. lo que hace que el punto de "hagamos este botón grande para que la gente lo note" casi no tiene sentido. Este comportamiento también se muestra cuando nuestros diseñadores tienen grandes botones 'hacia adelante' con una pequeña flecha dentro del botón. la gente hace clic en la flecha pequeña. Además, he visto a usuarios experimentados y no experimentados hacer esto. Todavía estoy debatiendo en la oficina si esto es un problema o no, y si a veces deberíamos deshacernos de los botones de radio o hacerlos tan grandes como el botón en sí (lo cual es feo e ineficiente, por supuesto)

¿Puedo revertirlo? Es decir, algo que hago mucho que a veces da resultados realmente extraños o peligrosos en algunos sitios web importantes.

Al hacer clic y, a veces, arrastrar en áreas vacías de una página web o aplicación mientras lee algo. A menudo, para asegurarme de haber anulado la selección de los elementos que podría haber seleccionado anteriormente, una "pizarra limpia", por así decirlo. O a veces arrastrando el texto que estoy leyendo actualmente con el mismo propósito. Una cantidad sorprendente de veces esto desencadena algo extraño o previsto en el sitio web, como desviarme de lo que estoy leyendo a otro artículo o anuncio.

Una aplicación llamada Lightwave 3D usa esto para anular la selección de polígonos, vértices, bordes o cualquier otra cosa, y en el Explorador de Windows al hacer clic en un espacio vacío anulará la selección de carpetas y archivos.

En un sitio de redes sociales en el que trabajé una vez, un usuario intentó pegar el código de inserción de un video de Youtube como el título de un álbum de fotos.

No estoy seguro de qué esperaban que sucediera, o por qué decidió dejar el nombre de su álbum como <object width="480" height="385"><param name="movie" value="http://www.youtube.com/v/dQw4w9WgXcQ...

Fui uno de los desarrolladores de algún software cliente/servidor. No son páginas web, pero son similares en concepto a un formulario web.

El formulario en cuestión solicitaba información del usuario (se trataba de personas que se registraban para un evento). La entrada de datos fue realizada por alguien sentado en la computadora. Ellos preguntarían:

• ¿Nombre?
• ¿Empresa?

Cosas como esas. Había dos teclas que podía golpear:

• F10 - para aceptar (transmitir) el formulario al servidor
• Esc - para cancelar la transacción

En cualquier caso, terminó con un formulario en blanco, listo para la siguiente persona en la cola. Sin embargo golpeando F10 realmente grabó los datos en el servidor. Debido a esto tomó un momento (medio segundo más o menos).

Estaba observando a los operadores utilizando este sistema, y ​​me sorprendió ver que algunos de ellos ingresaban todos los detalles y luego pulsaban Esc para cancelar la transacción. Luego, saludaban a la persona, obtenían el siguiente de la cola, ingresaban sus detalles, pulsaban Esc y así sucesivamente.

Les pregunté por qué estaban haciendo eso. Ellos respondieron "es más rápido de esa manera".

Entonces, la lección aprendida. No permita que las personas ingresen datos y luego cancele la transacción sin algún tipo de advertencia. Además, asegúrese de que entiendan completamente la capacitación que reciben.