Mensajes del sistema: ¿cuándo usar cuál?

Los mensajes constituyen un recurso excelente para comunicar información al usuario; sin embargo, cuando se abusa de ellos o se utilizan de forma inadecuada logran justamente el efecto contrario: el usuario pulsa el â??Introâ? sin prestarles ninguna atención. Conocer las características de cada tipo de mensaje y comprender la utilidad que proporciona al usuario facilita la elección del tipo y formato de mensaje adecuados para cada situación.

Tipo de realimentación en el tiempo

La realimentación o feedbak constituye un elemento imprescindible para una correcta interacción persona-ordenador y consiste en conseguir que, para cada acción del usuario, el sistema informe de su resultado de forma inmediata y evidente. Sin realimentación sería imposible utilizar un sistema, ya que el usuario no sabría en qué estado se encuentra ni tampoco si está respondiendo o no a sus acciones. Para entender hasta qué punto es indispensable la realimentación basta con imaginar cuán complicado resultaría dibujar con un lápiz que no dejara trazo en el papel.

Aunque no toda la realimentación que proporciona un sistema se sustenta únicamente en los mensajes, sí es cierto que todos los mensajes constituyen una forma de realimentación. Por este motivo, resulta muy conveniente analizar el fenómeno de la realimentación a fin de formarse un criterio correcto sobre cuándo hay que emitir un mensaje.

Lon Barfield en su libro The user interface. Concepts & Design, clasifica la realimentación que proporciona un sistema interactivo según su relación con el tiempo, de la siguiente forma:

A. Realimentación de futuro

Es aquella realimentación que el sistema proporciona antes de que se lleve a cabo la interacción. Informa sobre qué sucederá si se realiza una acción determinada. Por ejemplo, el literal del botón â??Imprimirâ? está proporcionando realimentación de futuro ya que indica que al apretar el botón se iniciará el proceso de impresión.

B. Realimentación de presente

Es la realimentación sobre la interacción que se está realizando en ese preciso momento. Comunica qué está pasando. La sensación de que las teclas se hunden bajo los dedos cuando utilizamos el teclado es un ejemplo de este tipo de realimentación.

C. Realimentación de pasado

Es la realimentación que se proporciona una vez que la interacción ya ha terminado. Notifica qué ha ocurrido. Por ejemplo, al editar un documento el texto que acabamos de teclear y que se muestra en la pantalla del editor de textos constituye una muestra de realimentación de pasado.

¿Cuándo usar un mensaje?

La primera pregunta que debemos formularnos es en qué situaciones del sistema conviene comunicar un mensaje al usuario y en cuáles no. Esta decisión no es trivial sino que, por el contrario, se revela de suma importancia, ya que debe mantenerse la consistencia para cualquier interacción del usuario con el sistema. Si cuando el usuario elimina un documento el sistema le solicita confirmación con un mensaje, el usuario esperará encontrar esta confirmación cada vez que quiera eliminar un objeto. De hecho, la norma a seguir sobre cuándo debe generarse un mensaje tiene que definirse dentro de la guía de estilo que se aplique en el desarrollo del sistema.

A continuación, se exponen algunos consejos que conviene tomar en consideración a la hora de determinar cuándo conviene usar un mensaje:

• Cuantos menos mensajes, mejor Un mensaje supone una interrupción para el usuario; por ello, conviene reducir el uso de mensajes al mínimo imprescindible: sólo hay que generar un mensaje cuando es preciso comunicar algo realmente relevante para el usuario y no se dispone de otro método mejor para informarle.
• Es preferible usar eventos que no interrumpan al usuario. Siempre que sea posible y resulte suficientemente comprensible para el usuario, es mejor vehicular la realimentación con un evento diferente a un mensaje. Por ejemplo, se indica que un texto está seleccionado mostrándolo en vídeo inverso.
• No usar un mensaje para comunicar un resultado esperado. No suele ser necesario informar al usuario del resultado de una acción cuando el final ha sido el deseado y se ha alcanzado inmediatamente después de iniciar la acción. En estos casos, hay otros eventos que comunican sobradamente esta información, como, por ejemplo, la aparición de un icono que representa un documento que se acaba de crear.
• Usar un mensaje para comunicar un resultado inesperado. Cuando una acción no ha tenido el resultado esperado es del todo inexcusable comunicárselo al usuario asegurándose de que éste va a estar informado de lo ocurrido. En estos casos, resulta especialmente indicado usar un mensaje modal, pues obliga al usuario a confirmar su recepción.
• Usar un mensaje cuando haya transcurrido mucho tiempo desde el inicio de la acción hasta la obtención del resultado Tanto si el resultado de la acción es el esperado como si no lo es, siempre que éste se obtenga mucho después de haber iniciado la acción, conviene comunicar su finalización con un mensaje. Esta recomendación resulta especialmente indicada para todas las acciones que se procesan en segundo plano, pero también para las que se ejecuten de forma prolongada en primer plano dado que el usuario fácilmente habrá dejado de prestar atención a la ejecución del proceso.
• Usar un mensaje cuando el sistema necesite recabar información del usuario. Cuando el sistema necesita que el usuario le proporcione una información para seguir con un proceso; por ejemplo, cuando es preciso que el usuario tome una decisión, es plenamente justificable que el sistema le interrumpa mostrándole un mensaje.

¿Qué tipo de mensaje usar?

Una vez tomada la decisión de usar un mensaje, la siguiente cuestión que debe decidirse es qué tipo de mensaje resultará más adecuado utilizar. También en este aspecto interesa conservar la consistencia entre todos los mensajes de la aplicación y, por lo tanto, debe definirse su uso en la guía de estilo correspondiente. La respuesta es simple: el tipo de mensaje que será más adecuado utilizar dependerá tanto la relevancia que la situación tenga para el usuario como de los recursos de que disponga el sistema en cada situación.

A continuación, se describe para qué es adecuado cada tipo de mensaje a la vez que se enumeran algunos de sus inconvenientes y se indican los usos incorrectos más habituales.

1. Mensaje Informativo

Constituye un caso típico de realimentación sobre una acción realizada en el pasado. Se utiliza para comunicar algún hecho o estado del sistema que no produce ningún efecto indeseable para el usuario. Entre otros casos, sirve, por ejemplo, para confirmarle que la acción que había iniciado ha finalizado correctamente.

Formato

En general, es un claro candidato a aparecer en la barra de estado en lugar de abrir un cuadro de mensaje modal. No obstante, para comunicar situaciones, como, por ejemplo, que ha finalizado una ejecución en segundo plano, es mejor usar un cuadro de diálogo modal, ya que el usuario difícilmente estará atento a la finalización del proceso.

Ejemplo de mensaje informativo en la barra de estado

Adecuado para

Informar de una situación que no reviste ninguna gravedad para el usuario.

Inconvenientes

Puede pasar inadvertido y, por ese mismo motivo, no debe aplicarse en caso de una situación que interesa que el usuario no pase por alto.

Errores de uso

– Utilizarlo para comunicar una circunstancia importante para el usuario.

– Nunca debe usarse en un cuadro de mensaje que desaparezca automáticamente por sí solo al cabo de cierto tiempo. En ese caso, el usuario percibirá la aparición del mensaje pero, al no haber tenido tiempo de leerlo, se quedará con la duda de saber de qué le informaba y de si la situación descrita era grave o no.

– En general, es mejor que no interrumpa al usuario exigiéndole algún tipo de acción de respuesta.

– Abusar de los mensajes informativos acaba molestando al usuario, especialmente cuando le requieren alguna acción de respuesta. Antes de decidirse a utilizarlos, conviene analizar si se dispone de otros recursos para comunicar la misma información. Por ejemplo, al crear un objeto, se puede mostrar un icono representando el objeto creado. La aparición del icono y su permanencia comunican que el objeto ha sido creado y, por tanto, ya no es necesario generar un mensaje que indique: â??Se ha creado el objeto Xâ?.

– Si se muestra en la barra de estado, el texto del mensaje debe ser lo suficientemente corto como para que se muestre en su totalidad o, en caso de que ello no sea posible, debe situar al principio del mensaje el contenido que aporte más significado a fin de asegurar su visibilidad.

Ejemplos de mensaje informativo incorrecto

1. El usuario inicia la acción de borrar una entrada y el sistema le muestra un mensaje de decisión. Esto es correcto.

2. El usuario borra la entrada y el sistema le muestra un mensaje informativo al que debe responder con un OK. Esto no es correcto: la entrada ya se ha borrado y, además, al cabo de cierto tiempo el mensaje desaparece por sí solo. También conviene remarcar el mal uso de los signos de admiración, que inducen a la alarma sin ningún motivo.

2. Mensaje de Progreso

Constituye un ejemplo paradigmático de realimentación sobre una acción que se está ejecutando en el presente. Se utiliza para informar del avance de un proceso que requiere cierto tiempo. Resulta adecuado, por ejemplo, para comunicar una descarga de archivos.

Formato

Se presenta en un cuadro de mensaje modal que, por lo general, desaparece automáticamente en cuanto finaliza el proceso. Según el nivel de detalle con que se conozca o se pueda medir el grado de avance del proceso, el sistema dispone de diversas maneras de mostrar la progresión:

– Con una simple barra que se va rellenando para indicar el porcentaje de proceso ya ejecutado así como el que falta por ejecutar.

РIndicando el n̼mero de ocurrencias ya procesadas del total.

– Enunciando el nombre del paso que se está ejecutando en cada momento del proceso.

– Cuando no se puede comunicar con fidelidad el grado de avance del proceso, conviene sustituir el mensaje de progreso por una animación que se limite a informar de que el proceso está en ejecución. Ese es el caso del traslado de un documento entre dos carpetas en el proceso de copia de archivos entre directorios.

Ejemplos de mensaje progreso: diferentes modos de indicar la progresión

Adecuado para

Comunicar el grado de progresión de un proceso que precisa de cierto tiempo de ejecución.

Inconvenientes

– Dado que este tipo de mensajes no suele exigir acción de confirmación del usuario, cuando un proceso se ejecuta con rapidez puede ocurrir que el usuario no tenga tiempo suficiente para advertir su aparición.

– Cuando no se muestra una barra de progreso o el número de ocurrencias procesadas del total a procesar, el usuario no sabe cuánto falta para que acabe el proceso.

– Cuando el proceso contiene pasos de larga duración, si el mensaje no muestra ningún avance el usuario puede confundirse, puesto que desconoce si el proceso está parado y, por tanto, le conviene cancelarlo, o bien si el proceso está avanzando aunque con mucha lentitud. En estos casos, conviene proporcionar la máxima información posible en el mensaje de progreso. Por ejemplo, es mucha mejor opción indicar el nombre y el número del paso dentro del proceso que mostrar solamente una barra de progreso.

Errores de uso

– Emplearlo en un proceso tan breve que el usuario no tenga tiempo de leer el mensaje.

– Exceptuando los casos en los que el usuario tiene que tomar una decisión al final del proceso, el mensaje debe desaparecer automáticamente en cuanto finaliza su ejecución.

– Debe indicar fielmente el grado de avance en el proceso. A veces, en los mensajes que usan una barra de progreso, ésta se llena antes de que finalice el proceso, la barra se vacía y comienza a llenarse otra vez. Este ciclo se repite hasta que el proceso acaba. En ese caso, el usuario se siente engañado por el sistema y nunca sabe cuándo va a acabar el proceso.

– Siempre que tenga sentido, es interesante permitir que el usuario pueda finalizar la ejecución del proceso en cualquier momento. Esta acción suele implementarse por medio de un botón â??Cancelarâ? incluido en el cuadro del mensaje. Si el usuario detiene el proceso cuando este aún no ha finalizado, hay que estudiar si tiene utilidad mantener los resultados de los pasos del proceso que se hayan completado hasta ese momento. Por ejemplo, en la copia de los archivos de un directorio, si el usuario cancela la copia puede tener sentido mantener los archivos copiados hasta la interrupción del proceso.

– Según cuál sea la duración del proceso, es mejor usar otros eventos para mostrar el grado de avance. De acuerdo con el artículo de Jakob Nielsen, Response Times: The Three Important Limits, puede establecerse la siguiente norma de actuación según cuál sea el tiempo de respuesta:

• Menos de 1 segundo: no hace falta generar ningún evento de realimentación.
• Entre 1 y 10 segundos: no hace falta mostrar un cuadro de mensaje, basta con la animación del cursor.
• Más de 10 segundos: usar un cuadro de mensaje. si el proceso es muy largo, conviene considerar la ejecución del proceso en segundo plano, liberando la estación de trabajo para que el usuario pueda realizar otras tareas. En ese caso, se recomienda usar dos mensajes informativos con sus respectivos cuadros modales: el primero, comunicando al usuario que el sistema empieza a ejecutar el proceso en segundo plano y que, cuando éste finalice, le avisará con otro mensaje. El segundo mensaje comunicará la finalización del proceso así como el resultado final.

3. Mensaje de Aviso

Informa sobre alguna contingencia que se ha producido en el pasado o que puede producirse en el futuro, que el usuario no puede evitar que se produzca, y que va a provocar que el resultado final sea diferente del esperado. Habitualmente, la acción iniciada por el usuario no ha finalizado.

Formato

Suele aparecer en un cuadro de diálogo modal ya que normalmente interesa asegurarse de que el usuario no pasa por alto el mensaje y confirma, con una acción explícita, que se ha percatado de la existencia del problema.

Adecuado para

Notificar estados del sistema que inciden sobre la acción iniciada por el usuario, de forma que el resultado final diferirá, en mayor o menor grado, del resultado esperado por el usuario.

Inconvenientes

– Tiene que redactarse correctamente. Esto es, debe indicar claramente 1) qué va a pasar, 2) cual es la causa del aviso y 3) si el usuario puede hacer algo para lograr su objetivo. Si no se comunica esta información, el usuario no va a comprender por qué el resultado de su acción difiere del esperado ni cómo debe actuar para obtener lo que quiere.

Errores de uso

– Utilizarlo para comunicar una situación que no reviste ninguna importancia para el usuario.

– Mostrarlo al final del proceso cuando las circunstancias que provocan el aviso ya existían al principio del proceso. En tales casos, es preciso considerar si sería más correcto usar un mensaje de decisión para darle el control al usuario y que éste pueda optar por cancelar el proceso o continuar con él.

Ejemplo de mensaje de aviso incorrecto: el producto estaba bloqueado antes de empezar a editarlo

4. Mensaje de Error

Comunica un estado que el sistema no tiene previsto tratar.

Formato

Se muestra en un cuadro de diálogo modal para asegurarse de que el usuario percibe la existencia del problema.

Adecuado para

Advertir cualquier estado de error. Parece una obviedad, pero no lo es. Entre los programadores está muy extendida la práctica de tratar sólo los códigos de retorno â??esperablesâ?, como, por ejemplo, al acceder a una base de datos. Sin embargo, esta práctica constituye una auténtica bomba de relojería, porque cuando el sistema devuelve un código â??no esperadoâ?, se trata como si no se hubiera producido ningún error.

En estos casos, lo más adecuado es tratar cada uno de los códigos de retorno â??esperadosâ? con un mensaje específico y los códigos inesperados con un mismo mensaje genérico. Dicho mensaje genérico debe usarse sólo para los casos realmente no esperables y debe incluir toda la información necesaria para que el administrador pueda hallar el origen del error, como, por ejemplo, â??El acceso a la base de datos X ha devuelto imprevistamente un código Y. Comuníquelo al administrador de su sistemaâ?.

Inconvenientes

– Es imprescindible que se redacte adecuadamente. Esto es, que indique qué ha pasado, cuál es la causa del error y qué puede hacer el usuario para alcanzar su objetivo. Si no se comunica esta información, el usuario no va a saber cómo actuar.

Errores de uso

– Dejar de comunicar alguna de las tres informaciones básicas de todo mensaje de error: qué ha ocurrido, la causa del error y qué puede hacer el usuario para superar el problema.

– Dejar que, en caso de error inesperado, sea el propio sistema quien muestre un mensaje estándar. Un mensaje tienen que ser lo más específico posible.

– Mostrarlo al final del proceso cuando las causas del error ya existían al principio del mismo, atentando de este modo contra el principio de guiar en lugar de sólo controlar.

Ejemplo de mensaje de error incorrecto: parece indicar que el nombre repetido es â??Nueva carpetaâ?cuando en realidad es â??Carpeta Aâ?(en un directorio con más carpetas difícilmente se vería que ya hay una â??Carpeta Aâ?)

5. Mensaje de Decisión

Comunica alguna contingencia que altera el resultado final esperado por el usuario y le solicita que indique si quiere o no proseguir con la acción inicial. De hecho, es un mensaje de aviso que deja el control de la situación en manos del usuario, de modo que éste puede decidir continuar o bien cancelar la acción.

Formato

Debe aparecer en un cuadro de diálogo modal dado que el sistema no puede reanudar el proceso hasta que el usuario responda al mensaje.

Adecuado para

Permitir que el usuario decida si quiere proseguir o no con una acción ya iniciada. Los motivos por los que puede convenir proporcionar esta opción son muy diversos: desde comunicar que, por cualquier circunstancia, el resultado de la acción va a ser diferente al esperado hasta advertir que el proceso va a durar mucho.

Por ejemplo, en un caso como el de una ecuación de búsqueda demasiado genérica, cuyo proceso va a ser largo, se puede advertir al usuario, por si prefiere reformular la ecuación para obtener resultados con mayor rapidez.

Inconvenientes

El mensaje tiene que redactarse de forma excelente. Esto es, debe indicar claramente sobre qué debe decidir el usuario y qué va a pasar para cada una de las respuestas posibles. En ese caso, el resultado final depende de la decisión del usuario, es decir, el sistema le cede el control y, con él, toda la responsabilidad; por este motivo, deviene imprescindible que el usuario disponga de toda la información necesaria para poder decidir.

Errores de uso

– No proporcionar toda la información necesaria para que el usuario pueda decidir. Es uno de los casos donde la completitud y exactitud del mensaje son más importantes que la brevedad.

– Utilizarlo para una acción que ya ha finalizado o cuyo resultado no va a cambiar sea cual sea la decisión del usuario.

– Utilizarlo para una acción que se puede deshacer fácilmente. Por ejemplo, para enviar un archivo a la â??Papeleraâ? no es necesaria confirmación, el usuario siempre podrá sacarlo de allí.

– A veces, el mensaje de decisión no se muestra como la ventana activa de modo que el usuario no lo percibe inmediatamente. Sin embargo, los mensajes de decisión son los que más justificadamente pueden interrumpir al usuario, especialmente los que se originan por acciones iniciadas explícitamente por el usuario, ya que, mientras no se le informe de lo contrario, piensa que el sistema está procesando su petición.

– Falta de consistencia al mostrar las opciones, como, por ejemplo, no mostrar las opciones â??Sí/Noâ? en el mismo orden en todos los mensajes de decisión de la aplicación.

Ejemplos de mensaje de decisión incorrecto

A. Mensaje de decisión que muestra el Calendario de Outlook cuando el usuario inicia la acción de eliminar una ocurrencia de una cita periódica. Es correcto, ya que la acción por defecto es la menos perjudicial en caso que el usuario pulse el â??Introâ? sin prestar atención.

B. Mensaje de decisión que muestra el Calendario del Pocket PC cuando el usuario inicia la acción de eliminar una ocurrencia de una cita periódica. Es incorrecto porque: 1) la pregunta se hace sobre la opción más perjudicial y 2) es inconsistente con el mensaje anterior (no hay que olvidar que una PDA suele estar sincronizada con el Outlook de un PC). Además, este mensaje resulta mucho más difícil de comprender y necesita explicar cómo cancelar el mensaje.

C. Mensaje de decisión que muestra el Calendario del Pocket PC cuando el usuario inicia la acción de editar una ocurrencia de una cita periódica. Es incorrecto porque: 1) es inconsistente com el mensaje anterior (B) pero consistente con el (A). Tampoco puede decirse que su redacción sea clara

6. Mensaje de Acción

Se trata de un tipo de mensaje que puede considerarse como una combinación de un mensaje de error y de un mensaje de decisión, dado que pone a disposición del usuario algunas acciones para que éste pueda corregir la contingencia y alcanzar su objetivo.

Formato

Se muestra en un cuadro de diálogo modal que incluye los botones correspondientes a las acciones disponibles.

Adecuado para

Cualquier caso donde esté generándose un mensaje de error. El hecho de proporcionar determinadas acciones para superar el problema lo convierten en un recurso mucho más recomendable que un simple mensaje de error, con el que el usuario tiene que â??buscarse la vidaâ?.

Inconvenientes

Su componente de decisión exige una excelente redacción del mensaje: además de indicar qué ha pasado, la causa del error y qué puede hacer el usuario para alcanzar su objetivo, tiene que quedar muy claro qué efecto tiene cada una de las acciones disponibles.

Errores de uso

– Que la misma causa del error impida la ejecución de alguna de las acciones que se muestran dentro del propio mensaje.

– Falta de consistencia tanto en las acciones que se ofrecen como en su colocación dentro del mensaje.

Resumen de recomendaciones

â?¢ No molestar al usuario: si el usuario percibe el mensaje como una molestia, significa que sobra.

� Evitar mensajes que desaparecen automáticamente; pueden confundir al usuario.

� No redactar mensajes genéricos para aplicarlos en diferentes situaciones; es mejor usar un mensaje específico para cada caso.

� Redactar mensajes breves pero que contengan toda la información necesaria para el usuario.

� Siempre que sea posible, usar mensajes de decisión en lugar de mensajes de aviso, y mensajes de acción en lugar de mensajes de error. Con ello se le otorga un mayor control al usuario, lo que respeta uno de los principios básicos de la usabilidad.

Conclusión

A pesar de la complejidad que parecer rodear el uso y diseño de los mensajes del sistema, todo se reduce a una idea muy simple: asegurar que el usuario conoce en todo momento el estado del sistema. Ciertamente, pensar cuándo debe usarse un mensaje, de qué tipo y cómo redactarlo demanda un esfuerzo apreciable, pero pienso que hay que considerarlo como una inversión valorando el beneficio que supone para los usuarios.