Compartilhar via

Lista de verificação de UX para aplicativos de desktop

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á algumas diretrizes importantes do Guia de UX. Você pode usar isso como uma lista de verificação para garantir que a interface do usuário do programa acerte esses itens importantes.

Windows

  • Suporta a resolução efetiva mínima do Windows de 800 x 600 pixels. Para interfaces do usuário (IUs) críticas que devem funcionar no modo de segurança, dê suporte a uma resolução efetiva de 640 x 480 pixels. Certifique-se de levar em conta o espaço usado pela barra de tarefas reservando 48 pixels relativos verticais para as 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 mais baixas de uma forma que ainda seja funcional.
  • Certifique-se de testar suas janelas nos modos de 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 corte de controles, texto e janelas, e esticamento de ícones e bitmaps.
  • Para programas com cenários de toque e uso móvel, otimize para 120 dpi. Atualmente, as telas de alto dpi são predominantes em PCs móveis e sensíveis ao toque.
  • Se uma janela for de propriedade, exiba-a inicialmente "centralizada" na parte superior da janela do proprietário. Nunca embaixo. Para exibições subsequentes, considere apresentá-lo em sua última posição (em relação à janela do proprietário), caso isso seja mais conveniente.
  • Se uma janela for contextual, sempre exiba-a perto do objeto com base no qual ela foi iniciada. No entanto, coloque-a fora do caminho (de preferência deslocada para baixo e para a direita) para que o objeto não seja coberto pela janela.

Layout

  • Dimensione os controles e painéis dentro de uma janela para corresponder ao seu 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 o redimensionamento e a rolagem para conteúdo extraordinariamente grande. Verifique o seguinte:
    • Tamanhos dos controles. Dimensione os controles conforme seu conteúdo típico, tornando os controles mais largos, mais altos ou com várias linhas, se necessário. Dimensione os controles 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 em 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 da coluna. Certifique-se de que as colunas de exibição em lista tenham tamanhos padrão, mínimo e máximo adequados. Escolha larguras de coluna padrão em modos de exibição em lista que não resultem em texto truncado, especialmente se houver espaço disponível no modo de exibição em lista.
    • Equilíbrio de layout. O layout de uma janela deve parecer mais ou menos equilibrado. Se o layout parecer pesado para a esquerda, considere tornar os controles mais amplos e mover alguns controles mais para a direita.
    • Redimensionamento do layout. Quando uma janela é redimensionável e os dados estão truncados, certifique-se de que tamanhos de janela maiores mostrem mais dados. Quando os dados estão truncados, os usuários esperam que as janelas de redimensionamento mostrem mais informações.
  • Defina um tamanho mínimo de janela se houver um tamanho abaixo do qual o conteúdo não seja mais utilizável. Para controles redimensionáveis, defina tamanhos mínimos de elementos redimensionáveis para os menores tamanhos funcionais, como larguras mínimas de coluna funcional em exibições em lista.

Texto

  • Use termos comuns de conversação quando puder. Concentre-se nos objetivos do usuário, não na tecnologia. Isso é especialmente eficaz se você estiver explicando um conceito ou ação técnica complexa. 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 texto redundante. Procure texto redundante em títulos de janela, instruções principais, instruções complementares, áreas de conteúdo, links de comando e botões de confirmação. Em geral, deixe o texto completo nas instruções principais e controles interativos e remova qualquer redundância dos outros locais.
  • Use capitalização em estilo de título para títulos e capitalização em estilo de frase para todos os outros elementos da interface do usuário. Fazer isso é mais apropriado ao tom do Windows.
    • Exceção: Para aplicativos legados, você pode usar capitalização no estilo de título para botões de comando, menus e cabeçalhos de coluna, se necessário, para evitar misturar estilos de capitalização.
  • Para nomes de recursos e tecnologia, seja conservador no uso de maiúsculas e minúsculas. Geralmente, apenas os componentes principais devem ser escritos com capitalização no estilo título.
  • Para nomes de recursos e tecnologia, seja consistente no 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 use maiúsculas nos nomes de 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, barra de ferramentas.
  • Não use somente letras maiúsculas para teclas de teclado. Em vez disso, siga o uso de maiúsculas usado pelos teclados padrão ou em minúsculas caso a tecla não esteja rotulada no teclado.
  • Reticências significam incompletude. 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 recebem 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...").

Dica: 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. Procure 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 presumir que é um link. Use negrito ou um tom de cinza onde normalmente 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 principal para explicar concisamente o que os usuários devem fazer em uma determinada janela ou página. Boas instruções principais comunicam o objetivo do usuário em vez de focar apenas na manipulação da interface do usuário.
  • Expresse a instrução principal na forma de uma direção imperativa ou uma pergunta específica.
  • Não coloque pontos no final dos rótulos de controles ou instruções principais.
  • 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 perda de dados ou acesso ao sistema) por padrão. Se segurança e proteção 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 desativados. Os controles desativados podem ser difíceis de usar porque os usuários literalmente precisam deduzir por que estão desativados. Desabilite um controle quando os usuários esperam que ele seja aplicado e eles podem deduzir facilmente por que o controle está desabilitado. Remova o controle quando os usuários não puderem habilitá-lo ou não estiverem esperando que ele seja aplicado, ou deixe-o habilitado, mas forneça uma mensagem de erro quando ele for usado incorretamente.
      • Dica: 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-alvo provavelmente não deduzirão 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 dos genéricos. O ideal é que os usuários não precisem ler mais nada para entender o rótulo. Os usuários são muito mais propensos a 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 que exige Sim ou Não.
    • Não use os botões Aplicar em caixas de diálogo que não sejam 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 as folhas de propriedades e os itens do painel de controle têm essa necessidade.
    • Rotule um botão Cancelar se o cancelamento retornar o ambiente ao seu estado anterior (sem deixar nenhum efeito colateral). Caso contrário, rotule o botão Fechar (se a operação tiver sido concluída) ou Parar (se a operação estiver em andamento) para indicar que ele deixa o estado alterado atual intacto.
  • Links de comando
    • Sempre apresente links de comando em um grupo 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 com cuidado 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 o fornecimento de 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. Descreva esse link de comando em termos de como ele difere da primeira resposta, em vez de apenas "Cancelar" ou alguma variação.
  • Caixas de seleção "Não mostrar 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 o <item> pelo item específico. Por exemplo, não mostre esse lembrete novamente. Ao fazer referência a uma caixa de diálogo em geral, use Não mostrar esta 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 de Cancelamento 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 umatecla 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 o ato de clicar.
  • Dicas de ferramenta
    • Use dicas de ferramentas para fornecer rótulos para controles não rotulados. Você não precisa fornecer dicas de ferramentas de controles rotulados simplesmente por uma questão de consistência.
    • As dicas de ferramentas também podem fornecer mais detalhes para os botões rotulados da barra de ferramentas, se isso for útil. Não apenas repita ou dê uma reafirmação prolixa do que já está no rótulo.
    • Evite cobrir o objeto que o usuário está prestes a visualizar ou interagir. Sempre coloque a ponta na lateral do objeto, mesmo que isso exija separação entre o ponteiro e a ponta. Certa separação não é um problema, desde que a relação entre o objeto e sua ponta seja clara.
      • Exceção: dicas de ferramentas de nome completo usadas em listas e árvores.
    • Para coleções de itens, evite cobrir o próximo objeto que o usuário provavelmente exibirá ou com o qual interagirá. Para itens dispostos horizontalmente, evite colocar dicas à direita; para itens dispostos verticalmente, evite colocar dicas abaixo dos itens.
  • Divulgação progressiva
    • Use botões de divulgação progressiva Mais/Menos 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 certifique-se de que o que está oculto tenha 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 mistura de opções, comandos e detalhes.
      • Mais/menos comandos. Utilize apenas para comandos.
      • Mais/menos detalhes. Usar somente para informação.
      • Mais/menos <nome do objeto>. Use para outros tipos de objetos, como pastas.
    • Caso contrário:
      • Mostrar/ocultar opções. Use para opções ou uma mistura de opções, comandos e detalhes.
      • Mostrar/ocultar comandos. Use apenas para comandos.
      • Mostrar/ocultar detalhes. Use apenas para informação.
      • Mostrar/ocultar <nome do objeto>. Use para outros tipos de objetos, como pastas.
  • Barras de progresso
    • Use barras de progresso determinadas para operações que exigem um período de tempo limitado, mesmo que esse período de tempo não possa ser previsto com precisão. As barras de progresso indeterminadas mostram que o progresso está sendo feito, mas não fornecem outras informações. Não escolha uma barra de progresso indeterminada com base apenas na possível falta de precisão.
    • Forneça uma estimativa de tempo restante, se puder fazê-lo com precisão. As estimativas de tempo restante que são precisas são úteis, mas as estimativas que estão muito fora da marca ou variam significativamente não são úteis. Pode ser necessário realizar 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 perde seu valor se for reiniciada (talvez porque uma etapa da operação seja concluída) porque os usuários não têm como saber quando a operação será concluída. Em vez disso, faça com que todas as etapas da operação compartilhem uma parte do progresso e que a barra de progresso vá até a conclusão uma única vez.
    • Forneça detalhes úteis sobre o progresso. Forneça informações adicionais sobre o progresso, mas somente se os usuários puderem fazer algo com essas informações. Certifique-se de que o texto seja 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 os dois ao mesmo tempo.
  • Prompts
    • Utilize um prompt quando o espaço na tela for tão limitado que usar um rótulo ou instrução não seja desejá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 concisa. Não deve ser uma informação crucial que o usuário precise ver ao usar o controle.
    • O texto do prompt não deve ser confundido com o texto real. Para fazer isso:
      • Desenhe o texto do prompt em itálico cinza e o texto de entrada real em letra normal preta.
      • O texto do prompt não deve ser editável e deve desaparecer quando os usuários clicarem ou entrarem na caixa de texto.
        • Exceção: o prompt será exibido se a caixa de texto tiver o foco de entrada padrão e só desaparece quando o usuário começa 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 atual do usuário, 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 apenas se precisar. Ao exibir uma notificação, você está potencialmente interrompendo os usuários ou até mesmo incomodando-os. Certifique-se de que a interrupção seja 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!

Teclado

  • 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 tabulação a todos os controles interativos, incluindo caixas de edição somente leitura. Exceções:
    • Agrupe conjuntos de controles relacionados que se comportam como um único controle, como botões de rádio. Esses grupos têm uma única parada de tabulação.
    • Contenha corretamente os grupos para que as teclas de seta naveguem para frente e para trás dentro do grupo e permaneçam ali.
  • A ordem de tabulação deve fluir da esquerda para a direita e de cima para baixo. Geralmente, 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. A tabulação deve percorrer todas as paradas de tabulação em ambas as direções sem parar. Dentro de um grupo, a ordem de tabulação deve estar em ordem sequencial, sem exceções.
  • Dentro de uma parada de tabulação, a ordem das teclas de seta deve fluir da esquerda para a direita, de cima para baixo, sem exceções. As teclas de seta 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] e [Não faça] são respostas específicas à instrução principal.

  • Não confunda teclas de acesso com teclas de atalho. Embora as teclas de acesso e as teclas de atalho forneçam acesso do teclado à interface do usuário, elas têm finalidades e diretrizes diferentes.
  • Sempre que possível, atribua teclas 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), para que se beneficiem das teclas 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 teclas de acesso.
  • Não faça de 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 tab, seta e teclas de acesso.
  • Não atribua significados diferentes a teclas de atalho conhecidas. Por serem 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 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 clicabilidade apenas por inspeção visual.
    • A interface do usuário principal (como botões de confirmação) deve ter uma funcionalidade de clique estático. Os usuários não devem ter que 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 funcionalidade de clique ao passar o mouse.
    • Os links de texto devem sugerir estaticamente o texto do link e, em seguida, exibir sua funcionalidade 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 de mão (ou "seleção de link") apenas para links de texto e gráficos. Caso contrário, os usuários teriam que clicar em objetos para determinar se 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 sua tarefa. Certifique-se de que a interrupção seja justificada, como para tarefas críticas ou pouco frequentes e pontuais que exigem conclusão. Caso contrário, considere alternativas sem janela restrita.
  • As caixas de diálogo sem janela restrita 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. Elas são mais bem usadas em 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 propriedades

  • Certifique-se de que 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 objetivos do usuário em vez de tecnologia. Só porque uma propriedade configura uma tecnologia específica não significa que você deva apresentar a propriedade em termos dessa tecnologia.
    • Se você precisar apresentar configurações em termos de tecnologia (talvez porque seus usuários reconheçam 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 podem se aplicar 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 propriedades tiver apenas uma única guia e não for extensível. Use uma caixa de diálogo normal com OK, Cancelar e um botão Aplicar opcional. No entanto, as janelas de propriedade 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 únicas. Os assistentes são uma interface do usuário pesada, mais bem usada em tarefas com várias etapas e executadas com pouca frequência. Você não precisa usar assistentes, é possível 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 apenas para corrigir erros. Além de corrigir erros, os usuários não precisam 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 principal (por exemplo, Imprimir, Conectar ou Iniciar). Não use rótulos genéricos como Avançar (que não implica compromisso) ou Concluir (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 os rótulos do 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 um conjunto de configurações.
  • Use links de comando apenas para escolhas, não 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 as páginas Acompanhamento e Conclusão. Não use Cancelar porque fechar a janela não abandonará nenhuma alteração ou ação feita 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 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".
  • Preserve as seleções do usuário por meio da navegação. Por exemplo, se o usuário fizer alterações, clicar em Voltar e, em seguida, em 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 optem explicitamente por limpá-las.

Páginas do Assistente

  • Concentre-se na tomada de decisão eficiente. Reduza o número de páginas para se concentrar no essencial. Consolide páginas relacionadas e retire páginas opcionais do fluxo principal. 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 tiver 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 principal instrução para as páginas de introdução é "Antes de começar:".
  • Nas páginas em que os usuários são solicitados a fazer escolhas, otimize para os casos mais prováveis. Esses tipos de páginas devem apresentar escolhas reais, não apenas instruções.
    • Se você não usar uma página de Introdução, explique a finalidade do assistente na parte superior da primeira página de opções.
  • Use as 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 de resumo que apenas 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 páginas de acompanhamento 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 as páginas de conclusão somente quando os resultados não estiverem visíveis e não houver melhor maneira de fornecer feedback para a conclusão da tarefa.
    • Os assistentes que têm páginas de progresso devem usar uma página de conclusão ou de acompanhamento para indicar a conclusão da tarefa. Para tarefas de longa duração, feche o assistente na página Confirmar e use notificações para dar feedback.

Mensagens de erro

  • Não dê mensagens de erro quando os usuários provavelmente não executarão uma ação ou alterarão 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, certifique-se de que 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 impliquem erro do usuário. Evite usar você e seu nas frases. Embora a voz ativa seja geralmente preferida, use a voz passiva quando o usuário for o sujeito e possa se sentir culpado pelo erro se a voz ativa for usada.
  • Não use OK para mensagens de erro. Os usuários não veem os erros como OK. Se a mensagem de erro não tiver ação direta, use Fechar.
  • Não use as seguintes palavras:
    • Erro, falha (use o problema em vez disso)
    • Falha ao (use incapaz de)
    • Ilegal, inválido, ruim (use incorreto ou inválido)
    • Abortar, interromper, encerrar (use parar)
    • Catastrófico, fatal (use sério 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. Fazer isso é 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 nem perguntas, portanto, não formule perguntas de rotina como avisos.
  • Não dê mensagens de aviso quando os usuários provavelmente não executarão uma ação nem alterarão 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á uma razão clara para não prosseguir e uma chance razoável de que às vezes os usuários não o façam.
    • 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.
    • Prosseguir 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 realizado uma ação por engano.
  • Crie confirmações na forma de pergunta do tipo sim ou não e forneça respostas sim ou não. Ao contrário de outros tipos de caixas de diálogo, as confirmações foram projetadas para impedir que os usuários tomem decisões rápidas. Se os usuários não pensarem em sua resposta, uma confirmação não terá valor.

Ícones

  • Todos os ícones devem seguir asdiretrizes de ícones do estilo Aero. Substitua todos os ícones no estilo do Windows XP.
  • 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 com base no qual os usuários precisam agir.

  • Os ícones devem sempre corresponder à instrução principal ou a outro texto correspondente.
  • Os ícones de erro não são necessários para problemas de entrada do usuário não críticos. No entanto, os ícones são necessários para erros in-loco, porque, caso contrário, esse feedback contextual seria muito fácil 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 crie links para a home page da Ajuda, o sumário, uma lista de resultados de pesquisa ou uma página apenas vinculada a outras páginas. Evite criar links para páginas estruturadas como uma grande lista de perguntas frequentes, pois isso força os usuários a pesquisar aquela que corresponde ao link em que clicaram. Não crie links para tópicos específicos da Ajuda que não sejam relevantes e úteis para a tarefa em questão. Nunca crie links para páginas vazias.
  • Não coloque links de Ajuda em todas as janelas ou páginas por uma questão de consistência. Fornecer um link de Ajuda em um só lugar não significa que você tenha que fornecê-los em todos os lugares.
  • Sempre que possível, formule os links de ajuda com base na pergunta principal respondida pelo conteúdo da Ajuda. Não use a frase "Saiba mais sobre" ou "Obtenha ajuda com isso".
  • Use o texto completo do link de Ajuda, 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.