Uma pessoa arquiva o orçamento errado enquanto organiza uma lista. O item desaparece e surge um aviso com a opção “Desfazer”. A interface parece oferecer uma saída. A experiência só funciona se o item puder voltar de verdade, se a ação estiver ao alcance e se o resultado ficar claro. Projetar o retorno exige conversar sobre estados, tempo e consequências antes de decidir a aparência do botão.
Escolha uma ação que tenha volta definida
Imagine um painel usado por um pequeno estúdio para acompanhar orçamentos. A equipe separa pedidos em andamento de propostas arquivadas. Arquivar retira a proposta da lista principal, mantém seus dados e permite encontrá-la em uma lista própria. Esse comportamento oferece uma base para recuperação. Registre qual estado existia antes, o que a ação muda e como uma reversão pode restaurar a condição anterior. A definição precisa valer inclusive quando a proposta foi arquivada dentro de uma seleção múltipla.
Compare com o envio de um e-mail para o cliente. A mensagem já entregue pode ter efeitos fora do controle do painel. Se o sistema oferece uma janela para cancelar o envio antes que ele aconteça, explique isso no momento certo. A reversão de um estado interno e o cancelamento de uma operação pendente pedem textos diferentes. Antes de escrever “Desfazer”, peça que a equipe descreva o que de fato volta e quais efeitos já ocorreram. Use o verbo que corresponde ao estado que a interface pode garantir.
Decida quando é preciso confirmar antes de agir
O guia de prevenção de erros da WCAG trata de situações de maior consequência, como certos compromissos legais, transações financeiras e modificações ou exclusões de dados controláveis pelo usuário. Ele descreve caminhos que incluem permitir reversão, checar entradas ou oferecer revisão e confirmação, conforme a situação. Para um painel de propostas, a consequência depende da ação. Arquivar pode aceitar recuperação posterior. Excluir definitivamente um histórico de negociação exige examinar a possibilidade de recuperação e a necessidade de uma confirmação informativa.
Ao discutir a decisão, identifique a frequência, a dificuldade de detectar um erro e o custo de corrigir. A equipe pode arquivar dezenas de propostas por semana. Uma interrupção a cada arquivamento adicionaria trabalho a um gesto rotineiro. Para exclusão permanente de um conjunto, a revisão dos itens e a explicação sobre o alcance da perda podem ser essenciais. O artigo sobre diálogos modais em interfaces ajuda a analisar quando vale interromper a tarefa para uma decisão que precisa de atenção imediata.
Descreva a ação concluída e o objeto afetado
“Proposta arquivada” informa mais do que “Tudo certo”. Se a interface estava mostrando várias propostas parecidas, inclua um identificador reconhecível, como “Proposta da Feira do Centro arquivada”. Ao arquivar cinco itens, diga quantos foram arquivados e explique o que a reversão afeta. Uma pessoa que pressiona “Desfazer” precisa saber se vai recuperar todos ou só o último. Teste os textos com os nomes longos usados pela equipe, pois um título de projeto pode consumir boa parte da largura disponível.
A confirmação também deve acompanhar o estado real. Quando a pessoa aciona a ação e a resposta ainda está pendente, o texto pode indicar “Arquivando”. Só anuncie a conclusão quando o sistema tiver uma base para isso. Se a operação falhar, mantenha a proposta acessível e informe o próximo passo. Quando a pessoa pede a reversão, aplique a mesma distinção. “Restaurando proposta” e “Proposta restaurada” descrevem momentos diferentes e permitem entender se ainda existe trabalho em curso.
Dê à recuperação um endereço que dure
Uma ação em um aviso temporário pode facilitar o retorno imediato. Quem demorou a perceber o erro precisa de um segundo caminho se a operação ainda for recuperável. No painel, a seção Arquivadas pode oferecer “Restaurar” em cada proposta. Inclua uma orientação breve sobre onde encontrar a proposta depois de arquivar. O aviso pode perder destaque com o tempo, enquanto a navegação continua oferecendo uma forma de corrigir a decisão quando o erro aparece durante uma busca posterior.
Desenhe a entrada e a saída dessa seção com o mesmo cuidado da lista principal. Depois de restaurar a proposta, diga em qual lista ela está e como localizá-la se os filtros atuais a ocultarem. Pense também na pessoa que busca pelo nome e encontra um resultado arquivado. O resultado pode mostrar a condição e levar ao comando apropriado. Uma recuperação previsível depende da visibilidade do estado em todos os pontos onde a pessoa pode descobrir o engano.
Integre a mensagem à navegação por teclado
A orientação da WAI sobre mensagens de status explica como tornar certas mudanças perceptíveis para tecnologias assistivas sem transferir o foco para a mensagem. A parte que comunica o arquivamento e o botão que permite desfazer têm funções distintas. O anúncio da primeira não substitui a possibilidade de alcançar e acionar o segundo. Verifique onde a pessoa está com o teclado quando o item desaparece e defina para onde o foco deve ir. Escolha um destino coerente com a sequência da tarefa.
Se a pessoa arquiva a primeira proposta de uma lista, o próximo item pode oferecer continuidade. Se arquiva o único resultado, um título ou ação remanescente precisa dar contexto sobre o que ficou na tela. Ao restaurar, verifique se a lista muda sem desorientar quem já está em outro ponto. O guia sobre notificações em interfaces complementa essa análise de atenção e retorno. Teste se o aviso pode ser compreendido enquanto outras atualizações acontecem, como a mudança de contagem na barra lateral.
Modele ações consecutivas e respostas que chegam fora de ordem
Suponha que a pessoa arquive três propostas em sequência. Se o aviso anterior desaparece a cada nova ação, o botão atual precisa deixar claro qual objeto será restaurado. Uma estratégia possível é tratar cada arquivamento separadamente e fornecer histórico durável na seção correspondente. Outra é agrupar ações quando elas representam uma operação em lote claramente identificada. Escolha com base na forma como a equipe trabalha e registre o comportamento para quem testa.
A chegada de respostas do servidor também influencia o resultado. A primeira operação pode terminar depois da segunda. Se o botão simplesmente usa o último item que mudou de aparência, existe risco de restaurar o objeto errado. Relacione cada comando de reversão à operação específica. Se a proposta mudou por ação de outra pessoa desde o arquivamento, informe o conflito e atualize o contexto antes de propor outra ação. Registre o que fazer em caso de falha parcial de um lote, incluindo o número de itens afetados e o caminho de recuperação aplicável a cada um.
Teste o erro que a equipe realmente comete
Em uma sessão breve, entregue um cenário em que duas propostas têm nomes parecidos. Peça para arquivar uma e depois avise que a instrução inicial indicou o item errado. Veja se a pessoa identifica qual foi movida e consegue recuperá-la. Faça uma segunda rodada depois de sair da página. Nesse momento, o aviso inicial já perdeu utilidade. Observe como a pessoa busca a proposta e como percebe que restaurou a versão correta.
Inclua um cenário com teclado e outro com uma falha de conexão durante a recuperação. Confira se a mensagem comunica o resultado com clareza e se o comando pode ser tentado de novo quando isso é seguro. No caso de seleção múltipla, experimente restaurar só um item pela lista durável. Em todas as rodadas, compare o que a pessoa acredita ter ocorrido com o estado salvo pelo serviço. A diferença entre os dois revela onde revisar o conteúdo ou a implementação.
Documente o que a ação promete
Para cada comando recuperável, registre o estado anterior, os efeitos externos, a duração da recuperação e o destino da entidade depois do retorno. Inclua a mensagem exibida em sucesso e falha, o comportamento do foco e as condições de uma nova tentativa. Se a ação depende de permissões, descreva o que acontece quando elas mudam entre a operação inicial e a reversão. Uma tabela curta costuma bastar para alinhar design, desenvolvimento e atendimento.
O botão “Desfazer” ganha credibilidade quando a pessoa entende a consequência e consegue confirmar o estado recuperado. Comece por uma ação frequente do produto e acompanhe o percurso até a restauração persistida. Depois provoque um atraso ou um conflito e veja se a interface continua dizendo a verdade. Esse teste torna verificável a promessa que o botão faz.
Feche a revisão com um exemplo completo de mensagem de arquivamento, um de restauração e um de conflito. Use o mesmo nome de proposta nos três. Assim, a equipe pode ler a sequência em voz alta e identificar saltos de contexto antes de implementar os avisos.