Os principais erros de UX em dashboards

Em muito SaaS B2B, o dashboard começa pequeno e vai acumulando responsabilidades. No início, ele mostra quatro ou cinco coisas que parecem importantes. Depois entra um gráfico novo, uma área quer espaço para uma funcionalidade recém-lançada, vendas pede um bloco para destacar algo na demonstração, operações precisa de pendências, financeiro quer volume. Dois anos depois, a primeira tela do produto tem quatorze blocos e ninguém sabe mais quais deles realmente merecem estar ali.

O problema não é ter muita informação. É que o dashboard deixou de responder a uma pergunta clara e virou uma coleção das coisas que o produto consegue mostrar.

Dashboard não deveria ser inventário de funcionalidades

Uma tela de fluxo normalmente tem uma responsabilidade evidente: criar uma cobrança, editar um cliente, revisar uma transação, exportar um relatório. O dashboard é diferente. Ele não vem com um job tão óbvio. Por isso é fácil cada time projetar nele a própria prioridade.

Precisamos mostrar a nova feature.

Esse indicador é importante para vendas.

O cliente deveria ver isso.

Vamos colocar um card aqui.

Nenhuma dessas decisões isoladamente parece ruim. O problema aparece no conjunto. A tela passa a refletir a estrutura interna da empresa em vez da necessidade de quem abre o produto.

Uma boa primeira pergunta para revisar um dashboard é: o que alguém deveria compreender nos primeiros segundos desta tela? Não qual feature deveria aparecer. Não qual gráfico está bonito. Qual entendimento precisa acontecer.

Nem todo dashboard tem o mesmo trabalho

Também existe um erro anterior: falar de “dashboard” como se fosse um único tipo de interface. Um dashboard executivo pode precisar responder “como o negócio está performando?”. Um operacional: “o que precisa da minha atenção hoje?”. Um financeiro: “o dinheiro está fechando?”. Um produto de monitoramento: “existe alguma anomalia agora?”. Um produto comercial: “onde estão as oportunidades e os riscos?”.

Essas telas podem usar os mesmos componentes — cards, gráficos, tabelas, indicadores — mas o critério de prioridade muda completamente. Antes de redesenhar, eu escreveria uma frase:

Ao abrir esta tela, [tipo de usuário] precisa conseguir entender ______ e decidir ______.

Se o time não consegue completar essa frase, dificilmente vai conseguir decidir qual dos quatorze blocos merece estar no topo.

Mostrar tudo com o mesmo peso é quase o mesmo que não priorizar

Imagine uma tela com receita, clientes ativos, MRR, ticket médio, churn, faturas em atraso, volume processado, transações recusadas, saldo, repasses, novos clientes e cancelamentos. Todos em cards do mesmo tamanho, mesmo fundo, mesmo título, mesmo contraste. Tecnicamente, a informação está toda lá. Visualmente, o produto não disse qual delas importa agora. A pessoa precisa construir a hierarquia sozinha.

É aqui que entra um dos princípios clássicos da Nielsen Norman Group sobre design estético e minimalista: informação irrelevante ou raramente necessária compete com aquilo que realmente importa. Minimalismo aqui não significa deixar a tela vazia. Significa não dar o mesmo peso para informações com importância diferente. Uma operação financeira pode precisar de uma tela extremamente densa e ainda assim ter ótima hierarquia. Densidade e desorganização não são sinônimos.

A primeira dobra deveria ter uma tese

Uma forma útil de revisar o topo do dashboard é perguntar: se o usuário só visse esta parte da tela, o que ele entenderia? Talvez:

O mês está acima da meta, mas inadimplência aumentou.

Ou:

Tudo operando normalmente, com três pagamentos que precisam de revisão.

Ou:

R$ 840 mil disponíveis para saque e R$ 127 mil ainda em liquidação.

Essa é uma tese. Agora compare com:

Receita: R$ 842.300
Clientes: 1.423
Transações: 8.492
Ticket médio: R$ 99,20

Isso é uma lista de fatos. Pode ser útil, mas não necessariamente comunica estado. Dashboard bom não precisa interpretar tudo para o usuário, mas deveria ajudá-lo a entender o que merece atenção antes de obrigá-lo a abrir quatro relatórios.

Número sem contexto pode ser apenas dado

“R$ 47.300” pode significar muita coisa. Receita deste mês? Saldo disponível? Volume bruto? Valor liquidado? Recebível futuro? Resultado após taxas? Mesmo com um rótulo correto, ainda falta contexto para interpretar desempenho. Por isso comparações são frequentemente úteis. Por exemplo:

R$ 47.300
+12,4% vs. mês anterior

Ou:

R$ 47.300 de R$ 60.000
79% da meta

Mas eu evitaria transformar isso numa regra de que todo número precisa de comparação. Alguns números são úteis como estado absoluto: 7 cobranças vencidas, R$ 18.420 disponíveis para saque, 3 transações aguardando análise, 0 incidentes ativos. A pergunta não é “onde está a comparação?”. É: o usuário consegue interpretar o que esse número significa para a decisão que precisa tomar? Se não, falta contexto.

Em produto financeiro, nomes próximos podem representar estados muito diferentes

Esse é um problema especialmente perigoso em fintech. Saldo disponível, saldo total, saldo futuro, recebíveis, volume processado, volume aprovado, volume liquidado, valor bruto, valor líquido. Esses conceitos podem parecer próximos para quem desenha o card. Para quem movimenta dinheiro, são diferentes.

Um título como:

Saldo

pode ser insuficiente. A pessoa precisa saber: saldo que posso sacar agora? Saldo incluindo valores ainda não liquidados? Saldo já descontado de taxas? Em qual período? Em qual conta?

Design de dashboard financeiro não é apenas escolher quais números colocar em destaque. É proteger significado. Um número correto com um label ambíguo continua sendo uma experiência ruim.

Estado vazio não deveria parecer produto quebrado

O primeiro contato de muitos usuários com um dashboard acontece antes de existir volume suficiente para preencher a tela: conta nova, empresa recém-conectada, primeiro projeto, primeira cobrança, primeiro período sem movimentação. A versão preguiçosa é:

R$ 0
0 clientes
0 transações

Gráfico vazio, tabela vazia, mais gráfico vazio. Tecnicamente correto. Pouco útil. O estado vazio deveria ajudar a pessoa a compreender por que não existe informação ali, o que aparecerá quando houver e qual ação faz o produto começar a produzir esse dado. Por exemplo:

Você ainda não processou nenhuma cobrança.
Quando receber o primeiro pagamento, seu volume e taxa de aprovação aparecerão aqui.

Criar primeira cobrança

Isso conecta dashboard a ativação. Mas estado vazio não existe apenas no primeiro dia. Também aparece quando:

• o filtro não encontra resultado;

• o período selecionado não teve movimento;

• uma integração foi desconectada;

• determinado usuário não tem acesso ao dado;

• uma conta dentro da organização ainda não possui atividade.

“Não existe dado” também tem causas diferentes. A interface deveria saber qual delas está acontecendo.

Dashboard operacional precisa mostrar exceção, não apenas média

Imagine uma operação com 99,4% de pagamentos processados corretamente. É um ótimo número. Mas talvez existam 12 pagamentos bloqueados que exigem ação humana agora. O indicador agregado diz “está tudo bem”. A operação diz “tem trabalho esperando”.

Esse é um problema comum em dashboards B2B: KPI e pendência são tratados como a mesma coisa. Não são. Um KPI ajuda a entender desempenho. Uma fila ajuda a executar. Um dashboard operacional frequentemente precisa dos dois. Por exemplo:

Aprovação de pagamentos
96,8%

e logo abaixo:

8 pagamentos precisam de revisão

Agora existe uma ponte entre observar e agir. Se a tela mostra apenas a saúde média, pode esconder justamente o pequeno grupo que precisa de atenção.

A tabela quebra de um jeito diferente do gráfico

Produtos costumam ser desenhados com datasets convenientes: vinte transações, dez clientes, seis faturas. A tabela parece perfeita. O cliente real coloca 150 mil registros. Agora outras perguntas aparecem. Quanto demora para carregar? Existe paginação ou virtualização? Consigo encontrar uma transação específica? A busca aceita os identificadores que operações realmente possuem? Filtros podem ser combinados? É possível voltar para o mesmo estado da tabela? Consigo exportar o subconjunto filtrado? A ordenação funciona sobre todo o dataset ou apenas a página atual?

Aqui Product Design e engenharia se encontram. Não adianta desenhar uma tabela linda para um volume que o produto não consegue operar. Também não adianta resolver performance e deixar uma pessoa olhando para 80 mil linhas sem ferramentas para encontrar o que precisa. Escala é comportamento de interface.

Busca não é solução para uma tabela sem modelo

Quando o volume cresce, a reação costuma ser:

coloca uma busca.

Mas alguém pode procurar por nome, e-mail, CPF, CNPJ, ID da transação, ID externo, número do pedido, valor, últimos quatro dígitos ou referência do cliente. Qual desses a busca entende? Uma caixa com placeholder “Buscar...” pode esconder uma capacidade muito limitada. Em tela operacional, vale ser explícito:

Buscar por ID, e-mail ou CPF

Ou criar filtros adequados para o trabalho. O melhor mecanismo depende da tarefa. A questão é evitar tratar “tem busca” como sinônimo de “é encontrável”.

O mesmo dashboard raramente serve igualmente para todos os papéis

Em SaaS B2B, “o usuário” pode significar dono, gestor, financeiro, operador, analista, suporte, administrador. Todos entram na mesma conta. Nem todos precisam começar pelo mesmo lugar. O gestor pode querer saber quanto a empresa movimentou este mês. O operador, o que precisa resolver agora. O financeiro, quanto foi liquidado e quanto ainda falta.

Isso não significa necessariamente construir um dashboard diferente para cada papel. Existem outras possibilidades: priorizar módulos diferentes, mostrar pendências apenas para quem pode agir, permitir personalização, salvar visões, usar permissões para esconder informação irrelevante, criar uma primeira camada comum e rotas especializadas depois. O erro é assumir que contratar cinco assentos significa ter cinco cópias do mesmo trabalho.

Período padrão é uma decisão de produto

“Últimos 30 dias” parece neutro. Não é. Uma operação diária pode precisar abrir em “hoje”. Um financeiro, no mês atual. Uma equipe de vendas, no trimestre. Um negócio sazonal talvez compare com o mesmo período do ano passado.

O filtro inicial determina a primeira leitura. Se o produto abre no período errado, toda sessão começa com uma correção. Isso parece pequeno. Multiplique por centenas de usuários, todos os dias. Defaults são decisões silenciosas de UX.

Cuidado ao medir “uso” de um dashboard

Existe uma recomendação intuitiva:

veja quais blocos recebem clique e remova os que ninguém usa.

Só que dashboard é frequentemente uma interface de leitura. Um card pode ser extremamente importante e nunca receber um clique.

Saldo disponível: R$ 84.320

Talvez a pessoa leia isso todo dia e nunca interaja. Zero clicks não significa zero valor. Por isso eu não avaliaria um bloco apenas por interação. Dependendo da interface, vale combinar:

• visibilidade do bloco;

• scroll depth;

• cliques quando existe ação;

• navegação subsequente;

• frequência de uso da tela;

• entrevistas;

• observação;

• perguntas de suporte;

• tarefas que levam alguém a abrir o dashboard.

Analytics ajuda a tirar opinião da discussão. Mas precisa medir o comportamento certo. Não confunda ausência de clique com ausência de leitura.

Um teste simples: peça interpretação, não opinião

Existe um exercício melhor que perguntar “gostou do dashboard?”. Mostre a tela e peça:

Me diga o que está acontecendo nesta conta.

Depois:

Tem alguma coisa aqui que precisa de atenção?

E:

O que você faria em seguida?

Observe. Se a pessoa entende rapidamente os principais estados, bom sinal. Se começa a ler cada card isoladamente tentando montar uma história, talvez a hierarquia esteja fraca. Se pergunta “isso é bruto ou líquido?”, o problema pode ser nomenclatura. Se entende o problema mas não sabe como agir, talvez falte ligação entre monitoramento e workflow. Esse teste avalia comunicação. Não decoração.

“Está tudo certo?” é uma boa pergunta, mas não para todo dashboard

Em dashboard operacional ou de monitoramento, uma excelente pergunta de abertura pode ser: existe alguma coisa que exige minha atenção? Mas não faria disso uma regra universal. Um dashboard analítico pode existir para explorar tendências, um executivo pode querer entender desempenho, um financeiro pode estar fazendo fechamento.

O princípio mais geral é: a tela deveria permitir que o usuário responda rapidamente à pergunta que o trouxe até ela. Quando ninguém consegue dizer qual é essa pergunta, o dashboard vira coleção de métricas.

O primeiro movimento talvez não seja redesenhar

Imagine que o dashboard está ruim. A reação natural:

vamos fazer um redesign.

Eu começaria antes. Listaria todos os blocos atuais e, para cada um: para quem existe, que pergunta responde, que decisão muda, com que frequência essa pergunta aparece, se existe outro lugar melhor para essa informação, se o dado está disponível e confiável, se alguém realmente precisa dele na primeira tela. Esse exercício costuma revelar três categorias.

Precisa estar imediatamente visível

Informação central para o estado ou tarefa.

É útil, mas não precisa estar no topo

Pode descer, ir para relatório ou aparecer contextualmente.

Não sabemos por que existe

Provavelmente entrou pelo roadmap.

A remoção começa a ficar menos política quando existe critério.

Cada card costuma ter um patrocinador interno

Essa é a parte difícil. Alguém pediu aquele gráfico. Alguma área acredita naquele KPI. Uma funcionalidade foi lançada e ganhou espaço. Vendas usa aquele bloco na demo. Produto não quer parecer que está removendo valor. Por isso dashboard ruim sobrevive por tanto tempo.

O problema raramente é “ninguém sabe desenhar cards”. É “ninguém quer decidir o que merece perder visibilidade”. Arquitetura visual também é estratégia. Dar mais espaço para uma informação significa, inevitavelmente, dar menos para outra.

Dashboard não precisa provar que o produto é completo

Existe uma pressão particular em SaaS B2B. Dashboard aparece em screenshot do site, demo comercial, pitch, apresentação, case. Uma tela cheia parece sofisticada. Mas existe diferença entre uma imagem que comunica robustez em dez segundos e uma interface que alguém precisa usar todos os dias.

A melhor solução para demo não pode ser o único critério da tela operacional. Se vendas precisa mostrar amplitude do produto, talvez exista outro jeito: dados de demonstração, roteiro, workspace preparado, visões específicas. O usuário recorrente não deveria pagar diariamente pelo impacto visual de uma apresentação comercial.

Um bom dashboard reduz tempo até compreensão

Essa é uma régua que eu gosto mais do que “está bonito?” ou “tem todos os KPIs?”. Quanto tempo alguém leva para entender o que está acontecendo, se isso está bom ou ruim dentro do contexto, se existe alguma exceção e se há algo que precisa ser feito? Nem todo dashboard precisa responder todas as quatro. Mas deveria responder muito bem aquelas que pertencem ao seu job. Quando não responde, adicionar mais um gráfico geralmente piora.

Dashboard não é a tela em que o produto demonstra tudo que sabe. É a tela em que o produto decide o que vale a pena saber agora. E em sistemas complexos, essa decisão costuma ser mais importante que o componente usado para representar o dado.

Em produto financeiro, a diferença fica ainda mais crítica: estados parecidos podem significar dinheiro disponível, pendente, bloqueado, liquidado ou em disputa. No artigo Gateway não é checkout: dois produtos, dois inimigos, eu entro justamente nessa diferença entre simplificar a experiência e preservar a granularidade que a operação precisa.

Fontes

Nielsen Norman Group. 10 Usability Heuristics for User Interface Design, Jakob Nielsen. Referência para os princípios de visibilidade do estado do sistema, reconhecimento em vez de memorização e design estético e minimalista usados na discussão sobre hierarquia, contexto e redução de informação sem função clara.