Mensagens de erro no Windows 7

Observação

Este guia de design foi criado para o Windows 7 e não foi atualizado para versões mais recentes do Windows. Grande parte das diretrizes ainda se aplica em princípio, mas a apresentação e os exemplos não refletem nossas diretrizes de design atuais.

Mensagens de erro no Windows 7 alertam os usuários sobre problemas que já ocorreram. Por outro lado, as mensagens de aviso alertam os usuários sobre condições que podem causar problemas no futuro. Mensagens de erro podem ser apresentadas usando caixas de diálogo modais, mensagens in-loco, notificações ou balões.

Uma mensagem de erro modal típica.

Mensagens de erro efetivas informam aos usuários que ocorreu um problema, explicam por que isso aconteceu e fornecem uma solução para que os usuários possam corrigir o problema. Os usuários devem executar uma ação ou alterar seu comportamento como resultado de uma mensagem de erro.

Mensagens de erro úteis e bem escritas são cruciais para uma experiência de usuário de qualidade. Mensagens de erro mal escritas resultam em baixa satisfação do produto e são uma das principais causas de custos de suporte técnico evitáveis. Mensagens de erro desnecessárias interrompem o fluxo dos usuários.

Nota: Diretrizes relacionadas a caixas de diálogo, mensagens de aviso, confirmações, ícones padrão, notificações e layout são apresentadas em artigos separados.

Essa é a interface do usuário certa?

Para decidir, considere estas perguntas:

• A interface do usuário está apresentando um problema que já ocorreu? Caso contrário, a mensagem não será um erro. Se o usuário estiver sendo alertado sobre uma condição que pode causar um problema no futuro, use uma mensagem de aviso.
• O problema pode ser evitado sem causar confusão? Nesse caso, evite o problema. Por exemplo, use controles restritos a valores válidos em vez de usar controles irrestritos que podem exigir mensagens de erro. Além disso, desabilitar controles ao clicar resultaria em erro, desde que seja óbvio por que o controle está desabilitado.
• O problema pode ser corrigido automaticamente? Nesse caso, lide com o problema e suprima a mensagem de erro.
• É provável que os usuários executem uma ação ou alterem seu comportamento como resultado da mensagem? Caso contrário, a condição não justifica a interrupção do usuário, portanto, é melhor suprimir o erro.
• O problema é relevante quando os usuários estão usando ativamente outros programas? Nesse caso, considere mostrar o problema usando um ícone de área de notificação.
• O problema não está relacionado à atividade atual do usuário, não requer ação imediata do usuário e os usuários podem ignorá-lo livremente? Nesse caso, use uma notificação de falha de ação .
• O problema está relacionado ao status de uma tarefa em segundo plano em uma janela primária? Nesse caso, considere mostrar o problema usando uma status barras.
• Os principais usuários de TI de destino são profissionais de TI? Nesse caso, considere usar um mecanismo de comentários alternativo, como entradas de arquivo de log ou alertas de email. Os profissionais de TI preferem fortemente arquivos de log para informações não críticas.

Conceitos de design

As características das mensagens de erro ruins

Não deve ser surpresa que haja muitas mensagens de erro irritantes, inúteis e mal escritas. E como as mensagens de erro geralmente são apresentadas usando diálogos modais, elas interrompem a atividade atual do usuário e exigem ser confirmadas antes de permitir que o usuário continue.

Parte do problema é que há tantas maneiras de fazê-lo errado. Considere estes exemplos do Salão de Mensagem de Erro da Vergonha:

Mensagens de erro desnecessárias

Incorreto:

Este exemplo do Windows XP pode ser a pior mensagem de erro de todos os tempos. Isso indica que um programa não pôde ser iniciado porque o próprio Windows está em processo de desligamento. Não há nada que o usuário possa fazer sobre isso ou mesmo queira fazer isso (o usuário optou por desligar o Windows, afinal). E exibindo essa mensagem de erro, o Windows impede que ele seja desligado!

O problema: A mensagem de erro em si é o problema. Além de ignorar a mensagem de erro, não há nada para os usuários fazerem.

Causa principal: Relatar todos os casos de erro, independentemente das metas ou do ponto de vista dos usuários.

Alternativa recomendada: Não relate erros com os quais os usuários não se importam.

Mensagens de erro "Êxito"

Incorreto:

Essa mensagem de erro resultou do usuário optar por não reiniciar o Windows imediatamente após a remoção do programa. A remoção do programa foi bem-sucedida do ponto de vista do usuário.

O problema: Não há nenhum erro do ponto de vista do usuário. Além de ignorar a mensagem de erro, não há nada para os usuários fazerem.

Causa principal: A tarefa foi concluída com êxito do ponto de vista do usuário, mas falhou do ponto de vista do programa de desinstalação.

Alternativa recomendada: Não relate erros para condições que os usuários consideram aceitáveis.

Mensagens de erro completamente inúteis

Incorreto:

Os usuários aprendem que houve um erro, mas não têm ideia do que foi o erro ou o que fazer sobre ele. E não, não está tudo bem!

O problema: A mensagem de erro não dá um problema específico e não há nada que os usuários possam fazer sobre isso.

Causa principal: Provavelmente, o programa tem mau tratamento de erros.

Alternativa recomendada: Crie um bom tratamento de erros no programa.

Mensagens de erro incompreensíveis

Incorreto:

Neste exemplo, a instrução de problema é clara, mas a explicação complementar é totalmente desconcertante.

O problema: A instrução ou solução do problema é incompreensível.

Causa principal: Explicando o problema do ponto de vista do código em vez do do usuário.

Alternativa recomendada: Escreva um texto de mensagem de erro que os usuários de destino possam entender facilmente. Forneça soluções que os usuários possam realmente executar. Projetar a experiência de mensagem de erro do programa não tem programadores que compõem mensagens de erro no local.

Mensagens de erro que supercomunizam

Incorreto:

Neste exemplo, a mensagem de erro aparentemente tenta explicar todas as etapas de solução de problemas.

O problema: Muita informação.

Causa principal: Fornecer muitos detalhes ou tentar explicar um processo complicado de solução de problemas dentro de uma mensagem de erro.

Alternativa recomendada: Evite detalhes desnecessários. Além disso, evite solucionadores de problemas. Se uma solução de problemas for necessária, concentre-se nas soluções mais prováveis e explique o restante vinculando-se ao tópico apropriado na Ajuda.

Mensagens de erro desnecessariamente duras

Incorreto:

A incapacidade do programa de encontrar um objeto dificilmente soa catastrófica. E supondo que seja catastrófico, por que está bem a resposta?

O problema: O tom do programa é desnecessariamente severo ou dramático.

Causa principal: O problema ocorre devido a um bug que parece catastrófico do ponto de vista do programa.

Alternativa recomendada: Escolha o idioma cuidadosamente com base no ponto de vista do usuário.

Mensagens de erro que blame usuários

Incorreto:

Por que fazer com que os usuários se sintam criminosos?

O problema: A mensagem de erro é formulada de uma forma que acusa o usuário de cometer um erro.

Causa principal: Frases não sensíveis que se concentram no comportamento do usuário em vez do problema.

Alternativa recomendada: Concentre-se no problema, não na ação do usuário que levou ao problema, usando a voz passiva conforme necessário.

Mensagens de erro bobas

Incorreto:

Neste exemplo, a instrução de problema é bastante irônica e nenhuma solução é fornecida.

O problema: Instruções de mensagem de erro que são bobas ou não sequitors.

Causa principal: Criar mensagens de erro sem prestar atenção ao contexto.

Alternativa recomendada: Tenha suas mensagens de erro criadas e revisadas por um gravador. Considere o contexto e o estado mental do usuário ao revisar os erros.

Mensagens de erro do programador

Incorreto:

Neste exemplo, a mensagem de erro indica que há um bug no programa. Essa mensagem de erro tem significado apenas para o programador.

O problema: As mensagens destinadas a ajudar os desenvolvedores do programa a encontrar bugs são deixadas na versão de lançamento do programa. Essas mensagens de erro não têm nenhum significado ou valor para os usuários.

Causa principal: Programadores que usam a interface do usuário normal para fazer mensagens para si mesmos.

Alternativa recomendada: Os desenvolvedores devem compilar condicionalmente todas essas mensagens para que elas sejam removidas automaticamente da versão de lançamento de um produto. Não perca tempo tentando cometer erros como esse que podem ser compreensíveis para os usuários porque seu único público-alvo são os programadores.

Mensagens de erro mal apresentadas

Incorreto:

Este exemplo tem muitos erros comuns de apresentação.

O problema: Obtendo todos os detalhes errados na apresentação da mensagem de erro.

Causa principal: Não conhecer e aplicar as diretrizes de mensagem de erro. Não usar gravadores e editores para criar e revisar as mensagens de erro.

A natureza do tratamento de erros é tal que muitos desses erros são muito fáceis de cometer. É perturbador perceber que a maioria das mensagens de erro pode ser indicada para o Salão da Vergonha.

As características de boas mensagens de erro

Ao contrário dos exemplos inválidos anteriores, boas mensagens de erro têm:

• Um problema. Indica que ocorreu um problema.
• Uma causa. Explica por que o problema ocorreu.
• Uma solução. Fornece uma solução para que os usuários possam corrigir o problema.

Além disso, boas mensagens de erro são apresentadas de uma maneira que é:

• Relevantes. A mensagem apresenta um problema com o qual os usuários se preocupam.
• Acionáveis. Os usuários devem executar uma ação ou alterar seu comportamento como resultado da mensagem.
• Centralizado pelo usuário. A mensagem descreve o problema em termos de ações ou metas de usuário de destino, não em termos do que o código está insatisfeito.
• Breve. A mensagem é o mais curta possível, mas não menor.
• Limpar. A mensagem usa linguagem simples para que os usuários de destino possam entender facilmente o problema e a solução.
• Específico. A mensagem descreve o problema usando uma linguagem específica, dando nomes, locais e valores específicos dos objetos envolvidos.
• Cortês. Os usuários não devem ser culpados ou obrigados a se sentirem estúpidos.
• Raro. Exibido com pouca frequência. As mensagens de erro exibidas com frequência são um sinal de design incorreto.

Ao projetar sua experiência de tratamento de erros para ter essas características, você pode manter as mensagens de erro do programa fora do Hall da Vergonha da Mensagem de Erro.

Evitando mensagens de erro desnecessárias

Geralmente, a melhor mensagem de erro não é uma mensagem de erro. Muitos erros podem ser evitados por meio de um design melhor, e muitas vezes há alternativas melhores para mensagens de erro. Geralmente, é melhor evitar um erro do que relatar um.

As mensagens de erro mais óbvias a evitar são aquelas que não são acionáveis. Se os usuários provavelmente ignorarem a mensagem sem fazer ou alterar nada, omita a mensagem de erro.

Algumas mensagens de erro podem ser eliminadas porque não são problemas do ponto de vista do usuário. Por exemplo, suponha que o usuário tentou excluir um arquivo que já está em processo de exclusão. Embora esse possa ser um caso inesperado do ponto de vista do código, os usuários não consideram isso um erro porque o resultado desejado é alcançado.

Incorreto:

Essa mensagem de erro deve ser eliminada porque a ação foi bem-sucedida do ponto de vista do usuário.

Para outro exemplo, suponha que o usuário cancele explicitamente uma tarefa. Para o ponto de vista do usuário, a condição a seguir não é um erro.

Incorreto:

Essa mensagem de erro também deve ser eliminada porque a ação foi bem-sucedida do ponto de vista do usuário.

Às vezes, as mensagens de erro podem ser eliminadas concentrando-se nas metas dos usuários em vez da tecnologia. Ao fazer isso, reconsidere o que realmente é um erro. O problema com as metas do usuário ou com a capacidade do programa de satisfazê-los? Se a ação do usuário fizer sentido no mundo real, ela também deverá fazer sentido no software.

Por exemplo, suponha que em um programa de comércio eletrônico um usuário tente encontrar um produto usando a pesquisa, mas a consulta de pesquisa literal não tem correspondências e o produto desejado está fora de estoque. Tecnicamente, isso é um erro, mas em vez de dar uma mensagem de erro, o programa pode:

• Continue a pesquisar produtos que correspondam mais de perto à consulta.
• Se a pesquisa tiver erros óbvios, recomende automaticamente uma consulta corrigida.
• Lidar automaticamente com problemas comuns, como erros ortográficos, ortografias alternativas e casos de pluralização e verbo incompatíveis.
• Indique quando o produto estará em estoque.

Desde que a solicitação do usuário seja razoável, um programa de comércio eletrônico bem projetado deve retornar resultados razoáveis e não erros.

Outra ótima maneira de evitar mensagens de erro é evitando problemas em primeiro lugar. Você pode evitar erros:

• Usando controles restritos. Use controles restritos a valores válidos. Controles como listas, controles deslizantes, caixas de marcar, botões de opção e seletores de data e hora são restritos a valores válidos, enquanto as caixas de texto geralmente não são e podem exigir mensagens de erro. No entanto, você pode restringir caixas de texto para aceitar apenas determinados caracteres e aceitar um número máximo de caracteres.
• Usando interações restritas. Para operações de arrastar, permita que os usuários solte somente em destinos válidos.
• Usando controles desabilitados e itens de menu. Desabilite controles e itens de menu quando os usuários podem facilmente deduzir por que o controle ou item de menu está desabilitado.
• Fornecendo bons valores padrão. Os usuários são menos propensos a cometer erros de entrada se puderem aceitar os valores padrão. Mesmo que os usuários decidam alterar o valor, o valor padrão permite que os usuários saibam o formato de entrada esperado.
• Fazer as coisas funcionarem. Os usuários têm menos probabilidade de cometer erros se as tarefas forem desnecessárias ou executadas automaticamente para eles. Ou se os usuários cometerem pequenos erros, mas sua intenção for clara, o problema será corrigido automaticamente. Por exemplo, você pode corrigir automaticamente problemas de formatação secundária.

Fornecer mensagens de erro necessárias

Às vezes, você realmente precisa fornecer uma mensagem de erro. Os usuários cometem erros, redes e dispositivos param de funcionar, objetos não podem ser encontrados ou modificados, tarefas não podem ser concluídas e programas têm bugs. O ideal é que esses problemas ocorram com menos frequência, por exemplo, podemos criar nosso software para evitar muitos tipos de erros do usuário, mas não é realista evitar todos esses problemas. E quando um desses problemas acontece, uma mensagem de erro útil faz com que os usuários se retomem rapidamente.

Uma crença comum é que as mensagens de erro são a pior experiência do usuário e devem ser evitadas a todo custo, mas é mais preciso dizer que a confusão do usuário é a pior experiência e deve ser evitada a todo custo. Às vezes, esse custo é uma mensagem de erro útil.

Considere os controles desabilitados. Na maioria das vezes, é óbvio por que um controle está desabilitado, portanto, desabilitar o controle é uma ótima maneira de evitar uma mensagem de erro. No entanto, e se o motivo pelo qual um controle está desabilitado não for óbvio? O usuário não pode continuar e não há comentários para determinar o problema. Agora, o usuário está preso e precisa deduzir o problema ou obter suporte técnico. Nesses casos, é muito melhor deixar o controle habilitado e dar uma mensagem de erro útil.

Incorreto:

Por que o botão Avançar está desabilitado aqui? É melhor deixá-lo habilitado e evitar confusão do usuário, dando uma mensagem de erro útil.

Se você não tiver certeza se deve enviar uma mensagem de erro, comece redigindo a mensagem de erro que você pode dar. Se os usuários provavelmente executarem uma ação ou alterarem seu comportamento como resultado, forneça a mensagem de erro. Por outro lado, se os usuários provavelmente ignorarem a mensagem sem fazer ou alterar nada, omita a mensagem de erro.

Projetando para uma boa manipulação de erros

Embora a criação de um bom texto de mensagem de erro possa ser desafiadora, às vezes é impossível sem um bom suporte de tratamento de erros do programa. Considere esta mensagem de erro:

Incorreto:

As chances são de que o problema seja realmente desconhecido porque o suporte ao tratamento de erros do programa está faltando.

Embora seja possível que essa seja uma mensagem de erro muito mal escrita, ela provavelmente reflete a falta de boa manipulação de erros pelo código subjacente, não há informações específicas conhecidas sobre o problema.

Para criar mensagens de erro específicas, acionáveis e centradas no usuário, o código de tratamento de erros do programa deve fornecer informações de erro específicas e de alto nível:

• Cada problema deve ter um código de erro exclusivo atribuído.
• Se um problema tiver várias causas, o programa deverá determinar a causa específica sempre que possível.
• Se o problema tiver parâmetros, os parâmetros deverão ser mantidos.
• Problemas de baixo nível devem ser tratados em um nível suficientemente alto para que a mensagem de erro possa ser apresentada do ponto de vista do usuário.

Boas mensagens de erro não são apenas um problema de interface do usuário, elas são um problema de design de software. Uma boa experiência de mensagem de erro não é algo que pode ser abordado mais tarde.

Solução de problemas (e como evitá-lo)

Solução de problemas de resultados quando um problema com várias causas diferentes é relatado com uma única mensagem de erro.

Incorreto:

Correto:

Solução de problemas de resultados quando vários problemas são relatados com uma única mensagem de erro.

No exemplo a seguir, não foi possível mover um item porque ele já foi movido ou excluído ou o acesso foi negado. Se o programa pode determinar facilmente a causa, por que colocar a carga sobre o usuário para determinar a causa específica?

Incorreto:

Bem, o que é isso? Agora, o usuário precisa solucionar problemas.

O programa pode determinar se o acesso foi negado, portanto, esse problema deve ser relatado com uma mensagem de erro específica.

Correto:

Com uma causa específica, nenhuma solução de problemas é necessária.

Use mensagens com várias causas somente quando a causa específica não puder ser determinada. Neste exemplo, seria difícil para o programa determinar se o item foi movido ou excluído, portanto, uma única mensagem de erro com várias causas pode ser usada aqui. No entanto, é improvável que os usuários se importem se, por exemplo, não conseguiram mover um arquivo excluído. Para essas causas, a mensagem de erro nem é necessária.

Tratamento de erros desconhecidos

Em alguns casos, você realmente não saberá o problema, a causa ou a solução. Se for imprudente suprimir o erro, é melhor estar adiantado sobre a falta de informações do que apresentar problemas, causas ou soluções que podem não estar corretas.

Por exemplo, se o programa tiver uma exceção sem tratamento, a seguinte mensagem de erro será adequada:

Se você não conseguir suprimir um erro desconhecido, é melhor estar adiantado sobre a falta de informações.

Por outro lado, forneça informações específicas e acionáveis se elas provavelmente serão úteis na maior parte do tempo.

Essa mensagem de erro é adequada para um erro desconhecido se a conectividade de rede geralmente for o problema.

Determinar o tipo de mensagem apropriado

Alguns problemas podem ser apresentados como um erro, aviso ou informações, dependendo da ênfase e da frase. Por exemplo, suponha que uma página da Web não possa carregar um controle ActiveX sem sinal com base na configuração atual de Explorer da Internet do Windows:

• Erro. "Esta página não pode carregar um controle ActiveX sem sinal." (Formulado como um problema existente.)
• Aviso. "Esta página pode não se comportar conforme o esperado porque o Explorer da Internet do Windows não está configurado para carregar controles ActiveX sem sinal" ou "Permitir que esta página instale um Controle ActiveX sem sinal? Fazer isso de fontes não confiáveis pode prejudicar seu computador." (Ambos formulados como condições que podem causar problemas futuros.)
• Informações. "Você configurou o Windows Internet Explorer para bloquear controles ActiveX não assinados." (Frase como uma declaração de fato.)

Para determinar o tipo de mensagem apropriado, concentre-se no aspecto mais importante do problema que os usuários precisam conhecer ou agir. Normalmente, se um problema impedir que o usuário prossiga, você deverá apresentá-lo como um erro; se o usuário puder continuar, apresente-o como um aviso. Crie a instrução main ou outro texto correspondente com base nesse foco e escolha um ícone (padrão ou não) que corresponda ao texto. O main texto de instrução e os ícones devem sempre corresponder.

Apresentação de mensagem de erro

A maioria das mensagens de erro em programas do Windows são apresentadas usando caixas de diálogo modais (como a maioria dos exemplos neste artigo), mas há outras opções:

• No local
• Balões
• Notificações
• Ícones da área de notificação
• Barras de status
• Arquivos de log (para erros direcionados a profissionais de TI)

Colocar mensagens de erro em caixas de diálogo modais tem o benefício de exigir a atenção e a confirmação imediatas do usuário. No entanto, essa também será a principal desvantagem se essa atenção não for necessária.

Você realmente precisa interromper os usuários para que eles possam clicar no botão Fechar? Caso contrário, considere alternativas para usar uma caixa de diálogo modal.

As caixas de diálogo modais são uma ótima opção quando o usuário deve reconhecer o problema imediatamente antes de continuar, mas muitas vezes uma opção ruim de outra forma. Em geral, você deve preferir usar a apresentação de peso mais leve que faz bem o trabalho.

Evitar excesso de comunicação

Geralmente, os usuários não leem, verificam. Quanto mais texto houver, mais difícil será a verificação do texto e maior a probabilidade de os usuários não lerem o texto. Como resultado, é importante reduzir o texto para seus fundamentos e usar a divulgação progressiva e links de Ajuda quando necessário para fornecer informações adicionais.

Há muitos exemplos extremos, mas vamos examinar um mais típico. O exemplo a seguir tem a maioria dos atributos de uma boa mensagem de erro, mas seu texto não é conciso e requer motivação para ler.

Incorreto:

Este exemplo é uma boa mensagem de erro, mas é sobrecomunhável.

O que todo esse texto está realmente dizendo? Algo assim:

Correto:

Essa mensagem de erro tem essencialmente as mesmas informações, mas é muito mais concisa.

Usando a Ajuda para fornecer os detalhes, essa mensagem de erro tem um estilo de apresentação pirâmide invertido .

Para obter mais diretrizes e exemplos sobre comunicação excessiva, consulte Texto da interface do usuário.

Se você fizer apenas oito coisas

1. Projete seu programa para tratamento de erros.
2. Não forneça mensagens de erro desnecessárias.
3. Evite a confusão do usuário fornecendo as mensagens de erro necessárias.
4. Verifique se a mensagem de erro fornece um problema, uma causa e uma solução.
5. Verifique se a mensagem de erro é relevante, acionável, breve, clara, específica, cortosa e rara.
6. Projete mensagens de erro do ponto de vista do usuário, não do ponto de vista do programa.
7. Evite envolver o usuário na solução de problemas, use uma mensagem de erro diferente para cada causa detectável.
8. Use o método de apresentação de peso mais leve que faz bem o trabalho.

Padrões de uso

As mensagens de erro têm vários padrões de uso:

Rótulo	Valor
Problemas do sistema O sistema operacional, o dispositivo de hardware, a rede ou o programa falharam ou não estão no estado necessário para executar uma tarefa.	Muitos problemas do sistema podem ser resolvidos pelo usuário: Problemas de dispositivo podem ser resolvidos ativando o dispositivo, reconectando o dispositivo e inserindo mídia. Os problemas de rede podem ser resolvidos verificando a conexão de rede física e executando Diagnóstico e reparo de rede. Os problemas do programa podem ser resolvidos alterando as opções do programa ou reiniciando o programa. Neste exemplo, o programa não pode encontrar uma câmera para executar uma tarefa de usuário. Neste exemplo, um recurso necessário para executar uma tarefa precisa ser ativado.
Problemas de arquivo Um arquivo ou pasta necessário para uma tarefa iniciada pelo usuário não foi encontrado, já está em uso ou não tem o formato esperado.	Neste exemplo, o arquivo ou pasta não pode ser excluído porque não foi encontrado. Neste exemplo, o programa não dá suporte ao formato de arquivo especificado.
Problemas de segurança O usuário não tem permissão para acessar um recurso ou privilégio suficiente para executar uma tarefa iniciada pelo usuário.	Neste exemplo, o usuário não tem permissão para acessar um recurso. Neste exemplo, o usuário não tem o privilégio de executar uma tarefa.
Problemas de tarefa Há um problema específico ao executar uma tarefa iniciada pelo usuário (além de um sistema, arquivo não encontrado, formato de arquivo ou problema de segurança).	Neste exemplo, os dados da Área de Transferência não podem ser colados no Paint. Neste exemplo, o usuário não pode instalar uma atualização de software.
Problemas de entrada do usuário O usuário inseriu um valor incorreto ou inconsistente com outra entrada do usuário.	Neste exemplo, o usuário inseriu um valor de hora incorreto. Neste exemplo, a entrada do usuário não está no formato correto.

Diretrizes

Apresentação

• Use caixas de diálogo de tarefa sempre que apropriado para obter uma aparência e um layout consistentes. As caixas de diálogo de tarefa exigem o Windows Vista ou posterior, portanto, elas não são adequadas para versões anteriores do Windows. Se você precisar usar uma caixa de mensagem, separe a instrução main da instrução complementar com duas quebras de linha.

Erros de entrada do usuário

• Sempre que possível, evite ou reduza erros de entrada do usuário:
  • Usando controles restritos a valores válidos.
  • Desabilitar controles e itens de menu ao clicar resultaria em erro, desde que seja óbvio por que o controle ou item de menu está desabilitado.
  • Fornecendo bons valores padrão.

Incorreto:

Neste exemplo, uma caixa de texto irrestrita é usada para entrada restrita. Em vez disso, use um controle deslizante.

• Use o tratamento de erros de modelagem (erros in-loco ou balões) para problemas contextuais de entrada do usuário.
• Use balões para problemas de entrada de usuário não críticos e de ponto único detectados em uma caixa de texto ou imediatamente após uma caixa de texto perder o foco.Balões não exigem espaço de tela disponível ou o layout dinâmico necessário para exibir mensagens in-loco. Exibe apenas um único balão por vez. Como o problema não é crítico, nenhum ícone de erro é necessário. Os balões desaparecem quando clicados, quando o problema é resolvido ou após um tempo limite.

Neste exemplo, um balão indica um problema de entrada enquanto ainda está no controle .

• Use erros in-loco para detecção de erros atrasadas, geralmente erros encontrados clicando em um botão de confirmação. (Não use erros in-loco para configurações que são confirmadas imediatamente.) Pode haver vários erros in-loco por vez. Use o texto normal e um ícone de erro de 16 x 16 pixels, colocando-os diretamente ao lado do problema sempre que possível. Os erros in-loco não desaparecem, a menos que o usuário confirme e nenhum outro erro seja encontrado.

Neste exemplo, um erro in-loco é usado para um erro encontrado clicando no botão confirmar.

• Use o tratamento de erro modal (caixas de diálogo de tarefa ou de mensagem) para todos os outros problemas, incluindo erros que envolvem vários controles ou que são erros não contextuais ou não de entrada encontrados clicando em um botão de confirmação.
• Quando um problema de entrada do usuário for relatado, defina o foco de entrada como o primeiro controle com os dados incorretos. Role o controle para a exibição, se necessário. Se o controle for uma caixa de texto, selecione todo o conteúdo. Deve ser sempre óbvio a que a mensagem de erro está se referindo.
• Não limpe a entrada incorreta. Em vez disso, deixe-o para que o usuário possa ver e corrigir o problema sem recomeçar.
  • Exceção: Desmarque caixas de texto de PIN e senha incorretas porque os usuários não podem corrigir a entrada mascarada com eficiência.

Solução de problemas

• Evite criar problemas de solução de problemas. Não confie em uma única mensagem de erro para relatar um problema com várias causas detectáveis diferentes.
• Use uma mensagem de erro diferente (normalmente uma instrução complementar diferente) para cada causa detectável. Por exemplo, se um arquivo não puder ser aberto por vários motivos, forneça uma instrução complementar separada para cada motivo.
• Use uma mensagem com várias causas somente quando a causa específica não puder ser determinada. Nesse caso, apresente as soluções em ordem de probabilidade de corrigir o problema. Isso ajuda os usuários a resolver o problema com mais eficiência.

Ícones

• As caixas de diálogo de mensagem de erro modal não têm ícones de barra de título. Os ícones da barra de título são usados como uma distinção visual entre janelas primárias e janelas secundárias.

• Use um ícone de erro. Exceções:

  • Se o erro for um problema de entrada do usuário exibido usando uma caixa de diálogo modal ou balão, não use um ícone. Fazer isso é contra o tom encorajador do Windows. No entanto, as mensagens de erro in-loco devem usar um pequeno ícone de erro (16 x 16 pixels) para identificá-las claramente como mensagens de erro.

    

    

    Nestes exemplos, os problemas de entrada do usuário não precisam de ícones de erro.

    

    Neste exemplo, uma mensagem de erro in-loco precisa de um pequeno ícone de erro para identificá-la claramente como uma mensagem de erro.

• Se o problema for para um recurso que tem um ícone (e não um problema de entrada do usuário), você pode usar o ícone de recurso com uma sobreposição de erro. Se você fizer isso, use também o nome do recurso como assunto do erro.

  

  Neste exemplo, o ícone de recurso tem uma sobreposição de erro e o recurso é o assunto do erro.

• Não use ícones de aviso para erros. Isso geralmente é feito para fazer com que a apresentação se sinta menos grave. Erros não são avisos.

  Incorreto:

  

  Neste exemplo, um ícone de aviso é usado incorretamente para fazer com que o erro pareça menos grave.

Para obter mais diretrizes e exemplos, consulte Ícones padrão.

Divulgação progressiva

• Use um botão Mostrar/Ocultar detalhes de divulgação progressiva para ocultar informações avançadas ou detalhadas em uma mensagem de erro. Isso simplifica a mensagem de erro para uso típico. Não oculte as informações necessárias, pois os usuários podem não encontrá-la.

Neste exemplo, o botão de divulgação progressiva ajuda os usuários a fazer drill down para obter mais detalhes, se desejarem, ou simplificar a interface do usuário se não o fizerem.

• Não use Mostrar/Ocultar detalhes, a menos que realmente haja mais detalhes. Não apenas reafirme as informações existentes em um formato mais detalhado.
• Não use Mostrar/Ocultar detalhes para mostrar informações da Ajuda. Em vez disso, use links de Ajuda.

Para obter diretrizes de rotulagem, consulte Controles progressivos de divulgação.

Não mostrar esta mensagem novamente

• Se uma mensagem de erro precisar dessa opção, reconsidere o erro e sua frequência. Se ele tiver todas as características de um bom erro (relevante, acionável e pouco frequente), não fará sentido para os usuários suprimi-lo.

Para obter mais diretrizes, consulte Caixas de diálogo.

Valores padrão

• Selecione a resposta mais segura, menos destrutiva ou mais segura para ser o padrão. Se a segurança não for um fator, selecione o comando mais provável ou conveniente.

Ajuda

• Crie mensagens de erro para evitar a necessidade de Ajuda. Normalmente, os usuários não devem ter que ler texto externo para entender e resolver o problema, a menos que a solução exija várias etapas.
• Verifique se o conteúdo da Ajuda é relevante e útil. Ele não deve ser uma reformulação detalhada da mensagem de erro, deve conter informações úteis que estão além do escopo da mensagem de erro, como maneiras de evitar o problema no futuro. Não forneça um link de Ajuda apenas porque você pode.
• Use links de Ajuda específicos, concisos e relevantes para acessar o conteúdo da Ajuda. Não use botões de comando ou divulgação progressiva para essa finalidade.
• Para mensagens de erro que você não pode tornar específicas e acionáveis, considere fornecer links para o conteúdo da Ajuda online. Ao fazer isso, você pode fornecer aos usuários informações adicionais que podem ser atualizadas após o lançamento do programa.

Para obter mais diretrizes, consulte Ajuda.

Códigos de erro

• Para mensagens de erro que você não pode tornar específicas e acionáveis ou que se beneficiam da Ajuda, considere também fornecer códigos de erro. Os usuários geralmente usam esses códigos de erro para pesquisar informações adicionais na Internet.
• Sempre forneça uma descrição de texto do problema e da solução. Não dependa apenas do código de erro para essa finalidade.

Incorreto:

Neste exemplo, um código de erro é usado como um substituto para um texto de solução.

• Atribua um código de erro exclusivo para cada causa diferente. Isso evita a solução de problemas.
• Escolha códigos de erro facilmente pesquisáveis na Internet. Se você usar códigos de 32 bits, use uma representação hexadecimal com um "0x" à esquerda e caracteres maiúsculos.

Correto:

1234

0xC0001234

Incorreto:

-1

-67113524

• Use Mostrar/Ocultar detalhes para exibir códigos de erro. Frase como Código de erro: <error code>.

Neste exemplo, um código de erro é usado para complementar uma mensagem de erro que pode se beneficiar de mais informações.

Som

• Não acompanhe mensagens de erro com um efeito sonoro ou um bipe. Fazê-lo é chocante e desnecessário.
  • Exceção: Reproduza o efeito sonoro Parada Crítica se o problema for crítico para a operação do computador e o usuário precisar tomar medidas imediatas para evitar consequências graves.

Texto

Geral

• Remova o texto redundante. Procure-o em títulos, main instruções, instruções complementares, links de comando e botões de confirmação. Em geral, deixe o texto completo em instruções e controles interativos e remova qualquer redundância dos outros locais.
• Use explicações centradas no usuário. Descreva o problema em termos de ações ou metas do usuário, não em termos do que o software está insatisfeito. Use o idioma que os usuários de destino entendem e usam. Evite jargões técnicos.

Incorreto:

Correto:

Nesses exemplos, a versão correta fala o idioma do usuário, enquanto a versão incorreta é excessivamente técnica.

• Não use as seguintes palavras:
  • Erro, falha (problema de uso em vez disso)
  • Falha ao (em vez disso, não é possível usar)
  • Ilegal, inválido, inválido (use incorreto em vez disso)
  • Anular, matar, terminar (use stop em vez disso)
  • Catastrófico, fatal (use sério em vez disso)

Esses termos são desnecessários e contrários ao tom encorajador do Windows. Quando usado corretamente, o ícone de erro comunica suficientemente que há um problema.

Incorreto:

Correto:

No exemplo incorreto, os termos "catastrófico" e "falha" são desnecessários.

• Não use frases que culpem o usuário ou impliquem erro do usuário. Evite usar você e seu na frase. Embora a voz ativa seja geralmente preferida, use a voz passiva quando o usuário for o assunto e poderá se sentir culpado pelo erro se a voz ativa tiver sido usada.

Incorreto:

Correto:

O exemplo incorreto culpa o usuário usando a voz ativa.

• Ser específico. Evite palavras vagas, como erro de sintaxe e operação ilegal. Forneça nomes, locais e valores específicos dos objetos envolvidos.

Incorreto:

Arquivo não localizado.

O disco está cheio.

Valor fora do intervalo.

O caractere é inválido.

Dispositivo não disponível.

Esses problemas seriam muito mais fáceis de resolver com nomes, locais e valores específicos.

• Não dê problemas, causas ou soluções possivelmente improváveis na tentativa de ser específico. Não forneça um problema, uma causa ou uma solução, a menos que seja provável que esteja certo. Por exemplo, é melhor dizer que ocorreu um erro desconhecido do que algo que provavelmente será impreciso.
• Evite a palavra "por favor", exceto em situações em que o usuário é solicitado a fazer algo inconveniente (como esperar) ou o software deve blame para a situação.

Correto:

Aguarde enquanto o Windows copia os arquivos para o computador.

• Use a palavra "desculpe" somente em mensagens de erro que resultem em sérios problemas para o usuário (por exemplo, perda de dados ou incapacidade de usar o computador). Não se desculpe se o problema ocorreu durante o funcionamento normal do programa (por exemplo, se o usuário precisar aguardar a conclusão de uma conexão de rede).

Correto:

Lamentamos, mas o Backup da Fabrikam detectou um problema irrecuperável e foi desligado para proteger arquivos em seu computador.

• Consulte os produtos usando seus nomes curtos. Não use nomes completos de produtos ou símbolos de marca registrada. Não inclua o nome da empresa, a menos que os usuários associem o nome da empresa ao produto. Não inclua números de versão do programa.

Incorreto:

Correto:

No exemplo incorreto, nomes de produtos completos e símbolos de marca registrada são usados.

• Use aspas duplas em torno de nomes de objeto. Isso facilita a análise do texto e evita instruções potencialmente embaraçosas.
  • Exceção: Caminhos de arquivo totalmente qualificados, URLs e nomes de domínio não precisam estar entre aspas duplas.

Correto:

Neste exemplo, a mensagem de erro seria confusa se o nome do objeto não estivesse entre aspas.

• Evite iniciar frases com nomes de objeto. Muitas vezes, fazer isso é difícil de analisar.
• Não use pontos de exclamação ou palavras com todas as letras maiúsculas. Pontos de exclamação e letras maiúsculas fazem parecer que você está gritando com o usuário.

Para obter mais diretrizes e exemplos, consulte Estilo e Tom.

Títulos

• Use o título para identificar o comando ou o recurso do qual o erro se originou. Exceções:
  • Se um erro for exibido por muitos comandos diferentes, considere usar o nome do programa.
  • Se esse título for redundante ou confuso com a instrução main, use o nome do programa.
• Não use o título para explicar ou resumir o problema que é a finalidade da instrução main.

Incorreto:

Neste exemplo, o título está sendo usado incorretamente para explicar o problema.

• Use a capitalização no estilo título, sem pontuação final.

Instruções principais

• Use a instrução main para descrever o problema em uma linguagem clara, simples e específica.
• Seja conciso usar apenas uma única frase completa. Pare a instrução main até as informações essenciais. Você pode deixar o assunto implícito se for o programa ou o usuário. Inclua o motivo do problema se você puder fazer isso de forma concisa. Se precisar explicar mais alguma coisa, use uma instrução complementar.

Incorreto:

Neste exemplo, toda a mensagem de erro é colocada na instrução main, dificultando a leitura.

• Seja específico se houver objetos envolvidos, dê seus nomes.
• Evite colocar caminhos de arquivo e URLs completos na instrução main. Em vez disso, use um nome curto (como o nome do arquivo) e coloque o nome completo (como o caminho do arquivo) na instrução complementar. No entanto, você pode colocar um único caminho de arquivo completo ou URL na instrução main se a mensagem de erro de outra forma não precisar de uma instrução complementar.

Neste exemplo, somente o nome do arquivo está na instrução main. O caminho completo está na instrução complementar.

• Não forneça o caminho completo do arquivo e a URL se ele for óbvio no contexto.

Neste exemplo, o usuário está renomeando um arquivo do Windows Explorer. Nesse caso, o caminho completo do arquivo não é necessário porque é óbvio no contexto.

• Use o tempo presente sempre que possível.
• Use a capitalização com estilo de frase.
• Não inclua os períodos finais se a instrução for uma instrução . Se a instrução for uma pergunta, inclua um ponto de interrogação final.

Principais modelos de instrução

Embora não haja regras rígidas para frases, tente usar os seguintes modelos de instrução main sempre que possível:

• [nome da entidade opcional] não pode [executar ação]
• [nome da entidade opcional] não pode [executar ação] porque [motivo]
• [nome da entidade opcional] não pode [executar ação] para "[nome do objeto]"
• [nome da entidade opcional] não pode [executar ação] para "[nome do objeto]" porque [motivo]
• Não há [recurso] suficiente para [executar a ação]
• [Nome da entidade] não tem um [nome do objeto] necessário para [finalidade]
• [Dispositivo ou configuração] está desativado para que [resultados indesejados]
• [Dispositivo ou configuração] não está [disponível | encontrado | ativado | habilitado]
• "[nome do objeto]" não está disponível no momento
• O nome de usuário ou a senha está incorreta
• Você não tem permissão para acessar "[nome do objeto]"
• Você não tem privilégios para [executar a ação]
• [nome do programa] teve um problema sério e deve fechar imediatamente

É claro que faça alterações conforme necessário para que a instrução main seja gramaticalmente correta e esteja em conformidade com as diretrizes de instrução main.

Instruções complementares

• Use a instrução complementar para:
  • Forneça detalhes adicionais sobre o problema.
  • Explicar a causa do problema.
  • Listar as etapas que o usuário pode executar para corrigir o problema.
  • Forneça medidas para evitar que o problema se repita.
• Sempre que possível, proponha uma solução prática e útil para que os usuários possam corrigir o problema. No entanto, verifique se a solução proposta provavelmente resolverá o problema. Não desperdice o tempo dos usuários sugerindo soluções possíveis, mas improváveis.

Incorreto:

Neste exemplo, embora o problema e sua solução recomendada sejam possíveis, eles são muito improváveis.

• Se o problema for um valor incorreto que o usuário inseriu, use a instrução complementar para explicar os valores corretos. Os usuários não devem precisar determinar essas informações de outra fonte.
• Não forneça uma solução se ela puder ser deduzida trivialmente da instrução do problema.

Neste exemplo, nenhuma instrução complementar é necessária; a solução pode ser deduzida trivialmente da instrução de problema.

• Se a solução tiver várias etapas, apresente as etapas na ordem em que elas devem ser concluídas. No entanto, evite soluções de várias etapas porque os usuários têm dificuldade em lembrar mais de duas ou três etapas simples. Se mais etapas forem necessárias, consulte o tópico de Ajuda apropriado.
• Mantenha as instruções complementares concisas. Forneça apenas o que os usuários precisam saber. Omita detalhes desnecessários. Aponte para um máximo de três frases de comprimento moderado.
• Para evitar erros enquanto os usuários executam instruções, coloque os resultados antes da ação.

Correto:

Para reiniciar o Windows, clique em OK.

Incorreto:

Clique em OK para reiniciar o Windows.

No exemplo incorreto, é mais provável que os usuários cliquem em OK por acidente.

• Não recomende entrar em contato com um administrador, a menos que isso esteja entre as soluções mais prováveis para o problema. Reserve essas soluções para problemas que realmente só podem ser resolvidos por um administrador.

Incorreto:

Neste exemplo, provavelmente o problema é com a conexão de rede do usuário, portanto, não vale a pena entrar em contato com um administrador.

• Não é recomendável entrar em contato com o suporte técnico. A opção de entrar em contato com o suporte técnico para resolver um problema está sempre disponível e não precisa ser promovida por meio de mensagens de erro. Em vez disso, concentre-se em escrever mensagens de erro úteis para que os usuários possam resolver problemas sem entrar em contato com o suporte técnico.

Incorreto:

Neste exemplo, a mensagem de erro recomenda incorretamente entrar em contato com o suporte técnico.

• Use frases completas, maiúsculas no estilo de frase e pontuação final.

Botões de confirmação

• Se a mensagem de erro fornecer botões de comando ou links de comando que resolvem o problema, siga suas respectivas diretrizes em Caixas de Diálogo.
• Se o programa precisar terminar como resultado do erro, forneça um botão Sair do programa. Para evitar confusão, não use Fechar para essa finalidade.
• Caso contrário, forneça um botão Fechar. Não use OK para mensagens de erro, pois essa redação implica que os problemas estão ok.
  • Exceção: Use OK se o mecanismo de relatório de erros tiver rótulos fixos (como com a API MessageBox).)

Documentação

Ao se referir a erros:

• Consulte os erros por meio de suas instruções de main. Se a instrução main for longa ou detalhada, resuma-a.
• Se necessário, você pode se referir a uma caixa de diálogo de mensagem de erro como uma mensagem. Consulte como uma mensagem de erro somente na programação e em outras documentações técnicas.
• Quando possível, formate o texto usando negrito. Caso contrário, coloque o texto entre aspas somente se necessário para evitar confusão.

Exemplo: Se você receber um Disco de CD não há disco cd na mensagem de unidade , insira um novo disco de CD na unidade e tente novamente.