Mensajes de error en Windows 7

Nota

Esta guía de diseño se creó para Windows 7 y no se ha actualizado para las versiones más recientes de Windows. Gran parte de las instrucciones todavía se aplican en principio, pero la presentación y los ejemplos no reflejan nuestra guía de diseño actual.

Los mensajes de error de Windows 7 alertan a los usuarios de problemas que ya se han producido. Por el contrario, los mensajes de advertencia alertan a los usuarios de condiciones que podrían causar problemas en el futuro. Los mensajes de error se pueden presentar mediante cuadros de diálogo modales, mensajes en contexto, notificaciones o globos.

screen shot of error message: can't rename

Mensaje de error modal típico.

Los mensajes de error efectivos informan a los usuarios de que se ha producido un problema, explican por qué se ha producido y proporcionan una solución para que los usuarios puedan solucionar el problema. Los usuarios deben realizar una acción o cambiar su comportamiento como resultado de un mensaje de error.

Los mensajes de error útiles y bien escritos son fundamentales para una experiencia de usuario de calidad. Los mensajes de error mal escritos dan lugar a una baja satisfacción del producto y son una causa principal de los costos de soporte técnico evitables. Los mensajes de error innecesarios interrumpen el flujo de los usuarios.

Nota: Las directrices relacionadas con los cuadros de diálogo, los mensajes de advertencia, las confirmaciones, losiconos estándar, las notificaciones y el diseño se presentan en artículos independientes.

¿Es esta la interfaz de usuario correcta?

Para decidirte, intenta responder a estas preguntas:

  • ¿La interfaz de usuario (UI) presenta un problema que ya se ha producido? Si no es así, el mensaje no es un error. Si el usuario que está alertando de una condición que podría causar un problema en el futuro, use un mensaje de advertencia.
  • ¿Se puede evitar el problema sin causar confusión? Si es así, evite el problema en su lugar. Por ejemplo, use controles restringidos a valores válidos en lugar de usar controles sin restricciones que pueden requerir mensajes de error. Además, deshabilitar los controles al hacer clic produciría un error, siempre y cuando sea obvio por qué el control está deshabilitado.
  • ¿Se puede corregir el problema automáticamente? Si es así, controle el problema y suprima el mensaje de error.
  • ¿Es probable que los usuarios realicen una acción o cambien su comportamiento como resultado del mensaje? Si no es así, la condición no justifica la interrupción del usuario, por lo que es mejor suprimir el error.
  • ¿Es relevante el problema cuando los usuarios usan activamente otros programas? Si es así, considere la posibilidad de mostrar el problema mediante un icono de área de notificación.
  • ¿El problema no está relacionado con la actividad del usuario actual, no requiere una acción inmediata del usuario y puede ignorarlo libremente? Si es así, use una notificación de error de acción en su lugar.
  • ¿El problema se relaciona con el estado de una tarea en segundo plano dentro de una ventana principal? Si es así, considere la posibilidad de mostrar el problema mediante una barra de estado.
  • ¿Son los principales usuarios de TI los usuarios de destino? Si es así, considere la posibilidad de usar un mecanismo de comentarios alternativo, como entradas de archivo de registro o alertas de correo electrónico. Los profesionales de TI prefieren encarecidamente los archivos de registro para información no crítica.

Conceptos de diseño

Características de mensajes de error deficientes

No debería sorprender que haya muchos mensajes de error molestos, no útiles y mal escritos. Y dado que los mensajes de error a menudo se presentan mediante diálogos modales, interrumpen la actividad actual del usuario y exigen que se confirmen antes de permitir que el usuario continúe.

Parte del problema es que hay tantas maneras de hacerlo mal. Tenga en cuenta estos ejemplos de la sala de mensajes de error de vergüenza:

Mensajes de error innecesarios

Incorrecto:

screen shot of error message: application failed

Este ejemplo de Windows XP podría ser el peor mensaje de error de la historia. Indica que un programa no se pudo iniciar porque Windows está en proceso de apagado. No hay nada que el usuario pueda hacer sobre esto o incluso quiere hacer sobre esto (el usuario eligió apagar Windows, después de todo). Y al mostrar este mensaje de error, Windows impide que se apague.

El problema: El propio mensaje de error es el problema. Aparte de descartar el mensaje de error, no hay nada que hacer para los usuarios.

Causa principal: Notificar todos los casos de error, independientemente de los objetivos o el punto de vista de los usuarios.

Alternativa recomendada: No notifique errores que los usuarios no le importan.

Mensajes de error "Correcto"

Incorrecto:

screen shot of error message: removal failure

Este mensaje de error fue el resultado de que el usuario no se reiniciara Windows inmediatamente después de la eliminación del programa. La eliminación del programa se realizó correctamente desde el punto de vista del usuario.

El problema: No hay ningún error desde el punto de vista del usuario. Aparte de descartar el mensaje de error, no hay nada que hacer para los usuarios.

Causa principal: La tarea se completó correctamente desde el punto de vista del usuario, pero no se pudo realizar desde el punto de vista del programa de desinstalación.

Alternativa recomendada: No notifique errores para las condiciones que los usuarios consideran aceptables.

Mensajes de error completamente inútiles

Incorrecto:

screen shot of error message: unknown error

Los usuarios aprenden que se produjo un error, pero no tienen idea de cuál era el error o qué hacer al respecto. ¡Y no, no está bien!

El problema: El mensaje de error no proporciona un problema específico y no hay nada que puedan hacer los usuarios sobre él.

Causa principal: Lo más probable es que el programa tenga un control de errores deficiente.

Alternativa recomendada: Diseñe un buen control de errores en el programa.

Mensajes de error incomprensibles

Incorrecto:

screen shot of error message: backup not complete

En este ejemplo, la instrucción del problema está clara, pero la explicación complementaria es absolutamente desacertada.

El problema: La instrucción o solución del problema es incomprensible.

Causa principal: Explicar el problema desde el punto de vista del código en lugar del del usuario.

Alternativa recomendada: Escriba texto de mensaje de error que los usuarios de destino puedan comprender fácilmente. Proporcione soluciones que los usuarios puedan realizar realmente. El diseño de la experiencia de mensaje de error del programa no tiene programadores que redacte mensajes de error en el lugar.

Mensajes de error que sobrecommunin

Incorrecto:

screen shot of extremely verbose message

En este ejemplo, el mensaje de error intenta explicar cada paso de solución de problemas.

El problema: Demasiada información.

Causa principal: Proporcionar demasiados detalles o intentar explicar un proceso de solución de problemas complicado dentro de un mensaje de error.

Alternativa recomendada: Evite detalles innecesarios. Además, evite solucionar problemas. Si es necesario un solucionador de problemas, céntrese en las soluciones más probables y explique el resto mediante la vinculación al tema adecuado en la Ayuda.

Mensajes de error innecesariamente duros

Incorrecto:

screen shot of message: can't find object

La incapacidad del programa para encontrar un objeto apenas suena catastrófico. Y suponiendo que es catastrófico, ¿por qué está bien la respuesta?

El problema: El tono del programa es innecesariamente duro o dramático.

Causa principal: El problema se debe a un error que parece catastrófico desde el punto de vista del programa.

Alternativa recomendada: Elija el idioma cuidadosamente en función del punto de vista del usuario.

Mensajes de error que culpan a los usuarios

Incorrecto:

screen shot of message: illegal character

¿Por qué hacer que los usuarios se sientan como un criminal?

El problema: El mensaje de error se formula de una manera que acusa al usuario de cometer un error.

Causa principal: Expresiones que no distinguen que se centran en el comportamiento del usuario en lugar del problema.

Alternativa recomendada: Céntrese en el problema, no en la acción del usuario que provocó el problema, usando la voz pasiva según sea necesario.

Mensajes de error tontos

Incorrecto:

screen shot of message: error in error report

En este ejemplo, la instrucción del problema es bastante irónico y no se proporciona ninguna solución.

El problema: Instrucciones de mensaje de error que son tontos o no sequitors.

Causa principal: Crear mensajes de error sin prestar atención a su contexto.

Alternativa recomendada: Tener los mensajes de error diseñados y revisados por un escritor. Tenga en cuenta el contexto y el estado de mente del usuario al revisar los errores.

Mensajes de error del programador

Incorrecto:

screen shot of message: access violation address

En este ejemplo, el mensaje de error indica que hay un error en el programa. Este mensaje de error solo tiene significado para el programador.

El problema: Los mensajes destinados a ayudar a los desarrolladores del programa a encontrar errores se dejan en la versión de lanzamiento del programa. Estos mensajes de error no tienen significado ni valor para los usuarios.

Causa principal: Los programadores que usan la interfaz de usuario normal para hacer mensajes a sí mismos.

Alternativa recomendada: Los desarrolladores deben compilar condicionalmente todos estos mensajes para que se quiten automáticamente de la versión de lanzamiento de un producto. No pierda tiempo intentando cometer errores como este comprensible para los usuarios, ya que su única audiencia es los programadores.

Mensajes de error mal presentados

Incorrecto:

screen shot of message: unexpected failure

Este ejemplo tiene muchos errores comunes de presentación.

El problema: Obtención de todos los detalles incorrectos en la presentación del mensaje de error.

Causa principal: No conocer ni aplicar las directrices del mensaje de error. No se usan escritores y editores para crear y revisar los mensajes de error.

La naturaleza del control de errores es tal que muchos de estos errores son muy fáciles de cometer. Es preocupante darse cuenta de que la mayoría de los mensajes de error podrían ser candidatos para el Salón de la Vergüenza.

Características de los mensajes de error correctos

A diferencia de los ejemplos incorrectos anteriores, los mensajes de error correctos tienen:

  • Un problema. Indica que se produjo un problema.
  • Una causa. Explica por qué se produjo el problema.
  • Una solución. Proporciona una solución para que los usuarios puedan solucionar el problema.

Además, los mensajes de error correctos se presentan de una manera que es:

  • Relevante. El mensaje presenta un problema que los usuarios se preocupan.
  • Procesable. Los usuarios deben realizar una acción o cambiar su comportamiento como resultado del mensaje.
  • Centrado en el usuario. El mensaje describe el problema en términos de acciones o objetivos de usuario de destino, no en términos de lo que el código no está satisfecho.
  • Breve. El mensaje es lo más corto posible, pero no más corto.
  • Borrar. El mensaje usa un lenguaje sin formato para que los usuarios de destino puedan comprender fácilmente el problema y la solución.
  • Específico. En el mensaje se describe el problema mediante un idioma específico, que proporciona nombres, ubicaciones y valores específicos de los objetos implicados.
  • Cortés. Los usuarios no deben culparse ni hacerse sentir estúpidos.
  • Poco frecuente. Se muestra con poca frecuencia. Los mensajes de error mostrados con frecuencia son un signo de diseño incorrecto.

Al diseñar la experiencia de control de errores para tener estas características, puede mantener los mensajes de error del programa fuera de la sala de mensajes de error de la vergüenza.

Evitar mensajes de error innecesarios

A menudo, el mejor mensaje de error no es ningún mensaje de error. Muchos errores se pueden evitar mediante un mejor diseño y a menudo hay mejores alternativas a los mensajes de error. Normalmente es mejor evitar un error que notificar uno.

Los mensajes de error más obvios que se deben evitar son aquellos que no son accionables. Si es probable que los usuarios descarten el mensaje sin hacer o cambiar nada, omita el mensaje de error.

Algunos mensajes de error se pueden eliminar porque no son problemas desde el punto de vista del usuario. Por ejemplo, supongamos que el usuario intentó eliminar un archivo que ya está en proceso de eliminación. Aunque esto podría ser un caso inesperado desde el punto de vista del código, los usuarios no consideran este error porque se logra su resultado deseado.

Incorrecto:

screen shot of message: can't delete file

Este mensaje de error debe eliminarse porque la acción se realizó correctamente desde el punto de vista del usuario.

En otro ejemplo, supongamos que el usuario cancela explícitamente una tarea. Para el punto de vista del usuario, la siguiente condición no es un error.

Incorrecto:

screen shot of message: can't complete backup

Este mensaje de error también debe eliminarse porque la acción se realizó correctamente desde el punto de vista del usuario.

A veces, los mensajes de error se pueden eliminar centrándose en los objetivos de los usuarios en lugar de en la tecnología. Al hacerlo, reconsidere lo que realmente es un error. ¿Es el problema con los objetivos del usuario o con la capacidad del programa de satisfacerlos? Si la acción del usuario tiene sentido en el mundo real, también debería tener sentido en el software.

Por ejemplo, supongamos que dentro de un programa de comercio electrónico un usuario intenta encontrar un producto mediante la búsqueda, pero la consulta de búsqueda literal no tiene coincidencias y el producto deseado está sin existencias. Técnicamente, se trata de un error, pero en lugar de proporcionar un mensaje de error, el programa podría:

  • Continúe buscando productos que coincidan más estrechamente con la consulta.
  • Si la búsqueda tiene errores obvios, se recomienda automáticamente una consulta corregida.
  • Controle automáticamente problemas comunes, como errores ortográficos, ortografías alternativas y casos de pluralización y verbos no coincidentes.
  • Indique cuándo estará el producto en existencias.

Siempre que la solicitud del usuario sea razonable, un programa de comercio electrónico bien diseñado debe devolver resultados razonables no errores.

Otra excelente manera de evitar mensajes de error es evitar problemas en primer lugar. Para evitar errores, haga lo siguiente:

  • Uso de controles restringidos. Use controles restringidos a valores válidos. Los controles como listas, controles deslizantes, casillas, botones de radio y selectores de fecha y hora están restringidos a valores válidos, mientras que los cuadros de texto a menudo no son y pueden requerir mensajes de error. Sin embargo, puede restringir los cuadros de texto para aceptar solo determinados caracteres y aceptar un número máximo de caracteres.
  • Uso de interacciones restringidas. Para las operaciones de arrastrar, permita a los usuarios colocar solo en destinos válidos.
  • Usar controles deshabilitados y elementos de menú. Deshabilite controles y elementos de menú cuando los usuarios puedan deducir fácilmente por qué el control o elemento de menú está deshabilitado.
  • Proporcionar buenos valores predeterminados. Es menos probable que los usuarios realicen errores de entrada si pueden aceptar los valores predeterminados. Incluso si los usuarios deciden cambiar el valor, el valor predeterminado permite a los usuarios conocer el formato de entrada esperado.
  • Hacer que las cosas funcionen. Es menos probable que los usuarios cometan errores si las tareas son innecesarias o se realizan automáticamente para ellos. O bien, si los usuarios cometen pequeños errores pero su intención es clara, el problema se corrige automáticamente. Por ejemplo, puede corregir automáticamente problemas de formato menores.

Proporcionar los mensajes de error necesarios

A veces, realmente necesita proporcionar un mensaje de error. Los usuarios cometen errores, redes y dispositivos dejan de funcionar, los objetos no se pueden encontrar ni modificar, las tareas no se pueden completar y los programas tienen errores. Idealmente, estos problemas se producirían con menos frecuencia, por ejemplo, podemos diseñar nuestro software para evitar muchos tipos de errores de usuario, pero no es realista evitar todos estos problemas. Y cuando se produce uno de estos problemas, un mensaje de error útil devuelve rápidamente a los usuarios en sus pies.

Una creencia común es que los mensajes de error son la peor experiencia del usuario y deben evitarse a todos los costos, pero es más preciso decir que la confusión del usuario es la peor experiencia y debe evitarse a todos los costos. A veces, ese costo es un mensaje de error útil.

Considere la posibilidad de deshabilitar los controles. La mayoría de las veces, es obvio por qué se deshabilita un control, por lo que deshabilitar el control es una excelente manera de evitar un mensaje de error. Sin embargo, ¿qué ocurre si el motivo por el que un control está deshabilitado no es obvio? El usuario no puede continuar y no hay comentarios para determinar el problema. Ahora el usuario está bloqueado y tiene que deducir el problema o obtener soporte técnico. En tales casos, es mucho mejor dejar el control habilitado y proporcionar un mensaje de error útil en su lugar.

Incorrecto:

screen shot of message: where save backup?

¿Por qué el botón Siguiente está deshabilitado aquí? Es mejor dejarla habilitada y evitar confusiones del usuario al proporcionar un mensaje de error útil.

Si no está seguro de si debe proporcionar un mensaje de error, empiece por redactar el mensaje de error que puede proporcionar. Si es probable que los usuarios realicen una acción o cambien su comportamiento como resultado, proporcione el mensaje de error. Por el contrario, si es probable que los usuarios descarten el mensaje sin hacer o cambiar nada, omita el mensaje de error.

Diseño para un buen control de errores

Aunque la creación de texto de mensaje de error correcto puede ser difícil, a veces es imposible sin una buena compatibilidad con el control de errores del programa. Tenga en cuenta este mensaje de error:

Incorrecto:

screen shot of message: unknown error

Lo más probable es que el problema sea desconocido porque el soporte de control de errores del programa carece de soporte técnico.

Aunque es posible que se trate de un mensaje de error muy mal escrito, es más probable que refleje la falta de un buen control de errores por parte del código subyacente, no hay información específica conocida sobre el problema.

Para crear mensajes de error específicos, accionables y centrados en el usuario, el código de control de errores del programa debe proporcionar información específica de error de alto nivel:

  • Cada problema debe tener asignado un código de error único.
  • Si un problema tiene varias causas, el programa debe determinar la causa específica siempre que sea posible.
  • Si el problema tiene parámetros, se deben mantener los parámetros.
  • Los problemas de bajo nivel deben controlarse en un nivel suficientemente alto para que el mensaje de error se pueda presentar desde el punto de vista del usuario.

Los mensajes de error correctos no son solo un problema de interfaz de usuario, sino que son un problema de diseño de software. Una buena experiencia de mensaje de error no es algo que se pueda atacar más adelante.

Solución de problemas (y cómo evitarlo)

Solución de problemas de resultados cuando se notifica un problema con varias causas diferentes con un único mensaje de error.

Incorrecto:

diagram of one message stating three causes

Correcto:

diagram of three messages stating one cause each

Solución de problemas de resultados cuando se notifican varios problemas con un único mensaje de error.

En el ejemplo siguiente, no se pudo mover un elemento porque ya se movió o eliminó o se denegó el acceso. Si el programa puede determinar fácilmente la causa, ¿por qué poner la carga al usuario para determinar la causa específica?

Incorrecto:

screen shot of message stating two causes

Bueno, ¿cuál es? Ahora el usuario tiene que solucionar problemas.

El programa puede determinar si se denegó el acceso, por lo que este problema debe notificarse con un mensaje de error específico.

Correcto:

screen shot of message stating one cause

Con una causa específica, no se requiere ninguna solución de problemas.

Use mensajes con varias causas solo cuando no se pueda determinar la causa específica. En este ejemplo, sería difícil que el programa determinara si el elemento se movió o eliminó, por lo que podría usarse aquí un único mensaje de error con varias causas. Sin embargo, es poco probable que los usuarios se preocupen si, por ejemplo, no pudieron mover un archivo eliminado. Para estas causas, el mensaje de error ni siquiera es necesario.

Control de errores desconocidos

En algunos casos, realmente no sabrá el problema, la causa o la solución. Si no se tratara de suprimir el error, es mejor estar delante de la falta de información que presentar problemas, causas o soluciones que podrían no ser correctas.

Por ejemplo, si el programa tiene una excepción no controlada, el siguiente mensaje de error es adecuado:

screen shot of message: unknown error occurred

Si no puede suprimir un error desconocido, es mejor estar por adelantado sobre la falta de información.

Por otro lado, proporcione información específica y procesable si es probable que sea útil la mayor parte del tiempo.

Screenshot that shows an Office Communicator 'server unavailable' message.

Este mensaje de error es adecuado para un error desconocido si la conectividad de red suele ser el problema.

Determinar el tipo de mensaje adecuado

Algunos problemas se pueden presentar como un error, una advertencia o información, según el énfasis y la expresión. Por ejemplo, supongamos que una página web no puede cargar un control de ActiveX sin firmar basado en la configuración actual de Windows Internet Explorer:

  • Error. "Esta página no puede cargar un control de ActiveX sin firmar". (Fraseda como un problema existente).
  • Advertencia. "Es posible que esta página no se comporte según lo esperado porque Windows Internet Explorer no está configurado para cargar controles de ActiveX sin firmar" o "Permitir que esta página instale un control de ActiveX sin firmar? Si lo hace desde orígenes que no son de confianza, puede dañar el equipo". (Ambas frases como condiciones que pueden causar problemas futuros).
  • Información. "Ha configurado Windows Internet Explorer para bloquear controles de ActiveX sin firmar". (Fraseda como una declaración de hecho).

Para determinar el tipo de mensaje adecuado, céntrese en el aspecto más importante del problema que los usuarios necesitan conocer o actuar. Normalmente, si un problema impide que el usuario continúe, debe presentarlo como un error; si el usuario puede continuar, presentándolo como una advertencia. Cree la instrucción principal u otro texto correspondiente basado en ese foco y, a continuación, elija un icono (estándar o de otro modo) que coincida con el texto. El texto de la instrucción principal y los iconos siempre deben coincidir.

Presentación del mensaje de error

La mayoría de los mensajes de error de Windows programas se presentan mediante cuadros de diálogo modales (como son la mayoría de los ejemplos de este artículo), pero hay otras opciones:

  • In situ
  • Globos
  • Notificaciones
  • Iconos del área de notificación
  • Barras de estado
  • Archivos de registro (para errores dirigidos a profesionales de TI)

Colocar mensajes de error en cuadros de diálogo modales tiene la ventaja de exigir la atención y el reconocimiento inmediatos del usuario. Sin embargo, esta es también su principal desventaja si no es necesaria esa atención.

screen shot of message: stop what you are doing

¿Realmente necesita interrumpir a los usuarios para que puedan hacer clic en el botón Cerrar? Si no es así, considere la posibilidad de usar un cuadro de diálogo modal.

Los cuadros de diálogo modales son una excelente opción cuando el usuario debe reconocer el problema inmediatamente antes de continuar, pero a menudo una mala elección en caso contrario. Por lo general, debe preferir usar la presentación de peso más ligera que hace bien el trabajo.

Evitar la sobrecomunicación

Por lo general, los usuarios no leen, examinan. Cuanto más texto haya, más difícil será examinar el texto y más probable es que los usuarios no lean el texto en absoluto. Como resultado, es importante reducir el texto a sus aspectos básicos y utilizar vínculos de divulgación progresiva y ayuda cuando sea necesario para proporcionar información adicional.

Hay muchos ejemplos extremos, pero echemos un vistazo a uno más típico. El ejemplo siguiente tiene la mayoría de los atributos de un buen mensaje de error, pero su texto no es conciso y requiere motivación para leer.

Incorrecto:

screen shot of verbose message

Este ejemplo es un buen mensaje de error, pero sobrecomunica.

¿Qué dice realmente todo este texto? Algo como esto:

Correcto:

screen shot of message: cd recorder not detected

Este mensaje de error tiene esencialmente la misma información, pero es mucho más conciso.

Al usar ayuda para proporcionar los detalles, este mensaje de error tiene un estilo piramidal invertido de presentación.

Para obtener más instrucciones y ejemplos sobre la sobrecomunicación, consulte Texto de la interfaz de usuario.

Si solo hace ocho cosas

  1. Diseñe el programa para el control de errores.
  2. No proporcione mensajes de error innecesarios.
  3. Evite la confusión del usuario al proporcionar los mensajes de error necesarios.
  4. Asegúrese de que el mensaje de error proporciona un problema, una causa y una solución.
  5. Asegúrese de que el mensaje de error sea relevante, procesable, breve, claro, específico, amable y poco frecuente.
  6. Diseñe mensajes de error desde el punto de vista del usuario, no desde el punto de vista del programa.
  7. Evite involucrar al usuario en la solución de problemas mediante un mensaje de error diferente para cada causa detectable.
  8. Utilice el método de presentación de peso más ligero que hace bien el trabajo.

Patrones de uso

Los mensajes de error tienen varios patrones de uso:

Etiqueta Value
Problemas del sistema
El sistema operativo, el dispositivo de hardware, la red o el programa han producido un error o no están en el estado necesario para realizar una tarea.
El usuario puede resolver muchos problemas del sistema:
  • Los problemas del dispositivo se pueden resolver activando el dispositivo, reconectando el dispositivo e insertando medios.
  • Los problemas de red se pueden resolver comprobando la conexión de red física y ejecutando Diagnóstico y reparación de red.
  • Los problemas del programa se pueden resolver cambiando las opciones del programa o reiniciando el programa.
Screen shot of message: Can't find a camera
En este ejemplo, el programa no puede encontrar una cámara para realizar una tarea de usuario.
Screen shot of message Network discovery off
En este ejemplo, es necesario activar una característica necesaria para realizar una tarea.
Problemas de archivos
No se encontró un archivo o carpeta necesario para una tarea iniciada por el usuario, ya está en uso o no tiene el formato esperado.
Screen shot of message: Can't delete file
En este ejemplo, no se puede eliminar el archivo o la carpeta porque no se encontró.
Screen shot of message: Can't play this file
En este ejemplo, el programa no admite el formato de archivo especificado.
Problemas de seguridad
El usuario no tiene permiso para acceder a un recurso o privilegios suficientes para realizar una tarea iniciada por el usuario.
Screen shot of message: You don't have permission
En este ejemplo, el usuario no tiene permiso para acceder a un recurso.
Screen shot of message: You don't have privilege
En este ejemplo, el usuario no tiene el privilegio de realizar una tarea.
Problemas de tareas
Hay un problema específico al realizar una tarea iniciada por el usuario (que no sea un sistema, un archivo no encontrado, un formato de archivo o un problema de seguridad).
Screen shot of message: Data can't be pasted
En este ejemplo, los datos del Portapapeles no se pueden pegar en Paint.
Screen shot of message: Upgrade can't be installed
En este ejemplo, el usuario no puede instalar una actualización de software.
Problemas de entrada de usuario
El usuario especificó un valor incorrecto o incoherente con otra entrada de usuario.
Screen shot of message: Incorrect time value
En este ejemplo, el usuario escribió un valor de hora incorrecto.
Screen shot of message: Incorrect input format
En este ejemplo, la entrada del usuario no tiene el formato correcto.

Directrices

Presentación

  • Use diálogos de tareas siempre que corresponda para lograr una apariencia y un diseño coherentes. Los cuadros de diálogo de tareas requieren Windows Vista o posterior, por lo que no son adecuados para versiones anteriores de Windows. Si debe usar un cuadro de mensaje, separe la instrucción principal de la instrucción complementaria con dos saltos de línea.

Errores de entrada del usuario

  • Siempre que sea posible, evite o reduzca los errores de entrada del usuario por:
    • Uso de controles restringidos a valores válidos.
    • Deshabilitar controles y elementos de menú al hacer clic produciría un error, siempre y cuando sea obvio por qué el control o el elemento de menú está deshabilitado.
    • Proporcionar buenos valores predeterminados.

Incorrecto:

screen shot of text box with speaker volume label

En este ejemplo, se usa un cuadro de texto sin restricciones para la entrada restringida. En su lugar, use un control deslizante.

  • Use el control de errores modeless (errores en contexto o globos) para problemas contextuales de entrada del usuario.
  • Use globos para problemas de entrada de usuario de punto único no críticos detectados en un cuadro de texto o inmediatamente después de que un cuadro de texto pierda el foco.Los globos no requieren espacio de pantalla disponible ni el diseño dinámico necesario para mostrar mensajes en contexto. Muestra solo un solo globo a la vez. Dado que el problema no es crítico, no es necesario ningún icono de error. Los globos desaparecen cuando se hace clic, cuando se resuelve el problema o después de un tiempo de espera.

screen shot of message: incorrect character

En este ejemplo, un globo indica un problema de entrada mientras sigue en el control .

  • Use errores en contexto para la detección de errores retrasada, normalmente los errores encontrados haciendo clic en un botón confirmar. (No use errores en contexto para la configuración que se confirma inmediatamente). Puede haber varios errores en contexto a la vez. Use texto normal y un icono de error de 16 x 16 píxeles, colocándolos directamente junto al problema siempre que sea posible. Los errores en contexto no desaparecen a menos que el usuario se confirme y no se encuentren otros errores.

screen shot of message: incorrect e-mail address

En este ejemplo, se usa un error en contexto para un error encontrado haciendo clic en el botón Confirmar.

  • Use el control de errores modales (cuadros de diálogo de tareas o cuadros de mensaje) para todos los demás problemas, incluidos los errores que implican varios controles o son errores no contextuales o no de entrada encontrados haciendo clic en un botón confirmar.
  • Cuando se notifica un problema de entrada de usuario, establezca el foco de entrada en el primer control con los datos incorrectos. Desplácese por el control a la vista si es necesario. Si el control es un cuadro de texto, seleccione todo el contenido. Siempre debe ser obvio lo que hace referencia el mensaje de error.
  • No borre la entrada incorrecta. En su lugar, déjelo para que el usuario pueda ver y corregir el problema sin empezar de nuevo.
    • Excepción: Borre los cuadros de texto contraseña y PIN incorrectos porque los usuarios no pueden corregir la entrada enmascarada de forma eficaz.

Solución de problemas

  • Evite crear problemas de solución de problemas. No confíe en un único mensaje de error para notificar un problema con varias causas detectables diferentes.
  • Use un mensaje de error diferente (normalmente una instrucción complementaria diferente) para cada causa detectable. Por ejemplo, si un archivo no se puede abrir por varios motivos, proporcione una instrucción complementaria independiente por cada motivo.
  • Use un mensaje con varias causas solo cuando no se pueda determinar la causa específica. En este caso, presente las soluciones en orden de probabilidad de corregir el problema. Esto ayuda a los usuarios a resolver el problema de forma más eficaz.

Iconos

  • Los cuadros de diálogo de mensaje de error modal no tienen iconos de barra de título. Los iconos de la barra de título se usan como distinción visual entre las ventanas principales y las ventanas secundarias.

  • Use un icono de error. Excepciones:

    • Si el error es un problema de entrada de usuario mostrado mediante un cuadro de diálogo modal o un globo, no use un icono. Hacerlo es contrarresiente al tono de Windows. Sin embargo, los mensajes de error en contexto deben usar un pequeño icono de error (16 x 16 píxeles) para identificarlos claramente como mensajes de error.

      screen shot of message incorrect postal format

      screen shot of message computer name too long

      En estos ejemplos, los problemas de entrada del usuario no necesitan iconos de error.

      screen shot of message phone number wrong format

      En este ejemplo, un mensaje de error local necesita un pequeño icono de error para identificarlo claramente como un mensaje de error.

  • Si el problema es para una característica que tiene un icono (y no un problema de entrada del usuario), puede usar el icono de característica con una superposición de errores. Si lo hace, use también el nombre de la característica como asunto del error.

    screen shot message media player can't play file

    En este ejemplo, el icono de característica tiene una superposición de error y la característica es el asunto del error.

  • No use iconos de advertencia para errores. Esto se hace a menudo para hacer que la presentación se sienta menos grave. Los errores no son advertencias.

    Incorrecto:

    screen shot of message fast switching not enabled

    En este ejemplo, se usa incorrectamente un icono de advertencia para hacer que el error se sienta menos grave.

Para obtener más instrucciones y ejemplos, consulte Iconos estándar.

Muestra progresiva

  • Use un botón Mostrar u ocultar detalles de divulgación progresiva para ocultar información avanzada o detallada en un mensaje de error. Al hacerlo, se simplifica el mensaje de error para el uso típico. No oculte la información necesaria, ya que es posible que los usuarios no lo encuentren.

screen shot of message: activesync can't log on

En este ejemplo, el botón de divulgación progresiva ayuda a los usuarios a explorar en profundidad para obtener más detalles si lo desean o simplifiquen la interfaz de usuario si no lo hacen.

  • No use mostrar u ocultar detalles a menos que realmente haya más detalles. No solo restate la información existente en un formato más detallado.
  • No use Mostrar u ocultar detalles para mostrar la información de ayuda. En su lugar, use vínculos de Ayuda.

Para obtener instrucciones de etiquetado, consulte Controles de divulgación progresiva.

No vuelva a mostrar este mensaje

  • Si un mensaje de error necesita esta opción, reconsidere el error y su frecuencia. Si tiene todas las características de un buen error (relevante, procesable y poco frecuente), no debería tener sentido que los usuarios lo supriman.

Para obtener más instrucciones, vea Cuadros de diálogo.

Valores predeterminados

  • Seleccione la respuesta más segura, menos destructiva o más segura para que sea la predeterminada. Si la seguridad no es un factor, seleccione el comando más probable o conveniente.

Ayuda

  • Diseñe mensajes de error para evitar la necesidad de ayuda. Normalmente, los usuarios no deben tener que leer texto externo para comprender y resolver el problema, a menos que la solución requiera varios pasos.
  • Asegúrese de que el contenido de la Ayuda sea relevante y útil. No debe ser una restateación detallada del mensaje de error en su lugar, debe contener información útil que esté fuera del ámbito del mensaje de error, como formas de evitar el problema en el futuro. No proporcione un vínculo de Ayuda solo porque puede.
  • Use vínculos de Ayuda específicos, concisos y relevantes para acceder al contenido de la Ayuda. No use botones de comando ni divulgación progresiva para este propósito.
  • En el caso de los mensajes de error que no se pueden hacer específicos y accionables, considere la posibilidad de proporcionar vínculos al contenido de la Ayuda en línea. Al hacerlo, puede proporcionar a los usuarios información adicional que puede actualizar después de que se publique el programa.

Para obtener más instrucciones, consulte Ayuda.

Códigos de error

  • En el caso de los mensajes de error que no se pueden hacer específicos y accionables o que se benefician de la Ayuda, considere también la posibilidad de proporcionar códigos de error. Los usuarios suelen usar estos códigos de error para buscar información adicional en Internet.
  • Proporcione siempre una descripción de texto del problema y la solución. No dependa solo del código de error para este propósito.

Incorrecto:

screen shot of message: unable to open file

En este ejemplo, se usa un código de error como sustituto de un texto de solución.

  • Asigne un código de error único para cada causa diferente. Al hacerlo, se evita la solución de problemas.
  • Elija códigos de error que se puedan buscar fácilmente en Internet. Si usa códigos de 32 bits, use una representación hexadecimal con caracteres "0x" iniciales y mayúsculas.

Correcto:

1234

0xC0001234

Incorrecto:

-1

-67113524

  • Use Mostrar u ocultar detalles para mostrar códigos de error. Frase como código de error: <error code>.

screen shot of message: program didn't initialize

En este ejemplo, se usa un código de error para complementar un mensaje de error que puede beneficiarse de más información.

Sonido

  • No acompañe los mensajes de error con un efecto de sonido o un pitido. Si lo hace, no es necesario.
    • Excepción: Reproducir el efecto de sonido Detención crítica si el problema es crítico para el funcionamiento del equipo, y el usuario debe tomar medidas inmediatas para evitar consecuencias graves.

Texto

General

  • Quitar texto redundante. Fíjelo en títulos, instrucciones principales, instrucciones complementarias, vínculos de comandos y botones de confirmación. Por lo general, deje texto completo en instrucciones y controles interactivos y quite cualquier redundancia de los demás lugares.
  • Use explicaciones centradas en el usuario. Describa el problema en términos de acciones o objetivos del usuario, no en términos de lo que el software no está satisfecho. Use el idioma que los usuarios de destino comprendan y usen. Evite la jerga técnica.

Incorrecto:

screen shot of message: input-synchronous call

Correcto:

screen shot of message: busy receiving a call

En estos ejemplos, la versión correcta habla el idioma del usuario, mientras que la versión incorrecta es demasiado técnica.

  • No use las siguientes palabras:
    • Error, error (use el problema en su lugar)
    • No se pudo (no se puede usar en su lugar)
    • No válido, no válido, incorrecto (use incorrecto en su lugar)
    • Anular, matar, finalizar (use stop en su lugar)
    • Grave, grave (use grave en su lugar)

Estos términos son innecesarios y contrarios al tono animado de Windows. Cuando se usa correctamente, el icono de error comunica lo suficiente que hay un problema.

Incorrecto:

screen shot of message: catastrophic failure!

Correcto:

screen shot of message: backup must close at once

En el ejemplo incorrecto, los términos "catastrófico" y "error" no son necesarios.

  • No use expresiones que culpan al usuario o impliquen un error de usuario. Evite usarlo y en la expresión. Aunque generalmente se prefiere la voz activa, use la voz pasiva cuando el usuario sea el sujeto y podría sentirse culpable del error si se usó la voz activa.

Incorrecto:

screen shot of message you entered incorrect logon

Correcto:

screen shot of message: incorrect password

En el ejemplo incorrecto se culpa al usuario mediante la voz activa.

  • Ser específico Evite palabras vagas, como el error de sintaxis y la operación ilegal. Proporcione nombres, ubicaciones y valores específicos de los objetos implicados.

Incorrecto:

No se encontró el archivo.

El disco está lleno.

Valor fuera del intervalo.

El carácter no es válido.

Dispositivo no disponible.

Estos problemas serían mucho más fáciles de resolver con nombres, ubicaciones y valores específicos.

  • No proporcione posibles problemas, causas o soluciones poco probables en un intento de ser específico. No proporcione un problema, una causa o una solución a menos que sea probable que sea correcto. Por ejemplo, es mejor decir que se ha producido un error desconocido que algo que es probable que sea inexacto.
  • Evite la palabra "por favor", excepto en situaciones en las que se le pida al usuario que haga algo inconveniente (por ejemplo, en espera) o que el software tenga la culpa de la situación.

Correcto:

Espere mientras Windows copia los archivos en el equipo.

  • Use la palabra "lo sentimos" solo en los mensajes de error que dan lugar a problemas graves para el usuario (por ejemplo, pérdida de datos o incapacidad de usar el equipo). No disculpe si el problema se produjo durante el funcionamiento normal del programa (por ejemplo, si el usuario necesita esperar a que se encuentre una conexión de red).

Correcto:

Lo sentimos, pero Fabrikam Backup detectó un problema irrecuperable y se cerró para proteger los archivos del equipo.

  • Consulte los productos con sus nombres cortos. No use nombres completos de productos ni símbolos de marca comercial. No incluya el nombre de la empresa a menos que los usuarios asocien el nombre de la compañía al producto. No incluya números de versión del programa.

Incorrecto:

Screenshot that shows a Microsoft Office Outlook 'Can't open this item' message.

Correcto:

screen shot of message: can't open this item

En el ejemplo incorrecto, se usan nombres completos de productos y símbolos de marca comercial.

  • Use comillas dobles alrededor de los nombres de objeto. Al hacerlo, el texto es más fácil de analizar y evitar instrucciones potencialmente embarazosas.
    • Excepción: No es necesario que las rutas de acceso a archivos, las direcciones URL y los nombres de dominio estén entre comillas dobles.

Correcto:

screen shot of message: 'my house' is unavailable

En este ejemplo, el mensaje de error sería confuso si el nombre del objeto no estuviera entre comillas.

  • Evite iniciar oraciones con nombres de objeto. Esto suele ser difícil de analizar.
  • No use signos de exclamación ni palabras con todas las letras mayúsculas. Las signos de exclamación y las letras mayúsculas hacen sentir que estás gritando al usuario.

Para obtener más instrucciones y ejemplos, vea Estilo y tono.

Títulos

  • Use el título para identificar el comando o la característica desde la que se originó el error. Excepciones:
    • Si muchos comandos diferentes muestran un error, considere la posibilidad de usar el nombre del programa en su lugar.
    • Si ese título sería redundante o confuso con la instrucción principal, use el nombre del programa en su lugar.
  • No use el título para explicar o resumir el problema que es el propósito de la instrucción principal.

Incorrecto:

Screenshot that shows a 'Can't rename new folder' message.

En este ejemplo, el título se usa incorrectamente para explicar el problema.

  • Use mayúsculas de estilo de título, sin puntuación final.

Instrucciones principales

  • Use la instrucción principal para describir el problema en lenguaje claro, simple y específico.
  • Use solo una frase completa y concisa. Pare la instrucción principal hasta la información esencial. Puede dejar implícito el asunto si es el programa o el usuario. Incluya el motivo del problema si puede hacerlo concisamente. Si debe explicar algo más, use una instrucción complementaria.

Incorrecto:

screen shot of message: upgrade can't be installed

En este ejemplo, todo el mensaje de error se coloca en la instrucción principal, lo que dificulta la lectura.

  • Ser específico si hay objetos implicados, asigne sus nombres.
  • Evite colocar rutas de acceso y direcciones URL de archivo completas en la instrucción principal. En su lugar, use un nombre corto (como el nombre de archivo) y coloque el nombre completo (como la ruta de acceso del archivo) en la instrucción complementaria. Sin embargo, puede colocar una única ruta de acceso de archivo completa o una dirección URL en la instrucción principal si el mensaje de error no necesita una instrucción complementaria.

screen shot of message: can't delete fabrikam file

En este ejemplo, solo el nombre de archivo está en la instrucción principal. La ruta de acceso completa está en la instrucción complementaria.

  • No proporcione la ruta de acceso completa del archivo y la dirección URL si es obvio desde el contexto.

screen shot of message: can't rename new folder

En este ejemplo, el usuario cambia el nombre de un archivo de Windows Explorer. En este caso, la ruta de acceso completa del archivo no es necesaria porque es obvia desde el contexto.

  • Use el tiempo presente siempre que sea posible.
  • Use mayúsculas de estilo de frase.
  • No incluya puntos finales si la instrucción es una instrucción . Si la instrucción es una pregunta, incluya un signo de interrogación final.

Plantillas de instrucciones principales

Aunque no hay reglas estrictas para la expresión, intente usar las siguientes plantillas de instrucciones principales siempre que sea posible:

  • [nombre de sujeto opcional] no puede [realizar la acción]
  • [nombre de sujeto opcional] no puede [realizar la acción] porque [motivo]
  • [nombre de sujeto opcional] no puede [realizar la acción] en "[nombre de objeto]"
  • [nombre de sujeto opcional] no puede [realizar la acción] en "[nombre del objeto]" porque [motivo]
  • No hay suficiente [recurso] para [realizar la acción]
  • [Nombre del firmante] no tiene un [nombre de objeto] necesario para [propósito]
  • [Dispositivo o configuración] está desactivado para que [resultados no deseados]
  • [Dispositivo o configuración] no está [| disponible | activado | habilitado]
  • "[nombre de objeto]" no está disponible actualmente
  • El nombre de usuario o la contraseña son incorrectos
  • No tiene permiso para acceder a "[nombre de objeto]"
  • No tiene privilegios para [realizar la acción]
  • [nombre del programa] ha experimentado un problema grave y debe cerrarse inmediatamente

Por supuesto, realice cambios según sea necesario para que la instrucción principal sea gramaticalmente correcta y cumpla con las directrices de instrucción principales.

Instrucciones complementarias

  • Use la instrucción complementaria para:
    • Proporcione detalles adicionales sobre el problema.
    • Explique la causa del problema.
    • Enumere los pasos que el usuario puede realizar para solucionar el problema.
    • Proporcione medidas para evitar que el problema se vuelva a incurrir.
  • Siempre que sea posible, proponer una solución práctica y útil para que los usuarios puedan solucionar el problema. Sin embargo, asegúrese de que la solución propuesta es probable que solucione el problema. No pierdas el tiempo de los usuarios mediante la sugerencia de soluciones posibles, pero improbables.

Incorrecto:

screen shot of message: out of memory

En este ejemplo, aunque el problema y su solución recomendada son posibles, son muy improbables.

  • Si el problema es un valor incorrecto que especificó el usuario, use la instrucción complementaria para explicar los valores correctos. Los usuarios no deben tener que determinar esta información de otro origen.
  • No proporcione una solución si se puede deducir trivialmente de la instrucción del problema.

screen shot of message: incorrect time value

En este ejemplo, no se necesita ninguna instrucción complementaria; La solución se puede deducir trivialmente de la instrucción del problema.

  • Si la solución tiene varios pasos, presente los pasos en el orden en que deben completarse. Sin embargo, evite soluciones de varios pasos porque los usuarios tienen dificultades para recordar más de dos o tres pasos simples. Si se requieren más pasos, consulte el tema de Ayuda adecuado.
  • Mantenga las instrucciones complementarias concisas. Proporcione solo lo que los usuarios necesitan saber. Omita los detalles innecesarios. Aspira a un máximo de tres oraciones de longitud moderada.
  • Para evitar errores mientras los usuarios realizan instrucciones, coloque los resultados antes de la acción.

Correcto:

Para reiniciar Windows, haga clic en Aceptar.

Incorrecto:

Haga clic en Aceptar para reiniciar Windows.

En el ejemplo incorrecto, es más probable que los usuarios hagan clic en Aceptar por accidente.

  • No recomiende ponerse en contacto con un administrador a menos que lo haga entre las soluciones más probables para el problema. Reserva estas soluciones para problemas que realmente solo pueden ser resueltos por un administrador.

Incorrecto:

screen shot of message: server unavailable

En este ejemplo, lo más probable es que el problema se produzca con la conexión de red del usuario, por lo que no vale la pena ponerse en contacto con un administrador.

  • No recomiende ponerse en contacto con el soporte técnico. La opción de ponerse en contacto con el soporte técnico para solucionar un problema siempre está disponible y no es necesario promoverla a través de mensajes de error. En su lugar, céntrese en escribir mensajes de error útiles para que los usuarios puedan resolver problemas sin ponerse en contacto con el soporte técnico.

Incorrecto:

Screenshot that shows a 'Can't open this item' message.

En este ejemplo, el mensaje de error recomienda incorrectamente ponerse en contacto con el soporte técnico.

  • Use oraciones completas, mayúsculas de estilo de oración y puntuación final.

Botones de confirmación

  • Si el mensaje de error proporciona botones de comando o vínculos de comandos que resuelven el problema, siga sus respectivas directrices en Cuadros de diálogo.
  • Si el programa debe finalizar como resultado del error, proporcione un botón Salir del programa. Para evitar confusiones, no use Close para este propósito.
  • De lo contrario, proporcione un botón Cerrar. No use Ok para los mensajes de error, ya que esta redacción implica que los problemas son correctos.
    • Excepción: Use Aceptar si el mecanismo de notificación de errores tiene etiquetas fijas (como con la API MessageBox).

Documentación

Al hacer referencia a errores:

  • Consulte los errores por su instrucción principal. Si la instrucción principal es larga o detallada, compónela.
  • Si es necesario, puede hacer referencia a un cuadro de diálogo de mensaje de error como mensaje. Consulte como un mensaje de error solo en programación y en otra documentación técnica.
  • Cuando sea posible, dé formato al texto con negrita. De lo contrario, coloque el texto entre comillas solo si es necesario para evitar confusiones.

Ejemplo: Si recibe un elemento No hay ningún disco CD en el mensaje de la unidad , inserte un nuevo disco CD en la unidad e inténtelo de nuevo.