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. En cambio, 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.

Un 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é ha ocurrido 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 cruciales 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, los iconos estándar, las notificaciones y el diseño se presentan en artículos independientes.

¿Es esta la interfaz de usuario adecuada?

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 provocarí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 para que sea mejor suprimir el error.
• ¿El problema es relevante 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 omitirlo 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 fuertemente 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:

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 mostrando este mensaje de error, Windows evita 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 los usuarios.

Causa inicial: 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 les importan.

Mensajes de error "Correctos"

Incorrecto:

Este mensaje de error fue el resultado de la elección del usuario de no reiniciar 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 los usuarios.

Causa inicial: 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:

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

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

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

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

Mensajes de error incomprensibles

Incorrecto:

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

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

Causa inicial: 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 entender 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:

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

El problema: Demasiada información.

Causa inicial: 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 vinculando al tema adecuado en Ayuda.

Mensajes de error innecesariamente duros

Incorrecto:

La incapacidad del programa para encontrar un objeto apenas suena grave. 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 inicial: 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:

¿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:

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:

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:

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:

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:

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:

¿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:

Lo más probable es que el problema sea desconocido porque falta el soporte de control de errores del programa.

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 ninguna 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:

Correcto:

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:

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:

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:

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.

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 ActiveX sin firmar basado en la configuración actual de Windows Internet Explorer:

• Error. "Esta página no puede cargar un control 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 ActiveX sin firmar" o "Permitir que esta página instale un control 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 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 los programas de Windows 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.

¿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:

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

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

Correcto:

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. En este ejemplo, el programa no puede encontrar una cámara para realizar una tarea de usuario. 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.	En este ejemplo, no se puede eliminar el archivo o la carpeta porque no se encontró. 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.	En este ejemplo, el usuario no tiene permiso para acceder a un recurso. 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).	En este ejemplo, los datos del Portapapeles no se pueden pegar en Paint. 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.	En este ejemplo, el usuario escribió un valor de hora incorrecto. En este ejemplo, la entrada del usuario no tiene el formato correcto.

Instrucciones

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 versiones posteriores, 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:

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 no críticos y de punto único 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.

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.

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 del usuario que se muestra mediante un cuadro de diálogo modal o un globo, no use un icono. Hacerlo es contrarreste con el tono animado 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.

    

    

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

    

    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.

  

  En este ejemplo, el icono de característica tiene una superposición de errores 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:

  

  En este ejemplo, se usa incorrectamente un icono de advertencia para 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.

En este ejemplo, el botón de divulgación progresiva ayuda a los usuarios a explorar en profundidad 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 restablezte 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, accionable y poco frecuente), no debe tener sentido que los usuarios lo supriman.

Para obtener más instrucciones, consulte 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:

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>.

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:

Correcto:

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, terminar, finalizar (use stop en su lugar)
  • Grave, grave (use en su lugar serio)

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

Incorrecto:

Correcto:

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

• No use expresiones que culpen al usuario o impliquen un error de usuario. Evite usar usted y su en la expresión. Aunque la voz activa suele ser preferida, use la voz pasiva cuando el usuario sea el sujeto y podría sentirse culpable del error si se usó la voz activa.

Incorrecto:

Correcto:

El ejemplo incorrecto culpa al usuario mediante la voz activa.

• Ser específico Evite las 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.

El dispositivo no está 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 improbables 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 en el 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 empresa al producto. No incluya números de versión del programa.

Incorrecto:

Correcto:

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. Si lo hace, el texto es más fácil de analizar y evita instrucciones potencialmente embarazosas.
  • Excepción: No es necesario que las rutas de acceso, las direcciones URL y los nombres de dominio estén entre comillas dobles.

Correcto:

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 que se sienta como si estuviera gritando al usuario.

Para obtener más instrucciones y ejemplos, vea Style y Tone.

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:

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

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

Instrucciones principales

• Use la instrucción principal para describir el problema en lenguaje claro, sin formato y específico.
• Sea conciso, use solo una frase única y completa. 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 de forma concisa. Si debe explicar algo más, use una instrucción complementaria.

Incorrecto:

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

• Sea 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 archivo completa o una dirección URL en la instrucción principal si el mensaje de error no necesita una instrucción complementaria.

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.

En este ejemplo, el usuario cambia el nombre de un archivo desde el Explorador de Windows. En este caso, la ruta de acceso completa del archivo no es necesaria porque es obvia del 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 expresiones, 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 acción] porque [motivo]
• [nombre de sujeto opcional] no puede [realizar acción] a "[nombre de objeto]"
• [nombre de sujeto opcional] no puede [realizar acción] en "[nombre de 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 | encontrado | 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:

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.

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:

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:

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.