Feedback ao usuário

Feedback é a forma como o sistema responde ao que a pessoa fez ou ao que aconteceu. No dia a dia logístico, um feedback mal escolhido custa caro: um erro que some sozinho em 4 segundos pode significar uma carga não despachada que ninguém percebeu. Regra de ouro: o peso do feedback deve ser proporcional ao impacto. Quanto mais o usuário precisa agir, mais o feedback deve interromper e permanecer visível.

Qual componente usar

Responda as perguntas nesta ordem e pare na primeira resposta “sim”:

A mensagem é sobre um campo específico de formulário? → Mensagem no próprio campo (estado de erro do Input).
O usuário precisa tomar uma decisão antes de continuar? (confirmar exclusão, escolher entre opções) → Modal.
O problema precisa continuar visível até ser resolvido? (falha na emissão, veículo com manutenção atrasada) → Alert.
É só a confirmação do resultado de uma ação, sem nada a fazer? (carga despachada, alterações salvas) → Toast.
É uma explicação curta de um ícone, sigla ou dado? → Tooltip.
Não há dados para mostrar? → EmptyState (veja Estados da interface). | Situação | Componente | Interrompe? | Some sozinho? | | — | — | — | — | | Erro ou aviso em campo | Estado de erro do Input | Não | Não, some ao corrigir | | Confirmar ação destrutiva ou irreversível | Modal | Sim, bloqueia a página | Não | | Falha ou risco que afeta o fluxo | Alert | Não | Não (pode ser dispensável) | | Resultado de ação concluída | Toast | Não | Sim | | Explicar ícone ou sigla | Tooltip | Não | Sim, ao tirar o mouse ou o foco |

Severidade e cor

Os cinco tipos do Alert seguem o mesmo significado em todo o sistema:

Tipo	Quando usar	Exemplo
Erro (vermelho)	Bloqueia a operação	Falha na emissão de nota
Aviso (amarelo)	Requer cautela, mas não bloqueia	Veículo com manutenção atrasada
Sucesso (verde)	Confirma conclusão	Rota otimizada
Informação (azul)	Contexto útil, sem urgência	Nova versão do manifesto disponível
Neutro	Aviso genérico, sem peso semântico	Mensagem de apoio

Deve: a cor nunca é o único sinal. Sempre acompanhe com texto e, quando couber, ícone. Parte dos operadores não distingue vermelho de verde, e o brilho do sol no pátio apaga contrastes sutis.
Deve: vermelho é reservado para erro. Não use para destacar algo “importante” (para isso, use aviso).

Como escrever

Todo feedback responde duas perguntas: o que aconteceu e o que fazer agora. Se não há nada a fazer, basta o primeiro.

Neutro e do ponto de vista do sistema. Evite “você”, “eu” e “nós”. Regras completas em Estilo de escrita.
Sem culpa. “CPF inválido. Insira apenas números.” em vez de “Você digitou o CPF errado.”
Específico. “Falha na conexão.” é melhor que “Ocorreu um erro.”
Nada de “Ops”. Seja técnico e útil. | Componente | Estilo | Exemplo correto | | — | — | — | | Toast | Caixa de sentença, no máximo uma frase curta, sem artigos | Carga despachada. | | Alert | Caixa de sentença; título em negrito só se houver texto longo abaixo | Endereço não encontrado. Verifique o CEP. | | Modal | Caixa de título, curto; se for pergunta, termina com “?” | Excluir Rota? | | Tooltip | Sem ponto final e sem reticências | Imprimir manifesto |

Ação destrutiva: o botão diz o que vai acontecer

Nunca use “Sim” e “Não”. O botão de confirmação repete a ação, com o estilo Danger; o outro é sempre Cancelar.

Modal: Excluir Rota?
Descrição: A rota RT-2041 e seus 12 pontos de parada serão removidos. Essa ação não pode ser desfeita.
Botões: Cancelar · Excluir Rota

Regras por componente

Alert

Deve ficar no contexto do problema (no topo da área afetada, não em um canto distante).
Deve ser dispensável apenas quando ignorar não tem consequência.
Recomendado um único Alert por área. Se houver vários problemas, agrupe em uma lista dentro de um Alert.
Botão de ação dentro do Alert leva a uma tela de resolução e, nesse caso, usa reticências: Configurar impressora…

Toast

Deve conter no máximo uma frase curta e nenhuma ação crítica.
Deve aparecer sem tirar o foco de onde a pessoa está.
Não deve ser o único registro de um erro que exige correção. Se o usuário precisa agir, use Alert ou o próprio campo.
[Proposta] Toasts de sucesso e informação somem sozinhos após alguns segundos; toasts de erro permanecem até serem dispensados, para não perder uma falha por uma distração.
[Proposta] Um Toast por vez, os seguintes entram em fila.

Deve ser usada só para interromper: confirmação crítica, alerta que exige decisão ou detalhamento que pede foco total.
Deve ter sempre uma saída clara (Cancelar e fechar).
Não deve abrir outra modal por cima. Se o fluxo é longo, use Drawer (painel lateral), que mantém o contexto da tela ao fundo.
[Proposta] O foco vai para dentro da modal ao abrir, fica preso nela, a tecla Esc fecha, e o foco volta ao elemento que a abriu.

Deve descrever ícones que não têm texto visível.
Não deve repetir o rótulo que já está visível.
Não deve conter informação essencial ou ações, já que não aparece em telas de toque.

Para designers

Componente	Frame no Figma
Alert	Alert
Toast	Toast/Notification
Modal	Modal
Tooltip	Tooltip

Para desenvolvedores

Componente	mds-styles (HTML/CSS)	mds-angular	Situação
Alert	`.mds-alert` + `.mds-alert--{neutral, info, warning, danger, success}`	`<mds-alert variant size solid dismissible fixed animated>`	Disponível
Modal	`.mds-float-panel--modal`	`<mds-float-panel>`	Disponível (Modal e Drawer compartilham o FloatPanel)
Tooltip	`.mds-tooltip`	`[mdsTooltip]`	Disponível (sem story no Storybook do mds-styles)
Erro em campo	`.mds-input--danger` + `.mds-input__helper`	`<mds-input>`	Disponível
Toast	não existe	não existe `mds-toast`	Só desenhado no Figma

Lacuna conhecida: Toast. O desenho existe no Figma, mas ainda não há componente em código. Enquanto isso, a aproximação prevista no mds-angular é <mds-alert [fixed]="true" [dismissible]="true">. Trate como solução temporária e sinalize no ticket que a tela usa a aproximação. Proposta de nome: adotar Toast no lugar de “Notification”, que costuma significar central de notificações persistente (o “sininho”) ou push do sistema.

Checklist de revisão

Use em revisão de design e em code review:

Escolhi o componente pela árvore de decisão, não por conveniência?
A mensagem diz o que aconteceu e o que fazer (quando há o que fazer)?
Erros que exigem ação não dependem só de um Toast?
O botão de confirmação destrutiva repete a ação (não “Sim/Não”)?
A informação não depende só de cor?
O texto está em caixa de sentença, sem “você”, sem “Ops”?