Share via


Lista de verificação da experiência do usuário para aplicativos da área de trabalho

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.

Aqui está uma coleção de algumas das diretrizes importantes no Guia da Experiência do Usuário. Você pode usar isso como uma lista de verificação para garantir que a interface do usuário do programa obtenha esses itens importantes corretamente.

Windows

  • Suporte à resolução mínima efetiva do Windows de 800 x 600 pixels. Para interfaces de usuário críticas (UIs) que devem funcionar no modo de segurança, dê suporte a uma resolução efetiva de 640 x 480 pixels. Lembre-se de considerar o espaço usado pela barra de tarefas reservando 48 pixels relativos verticais para janelas exibidas com a barra de tarefas.
  • Otimize layouts de janela redimensionáveis para uma resolução efetiva de 1024 x 768 pixels. Redimensione automaticamente essas janelas para resoluções de tela inferiores de uma forma que ainda esteja funcional.
  • Teste suas janelas em 96 pontos por polegada (dpi) (a 800 x 600 pixels), 120 dpi (a 1024 x 768 pixels) e 144 dpi (a 1200 x 900 pixels). Verifique se há problemas de layout, como recorte de controles, texto e janelas e alongamento de ícones e bitmaps.
  • Para programas com cenários de toque e uso móvel, otimize para 120 dpi. As telas de alto dpi atualmente são predominantes em computadores móveis e de toque.
  • Se uma janela for de propriedade, exiba-a inicialmente "centralizada" na parte superior da janela do proprietário. Nunca por baixo. Para exibição subsequente, considere exibi-lo em seu último local (em relação à janela do proprietário) se isso provavelmente for mais conveniente.
  • Se uma janela for contextual, sempre a exiba perto do objeto do qual foi iniciada. No entanto, coloque-o fora do caminho (preferencialmente deslocado para baixo e para a direita) para que o objeto não seja coberto pela janela.

Layout

  • Controles de tamanho e painéis dentro de uma janela para corresponder ao conteúdo típico. Evite texto truncado e suas reticências associadas. Os usuários nunca devem ter que interagir com uma janela para exibir seu conteúdo típico — reserve redimensionamento e rolagem para conteúdo extraordinariamente grande. Especificamente marcar:
    • Tamanhos de controle. Controles de tamanho para seu conteúdo típico, tornando os controles mais amplos, mais altos ou de várias linhas, se necessário. Controles de tamanho para eliminar ou reduzir a rolagem em janelas que têm muito espaço disponível. Além disso, nunca deve haver rótulos truncados ou texto truncado dentro de janelas que tenham muito espaço disponível. No entanto, para facilitar a leitura do texto, considere limitar as larguras de linha a 65 caracteres.
    • Larguras de coluna. Verifique se as colunas de exibição de lista têm um dimensionamento padrão, mínimo e máximo adequados. Escolha as larguras de coluna padrão das exibições de lista que não resultam em texto truncado, especialmente se houver espaço disponível no modo de exibição de lista.
    • Equilíbrio de layout. O layout de uma janela deve ser aproximadamente equilibrado. Se o layout ficar pesado para a esquerda, considere tornar os controles mais largos e mover alguns controles mais para a direita.
    • Redimensionamento de layout. Quando uma janela for redimensionável e os dados estiverem truncados, verifique se os tamanhos de janela maiores mostram mais dados. Quando os dados são truncados, os usuários esperam redimensionar janelas para mostrar mais informações.
  • Defina um tamanho mínimo de janela se houver um tamanho abaixo do qual o conteúdo não será mais utilizável. Para controles redimensionáveis, defina tamanhos mínimos de elemento redimensionáveis para seus menores tamanhos funcionais, como larguras de coluna funcional mínimas em exibições de lista.

Texto

  • Use termos comuns e conversacionais quando puder. Concentre-se nas metas do usuário, não na tecnologia. Isso é especialmente eficaz se você estiver explicando um conceito técnico complexo ou uma ação. Imagine-se olhando por cima do ombro do usuário e explicando como realizar a tarefa.
  • Seja educado, solidário e encorajador. O usuário nunca deve se sentir condescendente, culpado ou intimidado.
  • Remova o texto redundante. Procure texto redundante em títulos de janela, instruções main, instruções complementares, áreas de conteúdo, links de comando e botões de confirmação. Em geral, deixe o texto completo em main instruções e controles interativos e remova qualquer redundância dos outros locais.
  • Use maiúsculas no estilo de título para títulos e maiúsculas no estilo de frase para todos os outros elementos da interface do usuário. Fazer isso é mais apropriado para o tom do Windows.
    • Exceção: Para aplicativos herdados, você pode usar a capitalização no estilo título para botões de comando, menus e títulos de coluna, se necessário, para evitar a combinação de estilos de capitalização.
  • Para nomes de recursos e tecnologias, seja conservador no uso de maiúsculas. Normalmente, somente os principais componentes devem ser colocados em maiúsculas (usando maiúsculas no estilo de título).
  • Para nomes de recursos e tecnologias, seja consistente em uso de maiúsculas. Se o nome aparecer mais de uma vez em uma tela da interface do usuário, ele sempre deverá aparecer da mesma maneira. Da mesma forma, em todas as telas de interface do usuário do programa, o nome deve ser apresentado consistentemente.
  • Não coloque em maiúscula os nomes dos elementos genéricos da interface do usuário, como barra de ferramentas, menu, barra de rolagem, botão e ícone.
    • Exceções: Barra de endereços, Barra de links, faixa de opções.
  • Não use todas as letras maiúsculas para teclas de teclado. Em vez disso, siga as maiúsculas usadas pelos teclados padrão ou minúsculas se a tecla não estiver rotulada no teclado.
  • Reticências significam incompleto. Use reticências no texto da interface do usuário da seguinte maneira:
    • comandos. Indique que um comando precisa de informações adicionais. Não use reticências sempre que uma ação exibir outra janela, somente quando informações adicionais forem necessárias. Os comandos cujo verbo implícito é mostrar outra janela não fazem reticências, como Avançado, Ajuda, Opções, Propriedades ou Configurações.
    • Dados. Indique que o texto está truncado.
    • Rótulos. Indique que uma tarefa está em andamento (por exemplo, "Pesquisando...").

Ponta: O texto truncado em uma janela ou página com espaço não utilizado indica um layout ruim ou um tamanho de janela padrão muito pequeno. Busque layouts e tamanhos de janela padrão que eliminem ou reduzam a quantidade de texto truncado. Veja Layout para obter mais informações.

  • Não use texto azul que não seja um link, pois os usuários podem assumir que ele é um link. Use negrito ou um tom de cinza em que, de outra forma, você usaria texto colorido.
  • Use negrito com moderação para chamar a atenção para o texto que os usuários devem ler.
  • Use a instrução main para explicar concisamente o que os usuários devem fazer em uma determinada janela ou página. Boas instruções de main comunicam o objetivo do usuário em vez de se concentrar apenas na manipulação da interface do usuário.
  • Expresse a instrução main na forma de uma direção imperativa ou uma pergunta específica.
  • Não coloque períodos no final dos rótulos de controle ou main instruções.
  • Use um espaço entre frases. Não dois.

Controles

  • Geral
    • Rotule cada controle ou grupo de controles. Exceções:
      • Caixas de texto e listas suspensas podem ser rotuladas usando prompts.
      • Os controles subordinados usam o rótulo do controle associado. Controles de rotação são sempre controles subordinados.
    • Para todos os controles, selecione o valor mais seguro (para evitar a perda de dados ou acesso ao sistema), o valor mais seguro por padrão. Se segurança e segurança não forem fatores, selecione o valor mais provável ou conveniente.
    • Prefira controles restritos. Use controles restritos, como listas e controles deslizantes sempre que possível, em vez de controles irrestritos, como caixas de texto, para reduzir a necessidade de entrada de texto.
    • Reconsidere os controles desabilitados. Controles desabilitados podem ser difíceis de usar porque os usuários literalmente precisam deduzir por que estão desabilitados. Desabilite um controle quando os usuários esperam que ele seja aplicado e eles podem facilmente deduzir por que o controle está desabilitado. Remova o controle quando não houver nenhuma maneira de os usuários habilitá-lo ou eles não esperam que ele seja aplicado ou deixe-o habilitado, mas forneça uma mensagem de erro quando ele for usado incorretamente.
      • Ponta: Se você não tiver certeza se deve desabilitar um controle ou fornecer uma mensagem de erro, comece redigindo a mensagem de erro que você pode fornecer. Se a mensagem de erro contiver informações úteis que os usuários de destino provavelmente não deduzem rapidamente, deixe o controle habilitado e forneça o erro. Caso contrário, desabilite o controle.
  • Botões de comando
    • Prefira rótulos específicos em vez de genéricos. O ideal é que os usuários não precisem ler mais nada para entender o rótulo. Os usuários têm muito mais probabilidade de ler rótulos de botão de comando do que texto estático.
      • Exceção: Não renomeie o botão Cancelar se o significado de cancelar for inequívoco. Os usuários não devem ter que ler todos os botões para determinar qual botão cancela uma ação. No entanto, renomeie Cancelar se não estiver claro qual ação está sendo cancelada, como quando há várias ações pendentes.
    • Ao fazer uma pergunta, use rótulos que correspondam à pergunta. Por exemplo, forneça respostas Sim e Não a uma pergunta sim ou não.
    • Não use os botões Aplicar em caixas de diálogo que não são folhas de propriedades ou itens do painel de controle. O botão Aplicar significa aplicar as alterações pendentes, mas deixe a janela aberta. Isso permite que os usuários avaliem as alterações antes de fechar a janela. No entanto, apenas folhas de propriedades e itens do painel de controle têm essa necessidade.
    • Rotule um botão Cancelar se cancelar retornar o ambiente ao estado anterior (não deixando nenhum efeito colateral); caso contrário, rotule o botão Fechar (se a operação estiver concluída) ou Parar (se a operação estiver em andamento) para indicar que ele deixa o estado atual alterado intacto.
  • Links de comando
    • Sempre apresente links de comando em um conjunto de dois ou mais. Logicamente, não há razão para fazer uma pergunta que tenha apenas uma resposta.
    • Forneça um botão Cancelar explícito. Não use um link de comando para essa finalidade. Muitas vezes, os usuários percebem que não querem executar uma tarefa. Usar um link de comando para cancelar exigiria que os usuários lessem todos os links de comando cuidadosamente para determinar qual deles significa cancelar. Ter um botão Cancelar explícito permite que os usuários cancelem uma tarefa com eficiência.
    • Se fornecer um botão Cancelar explícito deixar um único link de comando, forneça um link de comando para cancelar e um botão Cancelar. Isso deixa claro que os usuários têm uma escolha. Expresse este link de comando em termos de como ele difere da primeira resposta, em vez de apenas "Cancelar" ou alguma variação.
  • Caixas de marcar "Não mostre este <item> novamente"
    • Considere usar uma opção "Não mostrar este <item> novamente" para permitir que os usuários suprimam uma caixa de diálogo recorrente, somente se não houver uma alternativa melhor. É melhor sempre mostrar a caixa de diálogo se os usuários realmente precisarem dela ou simplesmente eliminá-la se não precisarem.
    • Substitua <item> pelo item específico. Por exemplo, não mostre este lembrete novamente. Ao fazer referência a uma caixa de diálogo em geral, use Não mostrar essa mensagem novamente.
    • Indique claramente quando a entrada do usuário será usada para valores padrão futuros adicionando a seguinte frase sob a opção : Suas seleções serão usadas por padrão no futuro.
    • Não selecione a opção por padrão. Se a caixa de diálogo realmente deve ser exibida apenas uma vez, faça isso sem perguntar. Não use essa opção como desculpa para irritar os usuários. Verifique se o comportamento padrão não é irritante.
    • Se os usuários selecionarem a opção e clicarem em Cancelar, essa opção terá efeito. Essa configuração é uma meta-opção, portanto, ela não segue o comportamento padrão cancelar de não deixar nenhum efeito colateral. Observe que, se os usuários não quiserem ver a caixa de diálogo no futuro, provavelmente também desejam cancelá-la.
  • Links
    • Não atribua umachave de acesso. Os links são acessados usando a tecla Tab.
    • Não adicione "Clique" ou "Clique aqui" ao texto do link. Não é necessário porque um link implica clicar.
  • Dicas de ferramentas
    • Use dicas de ferramenta para fornecer rótulos para controles sem rótulo. Você não precisa dar dicas de ferramentas de controles rotulados simplesmente para fins de consistência.
    • As dicas de ferramenta também podem fornecer mais detalhes para botões rotulados da barra de ferramentas se isso for útil. Não repita ou dê uma reformulação do que já está no rótulo.
    • Evite cobrir o objeto com o qual o usuário está prestes a exibir ou interagir. Sempre coloque a dica na lateral do objeto, mesmo que isso exija separação entre o ponteiro e a ponta. Alguma separação não é um problema, desde que a relação entre o objeto e sua dica seja clara.
      • Exceção: Dicas de ferramenta de nome completo usadas em listas e árvores.
    • Para coleções de itens, evite cobrir o próximo objeto com o qual o usuário provavelmente exibirá ou interagirá. Para itens organizados horizontalmente, evite colocar dicas à direita; para itens organizados verticalmente, evite colocar dicas abaixo.
  • Divulgação progressiva
    • Use mais/menos botões de divulgação progressiva para ocultar opções, comandos e detalhes avançados ou raramente usados que os usuários normalmente não precisam. Não oculte itens comumente usados, pois os usuários podem não encontrá-los. Mas verifique se o que está oculto tem valor.
    • Se a superfície sempre exibir algumas opções, comandos ou detalhes, use os seguintes pares de rótulos:
      • Mais/Menos opções. Use para opções ou uma combinação de opções, comandos e detalhes.
      • Mais/Menos comandos. Use apenas para comandos.
      • Mais/Menos detalhes. Use apenas para obter informações.
      • Mais/Menos nome> de <objeto. Use para outros tipos de objeto, como pastas.
    • Caso contrário:
      • Mostrar/Ocultar opções. Use para opções ou uma combinação de opções, comandos e detalhes.
      • Mostrar/Ocultar comandos. Use apenas para comandos.
      • Mostrar/Ocultar detalhes. Use apenas para obter informações.
      • Mostrar/Ocultar nome> do <objeto. Use para outros tipos de objeto, como pastas.
  • Barras de progresso
    • Use barras de progresso determinantes para operações que exigem uma quantidade limitada de tempo, mesmo que esse período não possa ser previsto com precisão. Barras de progresso indeterminados mostram que o progresso está sendo feito, mas não fornecem outras informações. Não escolha uma barra de progresso indeterminado com base apenas na possível falta de precisão.
    • Forneça uma estimativa de tempo restante se você puder fazer isso com precisão. As estimativas restantes de tempo que são precisas são úteis, mas estimativas que estão muito fora da marca ou saltam significativamente não são úteis. Talvez seja necessário executar algum processamento antes de fornecer estimativas precisas. Nesse caso, não exiba estimativas potencialmente imprecisas durante esse período inicial.
    • Não reinicie o progresso. Uma barra de progresso perderá seu valor se for reiniciada (talvez porque uma etapa na operação é concluída) porque os usuários não têm como saber quando a operação será concluída. Em vez disso, tenha todas as etapas na operação compartilhando uma parte do progresso e que a barra de progresso vá para a conclusão uma vez.
    • Forneça detalhes úteis de progresso. Forneça informações adicionais de progresso, mas somente se os usuários puderem fazer algo com ela. Verifique se o texto é exibido por tempo suficiente para que os usuários possam lê-lo.
    • Não combine uma barra de progresso com um ponteiro ocupado. Use um ou outro, mas não ambos ao mesmo tempo.
  • Solicitações
    • Use um prompt quando o espaço na tela estiver tão premium que o uso de um rótulo ou instrução é indesejável, como em uma barra de ferramentas.
    • O prompt é principalmente para identificar a finalidade da caixa de texto ou caixa de combinação de forma compacta. Não deve ser uma informação crucial que o usuário precisa ver ao usar o controle .
    • O texto do prompt não deve ser confundido com texto real. Para fazer isso:
      • Desenhe o texto do prompt em cinza itálico e o texto de entrada real em preto romano.
      • O texto do prompt não deve ser editável e deve desaparecer depois que os usuários clicarem ou clicarem na caixa de texto.
        • Exceção: Se a caixa de texto tiver o foco de entrada padrão, o prompt será exibido e desaparecerá quando o usuário começar a digitar.
    • Não use pontuação final ou reticências.
  • Notificações
    • Use notificações para eventos que não estão relacionados à atividade do usuário atual, não exigem ação imediata do usuário e os usuários podem ignorar livremente.
    • Não abuse das notificações:
      • Use notificações somente se precisar. Ao exibir uma notificação, você está potencialmente interrompendo os usuários ou até mesmo incomodando-os. Verifique se a interrupção é justificada.
      • Use notificações para eventos ou situações não críticas que não exigem ação imediata do usuário. Para eventos ou situações críticas que exigem ação imediata do usuário, use um elemento de interface do usuário alternativo (como uma caixa de diálogo modal).
      • Não use notificações para anúncios de recursos!

Keyboard

  • Atribua o foco de entrada inicial ao controle com o qual os usuários têm maior probabilidade de interagir primeiro, que geralmente é o primeiro controle interativo. Se o primeiro controle interativo não for uma boa opção, considere alterar o layout da janela.
  • Atribua paradas de guias a todos os controles interativos, incluindo caixas de edição somente leitura. Exceções:
    • Conjuntos de grupos de controles relacionados que se comportam como um único controle, como botões de opção. Esses grupos têm uma única parada de tabulação.
    • Contém corretamente grupos para que as teclas de direção reciclem para frente e para trás dentro do grupo e permaneçam dentro do grupo.
  • A ordem de tabulação deve fluir da esquerda para a direita, de cima para baixo. Em geral, a ordem de tabulação deve seguir a ordem de leitura. Considere fazer exceções para controles comumente usados colocando-os anteriormente na ordem de tabulação. Tab deve percorrer todas as paradas de tabulação em ambas as direções sem parar. Em um grupo, a ordem de tabulação deve estar em ordem sequencial, sem exceções.
  • Em uma parada de tabulação, a ordem da tecla de direção deve fluir da esquerda para a direita, de cima para baixo, sem exceções. As teclas de direção devem percorrer todos os itens em ambas as direções sem parar.
  • Apresente os botões de confirmação na seguinte ordem:
    • OK/[Faça]/Sim
    • [Não faça]/Não
    • Cancelar
    • Aplicar (se presente)

em que [Faça isso] e [Não faça isso] são respostas específicas à instrução main.

  • Não confunda chaves de acesso com teclas de atalho. Embora as teclas de acesso e as teclas de atalho forneçam acesso de teclado à interface do usuário, elas têm diferentes finalidades e diretrizes.
  • Sempre que possível, atribua chaves de acesso exclusivas a todos os controles interativos ou seus rótulos.Caixas de texto somente leitura são controles interativos (porque os usuários podem rolar e copiar texto), portanto, eles se beneficiam das chaves de acesso. Não atribua chaves de acesso a:
    • Botões OK, Cancelar e Fechar. Enter e Esc são usados para suas chaves de acesso. No entanto, sempre atribua uma chave de acesso a um controle que significa OK ou Cancelar, mas tem um rótulo diferente.
  • Atribua teclas de atalho aos comandos mais usados. Programas e recursos usados com pouca frequência não precisam de teclas de atalho porque os usuários podem usar chaves de acesso.
  • Não torne uma tecla de atalho a única maneira de executar uma tarefa. Os usuários também devem ser capazes de usar o mouse ou o teclado com teclas tab, seta e acesso.
  • Não atribua significados diferentes a teclas de atalho conhecidas. Como são memorizados, significados inconsistentes para atalhos conhecidos são frustrantes e propensos a erros.
  • Não tente atribuir teclas de atalho de programa em todo o sistema. As teclas de atalho do programa terão efeito somente quando o programa tiver o foco de entrada.

Mouse

  • Nunca exija que os usuários cliquem em um objeto para determinar se ele é clicável. Os usuários devem ser capazes de determinar a capacidade de clicar apenas pela inspeção visual.
    • A interface do usuário primária (como botões de confirmação) deve ter uma funcionalidade de clique estático. Os usuários não devem precisar passar o mouse para descobrir a interface do usuário primária.
    • A interface do usuário secundária (como comandos secundários ou controles de divulgação progressiva) pode exibir sua acessibilidade de clique ao passar o mouse.
    • Os links de texto devem sugerir estaticamente o texto do link e, em seguida, exibir sua acessibilidade de clique (sublinhado ou outra alteração de apresentação, com ponteiro de mão) ao passar o mouse.
    • Os links gráficos exibem apenas um ponteiro de mão ao passar o mouse.
  • Use o ponteiro mão (ou "link select") somente para links de texto e gráfico. Caso contrário, os usuários teriam que clicar em objetos para determinar se eles são links.

Caixas de diálogo

  • As caixas de diálogo modais exigem interação, portanto, use-as para coisas às quais os usuários devem responder antes de continuar com a tarefa. Verifique se a interrupção é justificada, como para tarefas pontuais críticas ou pouco frequentes que exigem conclusão. Caso contrário, considere alternativas de modelagem.
  • As caixas de diálogo Modeless não exigem interação, portanto, use-as quando os usuários precisarem alternar entre uma caixa de diálogo e a janela do proprietário. Eles são mais bem usados para tarefas frequentes, repetitivas ou contínuas. No entanto, faixas de opções, barras de ferramentas e janelas de paleta geralmente são alternativas melhores.

Folhas de propriedade

  • Verifique se as propriedades são necessárias. Não sobrecarregue suas páginas de propriedades com propriedades desnecessárias apenas para evitar tomar decisões difíceis de design.
  • Apresente propriedades em termos de metas do usuário em vez de tecnologia. Só porque uma propriedade configura uma tecnologia específica não significa que você deve apresentar a propriedade em termos dessa tecnologia.
    • Se você precisar apresentar configurações em termos de tecnologia (talvez porque os usuários reconhecem o nome da tecnologia), inclua uma breve descrição do benefício do usuário.
  • Use rótulos de guia específicos e significativos. Evite rótulos de guia genéricos que possam ser aplicados a qualquer guia, como Geral, Avançado ou Configurações.
  • Evite páginas gerais. Você não precisa ter uma página Geral. Use uma página Geral somente se:
    • As propriedades se aplicam a várias tarefas e são significativas para a maioria dos usuários. Não coloque propriedades especializadas ou avançadas em uma página Geral, mas você pode torná-las acessíveis por meio de um botão de comando na página Geral.
    • As propriedades não se encaixam em uma categoria mais específica. Se o fizerem, use esse nome para a página.
  • Evite páginas avançadas. Use uma página Avançada somente se:
    • As propriedades se aplicam a tarefas incomuns e são significativas principalmente para usuários avançados.
    • As propriedades não se encaixam em uma categoria mais específica. Se o fizerem, use esse nome para a página.
  • Não use guias se uma janela de propriedade tiver apenas uma única guia e não for extensível. Em vez disso, use uma caixa de diálogo regular com OK, Cancelar e um botão Aplicar opcional. No entanto, janelas de propriedades extensíveis (que podem ser estendidas por terceiros) devem usar guias.

Assistentes

  • Considere alternativas leves primeiro, como caixas de diálogo, painéis de tarefas ou páginas simples. Os assistentes são uma interface do usuário pesada, mais usada para tarefas de várias etapas e executadas com pouca frequência. Você não precisa usar assistentes. Você pode fornecer informações úteis e assistência em qualquer interface do usuário.
  • Use Avançar somente ao avançar para a próxima página sem compromisso. Avançar para a próxima página é considerado um compromisso quando seu efeito não pode ser desfeito clicando em Voltar ou Cancelar.
  • Use Voltar somente para corrigir erros. Além de corrigir erros, os usuários não devem precisar clicar em Voltar para progredir em uma tarefa.
  • Quando os usuários estiverem se comprometendo com uma tarefa, use um botão de confirmação que seja uma resposta específica à instrução main (por exemplo, Imprimir, Conectar ou Iniciar). Não use rótulos genéricos como Avançar (o que não implica compromisso) ou Concluir (o que não é específico) para confirmar uma tarefa. Os rótulos nesses botões de confirmação devem fazer sentido por conta própria. Sempre inicie rótulos de botão de confirmação com um verbo. Exceções:
    • Use Concluir quando as respostas específicas ainda forem genéricas, como Salvar, Selecionar, Escolher ou Obter.
    • Use Concluir para alterar uma configuração específica ou uma coleção de configurações.
  • Use links de comando apenas para opções, não para compromissos. Botões de confirmação específicos indicam compromisso muito melhor do que links de comando em um assistente.
  • Ao usar links de comando, oculte o botão Avançar, mas deixe o botão Cancelar.
  • Use Fechar para Follow-Up e Páginas de conclusão. Não use Cancelar porque fechar a janela não abandonará nenhuma alteração ou ações feitas neste momento. Não use Concluído porque não é um verbo imperativo.
  • Não use "assistente" em nomes de assistente. Por exemplo, use "Conectar-se a uma rede" em vez de "Assistente de Configuração de Rede". No entanto, é aceitável se referir aos assistentes como assistentes. Por exemplo: "Se você estiver configurando uma rede pela primeira vez, poderá obter ajuda usando o assistente Conectar-se a uma Rede".
  • Preservar seleções de usuário por meio da navegação. Por exemplo, se o usuário fizer alterações, clicar em Voltar e, em seguida, Avançar, essas alterações deverão ser preservadas. Os usuários não esperam ter que inserir novamente as alterações, a menos que tenham escolhido explicitamente limpá-las.

Páginas do Assistente

  • Concentre-se na tomada de decisões eficiente. Reduza o número de páginas para se concentrar no essencial. Consolide as páginas relacionadas e tire páginas opcionais do fluxo de main. Fazer com que os usuários cliquem em Avançar completamente por meio do assistente pode parecer uma boa experiência no início, mas se os usuários nunca precisarem alterar os padrões, as páginas provavelmente serão desnecessárias.
  • Não use páginas de boas-vindas– torne a primeira página funcional sempre que possível. Use uma página de Introdução opcional somente quando:
    • O assistente tem pré-requisitos necessários para concluir o assistente com êxito.
    • Os usuários podem não entender a finalidade do assistente com base em sua primeira página de Escolha e não há espaço para mais explicações.
    • A instrução main para Introdução páginas é "Antes de começar:".
  • Em páginas nas quais os usuários são solicitados a fazer escolhas, otimize para os casos mais prováveis. Esses tipos de páginas devem apresentar opções reais, não apenas instruções.
    • Se você não usar uma página Introdução, explique a finalidade do assistente na parte superior da primeira página de opções.
  • Use Páginas de confirmação para deixar claro quando os usuários estão se comprometendo com a tarefa. Normalmente, a página Confirmar é a última página de opções e o botão Avançar é rotulado novamente para indicar a tarefa que está sendo confirmada.
    • Não use páginas resumo que simplesmente resumem as seleções anteriores do usuário, a menos que a tarefa seja arriscada (envolvendo segurança ou perda de tempo ou dinheiro) ou haja uma boa chance de que os usuários não entendam suas seleções e precisem revisá-las.
  • Não use páginas de parabéns que não fazem nada além de encerrar o assistente. Se os resultados do assistente forem claramente aparentes para os usuários, basta fechar o assistente no botão de confirmação final.
    • Use Follow-Up páginas quando houver tarefas relacionadas que os usuários provavelmente farão como acompanhamento. Evite tarefas de acompanhamento familiares, como "Enviar uma mensagem de email".
    • Use páginas de conclusão somente quando os resultados não estiverem visíveis e não houver uma maneira melhor de fornecer comentários para a conclusão da tarefa.
    • Os assistentes que têm páginas progresso devem usar uma página conclusão ou Follow-Up página para indicar a conclusão da tarefa. Para tarefas de execução prolongada, feche o assistente na página Confirmar e use notificações para enviar comentários.

Mensagens de erro

  • Não forneça mensagens de erro quando os usuários provavelmente não executarem uma ação ou alterarem seu comportamento como resultado da mensagem. Se não houver nenhuma ação que os usuários possam executar ou se o problema não for significativo, suprima a mensagem de erro.
  • Sempre que possível, proponha uma solução 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.
  • 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.
  • Não use frases que culpem o usuário ou impluram 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.
  • Não use OK para mensagens de erro. Os usuários não veem erros como ok. Se a mensagem de erro não tiver nenhuma ação direta, use Fechar.
  • Não use as seguintes palavras:
    • Erro, falha (problema de uso em vez disso)
    • Falha ao (em vez disso, não é possível usar)
    • Inválido, inválido, inválido (use incorreto ou inválido)
    • Anular, encerrar, terminar (use stop em vez disso)
    • Catastrófico, fatal (use grave em vez disso)

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

  • Não acompanhe mensagens de erro com efeitos sonoros. Fazê-lo é chocante e desnecessário.

Mensagens de aviso

  • Os avisos descrevem uma condição que pode causar um problema no futuro. Avisos não são erros ou perguntas, portanto, não expresse perguntas rotineiras como avisos.
  • Não forneça mensagens de aviso quando os usuários provavelmente não executarem uma ação ou alterarem seu comportamento como resultado da mensagem. Se não houver nenhuma ação que os usuários possam executar ou se a condição não for significativa, suprima a mensagem de aviso.

Confirmações

  • Não use confirmações desnecessárias. Use confirmações somente quando:
    • Há um motivo claro para não prosseguir e uma chance razoável de que, às vezes, os usuários não o prossigam.
    • A ação tem consequências significativas ou não pode ser facilmente desfeita.
    • A ação tem consequências das quais os usuários podem não estar cientes.
    • Continuar com a ação exige que os usuários façam uma escolha que não tenha um padrão adequado.
    • Dado o contexto atual, é provável que os usuários tenham executado uma ação com erro.
  • Confirmações de frase como uma pergunta sim ou não e fornecem respostas sim ou não. Ao contrário de outros tipos de caixas de diálogo, as confirmações são projetadas para impedir que os usuários tomam decisões rápidas. Se os usuários não pensarem na resposta, uma confirmação não terá valor.

Ícones

  • Todos os ícones devem seguir asdiretrizes de ícone de estilo aero. Substitua todos os ícones no estilo XP do Windows.
  • Escolha ícones padrão com base no tipo de mensagem, não na gravidade do problema subjacente:
    • Erro. Um erro ou problema que ocorreu.
    • Aviso. Uma condição que pode causar um problema no futuro.
    • Informações. Informações úteis.

Se um problema combinar diferentes tipos de mensagem, concentre-se no aspecto mais importante em que os usuários precisam agir.

  • Os ícones sempre devem corresponder à instrução main ou a outro texto correspondente.
  • Ícones de erro não são necessários para problemas de entrada de usuário não críticos. No entanto, ícones são necessários para erros in-loco, pois, caso contrário, esses comentários contextuais seriam muito fáceis de ignorar.
  • Não use ícones de aviso para "suavizar" erros não críticos. Erros não são avisos; em vez disso, aplique as diretrizes do ícone de erro.
  • Para caixas de diálogo de perguntas, use ícones de aviso apenas para perguntas com consequências significativas. Não use ícones de aviso para perguntas de rotina.

Ajuda

  • Link para tópicos específicos e relevantes da Ajuda. Não vincule à home page da Ajuda, ao sumário, a uma lista de resultados da pesquisa ou a uma página que seja vinculada apenas a outras páginas. Evite vincular a páginas estruturadas como uma grande lista de perguntas frequentes, pois isso força os usuários a pesquisar aquele que corresponde ao link em que clicaram. Não vincule a tópicos específicos da Ajuda que não são relevantes e úteis para a tarefa em questão. Nunca vincule a páginas vazias.
  • Não coloque links de Ajuda em todas as janelas ou páginas para fins de consistência. Fornecer um link de Ajuda em um só lugar não significa que você precisa fornecê-los em todos os lugares.
  • Sempre que possível, a frase Ajuda vincula o texto em termos da pergunta principal respondida pelo conteúdo da Ajuda. Não use a frase "Saiba mais sobre" ou "Obter ajuda com isso".
  • Use todo o link da Ajuda para o texto do link, não apenas as palavras-chave.
  • Use frases completas.
  • Não use pontuação final ou reticências, exceto para pontos de interrogação.
  • Se o conteúdo da Ajuda estiver online, deixe isso claro no texto do link. Isso ajuda a tornar o resultado dos links previsível.