Mensagens de erro no Windows 7

Nota

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

Observação: diretrizes relacionadas às caixas de diálogo , mensagens de aviso, confirmações, ícones padrão , de notificaçõese de layout de são apresentadas em artigos separados.

Essa é a interface do usuário certa?

Para decidir, considere estas perguntas:

• A interface do usuário (interface do usuário) está apresentando um problema que já ocorreu? Caso contrário, a mensagem não é um erro. Se o usuário estiver sendo alertado sobre uma condição que possa causar um problema no futuro, use uma mensagem de aviso.
• O problema pode ser evitado sem causar confusão? Em vez disso, evite o problema. Por exemplo, use controles restritos a valores válidos em vez de usar controles não treinados que possam 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 suprime 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á-la livremente? Em caso afirmativo, use uma notificação de falha de ação em vez disso.
• O problema está relacionado ao status de uma tarefa em segundo plano dentro de uma janela primária? Nesse caso, considere mostrar o problema usando uma barras de status.
• Os principais usuários de TI são profissionais de TI? Nesse caso, considere usar um mecanismo de comentários alternativo, como arquivo de log entradas 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 a demanda a ser confirmada antes de permitir que o usuário continue.

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

mensagens de erro desnecessárias

Incorreto:

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

O problema: a própria mensagem de erro é 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 relatar erros com os quais os usuários não se importam.

mensagens de erro "Êxito"

Incorreto:

Essa mensagem de erro resultou do usuário optando 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á 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 relatar 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 a respeito. 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 um tratamento de erro ruim.

alternativa recomendada: Criar 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 suplementar é 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: escrever texto de mensagem de erro que os usuários de destino podem 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 sobrecomunizam

Incorreto:

de mensagens extremamente detalhadas

Neste exemplo, a mensagem de erro aparentemente tenta explicar cada etapa de solução de problemas.

o problema: muita informação.

Causa principal: Fornecendo muitos detalhes ou tentando 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á tudo bem a resposta?

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

causa principal: O problema é 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 culpam os usuários

Incorreto:

de caracteres ilegais

Por que fazer os usuários se sentirem um criminoso?

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: Foco 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 sequidoras.

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

alternativa recomendada: Crie e examine suas mensagens de erro 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: 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 significado ou valor para os usuários.

causa principal: programadores usando a interface do usuário normal para fazer mensagens para si mesmos.

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

mensagens de erro mal apresentadas

Incorreto:

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

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

causa principal: Não saber e aplicar as diretrizes de mensagem de erro. Não usar escritores 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 das boas mensagens de erro

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

• Um problema. Afirma 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 é:

• Relevante. A mensagem apresenta um problema com o qual os usuários se preocupam.
• Acionável. 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 de qual código está infeliz.
• Breve. A mensagem é o mais curta possível, mas não é mais curta.
• Claro. 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. 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 de Mensagens 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:

de arquivo

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

Por 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 focando 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 seu programa de satisfazê-las? Se a ação do usuário faz sentido no mundo real, ela também deve 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á sem 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.
• Lida 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 seleção, 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 soltem 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.
• Fazendo as coisas funcionarem. Os usuários são menos propensos a 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, os objetos não podem ser encontrados ou modificados, as tarefas não podem ser concluídas e os 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 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 a razão pela qual um controle está desabilitado não for óbvia? 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 a 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 compondo 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 de tratamento 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 de 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, 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)

A solução de problemas resulta 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 no usuário para determinar a causa específica?

Incorreto:

Bem, qual é? 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 conseguirem mover um arquivo excluído. Para essas causas, a mensagem de erro nem é necessária.

Tratando 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 na frente sobre a falta de informações do que apresentar problemas, causas ou soluções que possam 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 na frente 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 do Windows Internet Explorer:

• 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 Windows Internet Explorer não está configurado para carregar controles ActiveX não assinados" 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ção. "Você configurou o Windows Internet Explorer para bloquear controles ActiveX não assinados." (Formulado como uma declaração de fato.)

Para determinar o tipo de mensagem apropriado, concentre-se no aspecto mais importante do problema em que os usuários precisam saber 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 principal ou outro texto correspondente com base nesse foco e escolha um ícone ( padrão ou não) que corresponda ao texto. O texto de instrução principal 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:

• In-loco
• 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 ao uso de 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.

Evite de comunicação excessiva

Geralmente, usuários não lêem, eles 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 itens essenciais 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 mais um 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:

de mensagens detalhadas

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 pirâmide invertido de apresentação.

Para obter mais diretrizes e exemplos sobre o excesso de comunicação, consulte de 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 oferece 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. Crie 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:

Etiqueta	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 de sistema podem ser resolvidos pelo usuário: Problemas de dispositivo podem ser resolvidos ativando o dispositivo, reconectando o dispositivo e inserindo mídia. Problemas de rede podem ser resolvidos verificando a conexão de rede física e executando diagnóstico e reparo de rede. Problemas de 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.	de arquivo 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 na execução de 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 tempo incorreto. Neste exemplo, a entrada do usuário não está no formato correto.

Diretrizes

Apresentação

• Usar 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 principal 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 sem restrições é usada para entrada restrita. Em vez disso, use um controle deslizante.

• Usar o tratamento de erros de modelagem (erros in-loco ou balões) para problemas contextuais de entrada do usuário.
• Usar balões para problemas de entrada de usuário de ponto único não críticos 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. Exibir apenas um único balão de cada 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.

de caractere incorreto

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

• Usar erros in-loco para detecção de erros atrasada, geralmente os 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. Erros in-loco não desaparecem, a menos que o usuário se confirme e nenhum outro erro seja encontrado.

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

• Usar o tratamento de erros modais (caixas de diálogo de tarefa ou caixas 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 para 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. Sempre deve ser ó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: Limpar senha incorreta e caixas de texto PIN porque os usuários não podem corrigir a entrada mascarada efetivamente.

Solucionando 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 da 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 ou balão modal, 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.

    

    

    Nesses 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 tenha um ícone (e não um problema de entrada do usuário), você poderá 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 detalhar 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 de 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 que os usuários o suprimam.

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 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. Não deve ser uma reformulação detalhada da mensagem de erro, em vez disso, ela 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 só 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 Help.

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:

de arquivo

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" e caracteres maiúsculos à esquerda.

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. Fazer isso é chocante e desnecessário.
  • Exceção: Reproduzir o efeito sonoro Parada Crítica se o problema for crítico para a operação do computador e o usuário deverá tomar medidas imediatas para evitar sérias consequências.

Texto

Geral do

• Remova o texto redundante. Procure-o em títulos, instruções principais, 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 (use o problema em vez disso)
  • Falha ao usar (em vez disso, não foi possível usar)
  • Ilegal, inválido, inválido (uso incorreto em vez disso)
  • Anular, matar, terminar (use parar 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 culpam o usuário ou implicam erro do usuário. Evite usar você e o 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:

de logon incorreto

Correto:

de senha incorreta

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

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

Incorreto:

Arquivo não encontrado.

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 em uma tentativa de ser específica. 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 é o culpado pela 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 problemas graves para o usuário (por exemplo, perda de dados ou incapacidade de usar o computador). Não peça desculpas 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. 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 são usados.

• Use aspas duplas em torno de nomes de objeto. Isso facilita a análise do texto e evita declaraçõ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 Style and Tone.

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 principal, use o nome do programa.
• Não use o título para explicar ou resumir o problema essa é a finalidade da instrução principal.

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 principal para descrever o problema em uma linguagem clara, simples e específica.
• Use apenas uma única frase completa. Pare a instrução principal 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 você precisar explicar mais alguma coisa, use uma instrução complementar.

Incorreto:

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

• Ser específico se houver objetos envolvidos, dê seus nomes.
• Evite colocar caminhos de arquivo completos e URLs na instrução principal. 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 principal se a mensagem de erro não precisar de uma instrução complementar.

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

• Não forneça o caminho completo do arquivo e a URL se 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 do contexto.

• Use o tempo presente sempre que possível.
• Use a capitalização no 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.

Modelos de instrução principais

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

• [nome do assunto opcional] não pode [executar ação]
• [nome da entidade opcional] não pode [executar ação] porque [motivo]
• [nome do assunto 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]" está indisponível no momento
• O nome de usuário ou senha está incorreto
• Você não tem permissão para acessar "[nome do objeto]"
• Você não tem privilégio para [executar a ação]
• [nome do programa] teve um problema sério e deve fechar imediatamente

Claro, faça alterações conforme necessário para que a instrução principal seja gramaticalmente correta e esteja em conformidade com as diretrizes de instrução principais.

de instruções complementares

• Use a instrução complementar para:
  • Forneça detalhes adicionais sobre o problema.
  • Explicar a causa do problema.
  • Listar 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 determinar essas informações de outra fonte.
• Não forneça uma solução se ela puder ser deduzida trivialmente da instrução de 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 forem necessárias mais etapas, 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, os usuários são mais propensos a clicar em OK por acidente.

• Não é recomendável 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 na gravação de 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 em 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 ser encerrado como resultado do erro, forneça um botão Sair do programa. Para evitar confusão, não use Close 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: Usar OK se o mecanismo de relatório de erros tiver rótulos fixos (como com a API do MessageBox).)

Documentação

Ao se referir a erros:

• Consulte os erros por sua instrução principal. Se a instrução principal for longa ou detalhada, resumi-la.
• 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 outra documentação técnica.
• 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 Não há disco cd na mensagem de da unidade, insira um novo disco cd na unidade e tente novamente.