Introducción



Descargar 394.58 Kb.
Página5/9
Fecha de conversión14.11.2017
Tamaño394.58 Kb.
1   2   3   4   5   6   7   8   9

Tomando decisiones


Tanto la tarea descrita – búsqueda y localización de ítems – como otras posibles en la interacción del usuario, comparten un mismo tipo de acción cognitiva: la toma de decisiones. Por ejemplo, cuando exploramos una serie de ítems, por cada uno debemos tomar una decisión en base a la similitud percibida entre el ítem y nuestra representación mental: ¿hacemos clic o seguimos buscando?

La toma de decisiones es un proceso complejo, influido por multitud de factores, y por tanto complicado de resumir en pocas palabras. De todos modos debemos al menos entender que las personas usamos dos sistemas diferentes en estas decisiones, que denominaremos – con fines didácticos – sistema intuitivo y sistema racional.

El primer mecanismo se caracteriza por ser muy rápido, “sucio”, susceptible a errores y fundamentalmente emocional. Podemos decir que ante la toma de una decisión, se disparan reglas automáticas o heurísticas – adquiridas en base a nuestra experiencia – que nos ofrecen una solución rápida, y nos posibilitan un comportamiento eficiente. No se trata de un sistema dirigido conscientemente, dado que aunque a posteriori podamos intentar razonar nuestra decisión, difícilmente esta reconstrucción se aproxime al proceso realmente acontecido.

El segundo mecanismo, que llamamos racional, es un proceso lineal, lógico, consciente y que requiere esfuerzo y tiempo. Este mecanismo es menos propenso a errores, además de que podemos – frente a un error – modificar el proceso, corrigiendo el resultado.

La función y utilidad que tiene el primer sistema es la de permitirnos economizar nuestro esfuerzo cognitivo, de tal modo que sólo tengamos que emplear el segundo sistema para las decisiones realmente importantes.

El motivo de explicar la diferencia entre ambos sistemas se encuentra en entender que una gran parte de las acciones que llevamos a cabo sobre una interfaz están dirigidas por decisiones tomadas intuitivamente. Esto explica por qué, por ejemplo, ante una ventana de alerta en la que se nos pregunta algo y se nos ofrecen dos posibles respuestas (“si” y “no”), es frecuente que automáticamente hagamos clic en una de ellas sin ni tan siquiera leer o procesar el contenido de la pregunta. O por qué al visitar por primera vez un sitio web, tras un primer "parpadeo" somos capaces de tomar decisiones como cerrar directamente la ventana o, por el contrario, comenzar a explorar el sitio web. El porcentaje de acierto de estas decisiones rápidas estará determinado por nuestra experiencia como usuarios, ya que recordemos que la intuición es un mecanismo que se alimenta de las experiencias previas.


Errar es humano


“Errar es humano… pero echarle la culpa a otro es más humano todavía”
Les Luthiers

Suele ser común en conversaciones sobre usabilidad, escuchar que alguien argumente aquello de “en usabilidad presuponéis que todos los usuarios son idiotas”, frase que no esconde otra cosa que la delegación de la responsabilidad del diseño en los hombros del usuario final. Realmente la premisa de la que se debe partir cuando tratamos de crear productos usables no es que los usuarios sean idiotas, sino que tienen mejores asuntos en los que emplear su esfuerzo cognitivo que en comprender nuestro diseño. Es decir, ante un sitio web lo que el usuario persigue es satisfacer sus objetivos, que siempre están relacionados con el contenido, no con el envoltorio gráfico o interactivo de dicho contenido.

Si la conclusión principal del capítulo sobre percepción visual era que los usuarios no exploran exhaustivamente todos los elementos y contenidos de una interfaz, la conclusión principal de este capítulo es que no todo a lo que atendemos es procesado racional y detenidamente antes de realizar una acción, lo que nos lleva a cometer errores frecuentemente. Como diseñadores no podemos impedir que los usuarios cometan errores, pero sí intentar prevenir que se produzcan, así como ofrecer vías de solución cuando ocurran. A continuación se exponen diferentes vías para disminuir la probabilidad de error del usuario.

Limitar posibilidades


La primera medida para evitar que el usuario cometa errores es limitar sus posibilidades de acción. Por ejemplo, en la figura 2.3 vemos dos posibles formas de solicitar al usuario que introduzca la fecha de caducidad de su tarjeta de crédito. En el primer caso el usuario podría introducir dicha fecha de muy diversas formas (algunas correctas, otras no), mientras que en el segundo la separación de campos limita las posibilidades y por tanto reduce la probabilidad de error.

http://nosolousabilidad.com/manual/img/fig23.gif
Fig. 2.3: Diferentes formas de solicitar una fecha de caducidad

En la figura 2.4 podemos observar las consecuencias de no limitar (a tiempo) las posibilidades de acción.



http://nosolousabilidad.com/manual/img/fig24.gif
Fig. 2.4. Mensaje de error. Fuente: http://www.usabilityinstitute.com/morsels/morsels.htm

Orientar al usuario


Orientar al usuario, ofreciendo ayuda contextual tal y como podemos ver en la figura 2.5, es una medida recomendable para reducir posibles errores. Cuando el exceso de ayuda contextual sobrecargue la interfaz, pueden emplearse ‘tooltips’.

http://nosolousabilidad.com/manual/img/fig25.gif
Fig. 2.5. Sugerencias en la caja de búsqueda. Fuente: 11870.com

Otra forma efectiva de orientar al usuario es mediante sugerencias interactivas, que respondan a la acción del usuario y guíen su recorrido, tal y como se puede observar en la figura 2.6.



http://nosolousabilidad.com/manual/img/fig26.gif
Fig. 2.6: Sugerencias interactivas. Fuente: Trabber.com

Solicitar confirmación


En ocasiones el usuario lleva a cabo una acción que puede tener consecuencias irreversibles y potencialmente perjudiciales, casos en los que resulta de gran importancia solicitar confirmación. De todos modos no debemos olvidar que cuanto más abusemos de este tipo de mensajes en nuestras aplicaciones, menor será su efectividad, pues la atención del usuario se insensibiliza por repetición.

http://nosolousabilidad.com/manual/img/fig27.gif
Fig. 2.7: Mensaje de confirmación de GMail

Advertir al usuario


Este principio está muy relacionado con el anterior. La diferencia estriba en que, aunque su objetivo es igualmente advertir al usuario de posibles consecuencias indeseadas, en este caso no se le solicita confirmación alguna, ya que estos mensajes tienen lugar antes de que el usuario lleve a cabo la acción (advertencia), no como respuesta a su acción (solicitud de confirmación).

Ya que estos mensajes no requieren del usuario la toma de ninguna decisión, su contenido puede pasar desapercibido con mucha más probabilidad, por lo que se recomienda no sólo no abusar de ellos en la aplicación, sino también redactarlos y presentarlos visualmente de forma "inusual", con el fin de forzar la atención del usuario. Como ejemplo podemos observar la captura de la figura 2.8.



http://nosolousabilidad.com/manual/img/fig28.gif
Fig. 2.8: Mensaje de advertencia en Firefox

Evitar la pérdida de información


Otro principio en la prevención de errores es evitar la pérdida de información introducida por el usuario. El ejemplo más típico es el de almacenamiento de correos electrónicos (borradores) mediante técnicas como AJAX, pero existen muchos más contextos posibles, como cuando el usuario está completando un formulario de compra en una web, o dejando un comentario en un blog. Ya que los usuarios se guían por la “ley del mínimo esfuerzo”, es precisamente la pérdida del trabajo realizado la mayor causa de frustración.

Permitir deshacer


Permitir deshacer, una opción tan común en aplicaciones software de escritorio, resulta igualmente necesaria en multitud de contextos web. Un ejemplo clásico es el de la “Papelera” en servicios web de correo electrónico, lo que permite al usuario deshacer su decisión de eliminar un mensaje, pero una vez más podemos encontrar ejemplos en otros tipos de aplicaciones online. Por ejemplo, cuando el usuario se halla completando un proceso de compra divido en diferentes pasos, se le debe permitir volver y rehacer pasos previos. O cuando el usuario introduce una consulta en un buscador, la caja de búsqueda de la página de resultados debe incluir la consulta introducida por el usuario, a fin de permitirle rehacerla o modificarla.

Ofrecer solución automática a los errores


Idealmente las aplicaciones software, incluidos los sitios web, deberían demostrar un comportamiento “inteligente”, solucionando automáticamente errores cometidos por los usuarios. Un ejemplo por todos conocidos es el algoritmo que Google emplea para detectar errores en las consultas del usuario (el famoso “quizás quiso decir:”).

Por supuesto, no se encuentra al alcance de cualquier proyecto ofrecer soluciones algorítmicas como la citada, aunque sí emplear otras de más sencilla implementación, basadas en simples condicionales. Por ejemplo, detectando cuándo el usuario introduce una URL sin “http://” en un campo de texto para tal fin, y solucionando el problema automáticamente en vez de obligarle a solucionar el error manualmente.


Mensajes de error para humanos


Seguro que el lector se habrá encontrado a lo largo de su vida digital con verdaderas obras de arte en forma de mensajes de error, desde luego no pensados para su consumo por simples humanos.

http://nosolousabilidad.com/manual/img/fig29.png
Fig. 2.9. Mensaje de error. Fuente: http://www.exceptontuesdays.com/?p=16

Redactar mensajes para humanos implica exponer breve y claramente el problema, motivos y posibles soluciones, con un vocabulario entendible y sencillo. Es decir, justo lo contrario que el mensaje de la figura 2.9.




Compartir con tus amigos:
1   2   3   4   5   6   7   8   9


La base de datos está protegida por derechos de autor ©composi.info 2017
enviar mensaje

    Página principal