Inicio > Internet > Breve ejercicio de interacción: sección de ayuda de una web

Breve ejercicio de interacción: sección de ayuda de una web

Actualmente me encuentro trabajando en la última fase de una aplicación web y hemos comprobado con usuarios nuevos que existen algunos puntos negros. Trabajar durante meses o años en un proyecto hace que los desarrolladores nos convirtamos en usuarios avanzados de nuestra propia creación, pues conocemos todos los conceptos y funciones de la misma.

Por poner un ejemplo, tras decenas de sesiones de trabajo, los nombres de los elementos de una aplicación que al principio nos sonaban extraños acaban convertidos en conceptos básicos y en palabras clave de nuestras conversaciones. A menudo caemos en el error de dar por sentado que el usuario final va a comprender todo al primer vistazo, como si lo viese a través de nuestros ojos. Acabamos siendo esclavos de nuestro conocimiento.

Sin duda, la mejor aplicación sería aquella que fuese intuitiva al 100%. Muchas veces no se consigue un porcentaje tan alto, por lo que es necesario abrir al usuario una sección de ayuda. En tal caso, debemos poner un especial cuidado al diseñarla. Es frecuente encontrar manuales que tienen un lenguaje más complejo que la propia aplicación o que por su extensión son ignorados por los usuarios.

Nunca debemos olvidar que el actor principal de nuestra aplicación es un ser humano y debemos diseñar para él.

Como siempre digo los mejores ejemplos de experiencia con usuarios los encontramos en la vida real. Pongamos un caso que nos ayudará a trabajar con el asunto que estamos tratando:

Una persona compra un electrodoméstico. ¿Qué porcentaje de compradores se estudian el libro de instrucciones antes de utilizar un aparato? Bajo. El usuario se ve dominado por las ganas de ver funcionando su nueva adquisición y el diseño industrial de la misma sufre su gran prueba de fuego. Si cumple su función sin que tenga que consultar el aburrido libro de instrucciones la satisfacción de la persona se ve exponenciada. En caso contrario ésta se verá obligada a consultar las instrucciones cuando se encuentre ante un problema. Si éstas son claras, la experiencia del usuario no se verá mermada. Sin embargo, si el libro es meramente técnico o enrevesado, es posible que llevemos al comprador a un callejón sin salida y éste sólo pueda echar mano de su paciencia, de un amigo o de la idea de que el dinero invertido en el aparato no se convierta en dinero perdido. Los primeros usos son pues cruciales y aunque toda persona pueda acostumbrarse a los errores de diseño, supondrá la diferencia de un usuario adalid de la marca y el producto y uno resignado.

¿Qué conclusiones sacamos y podemos aplicar?

  1. El usuario es propenso a utilizar una aplicación sin leer ninguna indicación previa que podamos darle. Evitemos entonces las pantallas de inicio con gran cantidad de texto sobre el uso de la herramienta. Si queremos dar indicaciones previas hagámoslo de forma muy visual y breve para que vayan calando en el usuario ciertos conceptos básicos sin que éste deba dedicarle mayor atención.
  2. La experiencia de usuario es inversamente proporcional al número de veces que éste se sienta tan confuso como para recurrir a la ayuda y al tiempo que pase consultándola. Es decir, si no necesita consultar la ayuda tendremos un usuario feliz, que recomendará la herramienta a sus amistades. En cambio, si en sus primeras visitas pasa más tiempo en la ayuda que en la aplicación, es muy probable que un usuario no vuelva a utilizar nuestra aplicación.
  3. El usuario consultará la ayuda sólo cuando se encuentre ante problemas concretos. Debemos facilitarle el acceso desde éstos a la información que los solucione y con el menor número de acciones posible dentro de la ayuda. Por ejemplo, podemos mostrar una ayuda breve (una línea) junto al cursor al posicionarse sobre un enlace o permitir el acceso a casos frecuentes relacionados con una determinada pantalla desde ella misma.
  4. La ayuda debe ser breve, visualmente atractiva y con un lenguaje muy claro para que el usuario no se pierda y vuelva a la aplicación rápidamente. Lo peor que podemos hacer es que se sienta menospreciado o, incluso, estúpido por no tener nuestros conocimientos técnicos o por no saber encontrar respuestas dentro del manual.

Seguro que existen muchos y mejores ejemplos en el mundo real. Éste sólo ha servido como pequeña introducción de cómo plantear unas pautas de diseño iniciales. Cada aplicación es diferente y será necesario realizar varios ejercicios como el anterior para cada una.

Anuncios
  1. 24 noviembre 2009 en 18:33

    Estoy de acuerdo contigo en cómo es la vida real ™, pero cabría preguntarse ¿debería ser así? Muchas veces me he planteado que para utilizar un ordenador debería hacer falta una acreditación (me han venido a la mente las IT Txartelas). ¿O acaso dejamos los cuchillos en manos de nuestros niños sin enseñarles?
    Pues lo mismo con cualquier aplicación. Es imposible que no se requiera una formación para una aplicación medianamente compleja. Esta puede ser de muchos tipos, manual, formación presencial, ayuda interactiva… pero es completamente necesaria y el usuario que no la use, se quedará sin poder sacarle partido a la aplicación.

    Otra cosa es que la gente esté (mal) acostumbrada a que todo tiene que funcionar con un botón (cuantas veces he tenido que sintonizar un TDT este año… y se sintoniza con un botón). Pues puede que si, y puede que no. No se pueden simplificar todos los complejos procesos que requieren algunas aplicaciones web hasta que sean automáticos. ¡Y eso que nos esforzamos!

    Resumiendo: Hacemos mucho por simplificar las aplicaciones, a veces hasta demasiado, pero también creo que podemos exigir un poco de esfuerzo por parte del usuario.

    • 25 noviembre 2009 en 09:10

      Encantado de verte por aquí de nuevo @linsms.

      Para nosotros claro que sería más fácil que un usuario tuviese formación previa pero eso creo que va a ser difícil de asegurar. Yo creo que el usuario es como el cliente de una tienda: siempre tiene la razón. Hasta cierto punto claro 😉

      Muchas veces pensamos que hacemos las aplicaciones simples, pero nada más lejos de la realidad. Eso es lo que vemos nosotros hasta que comprobamos cómo la utiliza un usuario normal.

      No creo que podamos exigir nada al usuario, sobre todo si hablamos de Internet. Como dicen por ahí, en la red tenemos 5 segundos para resultar interesantes al visitante, si no se irá a otro servicio.

      • 25 noviembre 2009 en 09:37

        A veces no hacemos cosas simples porque nos piden hacer cosas complejas. Aún recuerdo el proyecto donde tenía que calcular la resistencia térmica de una ventana en función del marco, tipo de cristal, área… Y no se planificó formación. El resultado: llamadas a tutiplen.

        Otra cosa es cuando te refieres a aplicaciones públicas donde no puedes controlar quien va a acceder. Entonces si, hay que apostar por la simplicidad de procesos incluso aunque sea a cambio de recortar funcionalidades (o hacerlas más difícilemente accesibles).

  2. kNo
    25 noviembre 2009 en 17:12

    Otra opinión de como un usuario tiene que aprender a usar una aplicación (web o no)
    http://www.mundowdg.com/blog/?p=285
    Es largo, la “moraleja” que viene a cuento aquí es lo relacionado con “Pollamboca”.

    • 26 noviembre 2009 en 09:19

      Estoy de acuerdo contigo en que en aplicaciones destinadas al trabajo dentro de una organización (donde se puede controlar quién accede) es posible realizar jornadas de formación. En la web pública no, por eso a veces es necesario proporcionar una ayuda simple que entienda todo el mundo.

      Por otro lado, el post que has enlazado para mí es la típica visión de un informático. ¿Mensaje con datos por defecto que después desaparecen y si Pollamboca no es capaz de recordar mejor que los apunte? Eso para mí es un claro mal diseño. Estoy convencido que se podrían plantear mil soluciones antes que una ventana de información previa. Lo que quiero decir es un ejemplo de cómo el usuario hay muchas veces que no hace las cosas como debería (o como los informáticos esperaban al diseñar), y muchas de esas es por una mala calidad del diseño (como decía Cooper, las aplicaciones no son una serie de funcionalidades a cumplir sino una herramienta para que el usuario las lleve a cabo).

      Te recomiendo que le eches un vistazo a los siguientes libros:

      The Inmates Are Running the Asylum (Alan Cooper)
      Pensar Primero (Daniel Mordecki). Se nota que el autor está muy influenciado por los planteamientos de Cooper.

  1. No trackbacks yet.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: