A palavra 'dashboard' está sobrecarregada a ponto de perder o sentido no design de software. Já vi de tudo, desde um único card de KPI até um painel analítico com 40 painéis, ser chamado de dashboard. Em software financeiro especificamente, dashboards existem para um único propósito: ajudar alguém a tomar uma decisão ou executar uma ação. Se um usuário olha para um dashboard e sai sem decidir ou agir, o dashboard falhou. Independentemente de quantos dados exibe ou quão visualmente polido ele pareça.
Ao longo da minha carreira, dos dashboards de trading em tempo real para empresas de investimentos que construí na GFT aos dashboards de relatórios que construí no Data Studio como estagiário na iRestify, projetei e iterei um bom número de dashboards de dados financeiros e operacionais. Este post destila os princípios e padrões que se sustentaram em todos eles.
Comece pela decisão, não pelos dados
O erro mais comum que vejo no design de dashboards financeiros é o design orientado a dados. Um stakeholder pede um dashboard, lista todos os dados que quer ver e o designer organiza esses dados em painéis. O resultado é um dashboard abrangente, porém inútil. Responde muitas perguntas que ninguém estava fazendo e é silencioso sobre as perguntas que os usuários realmente têm.
Meu ponto de partida é sempre um inventário de decisões. Quais decisões esse usuário toma? Com que frequência? Com que nível de urgência? Um gerente de agência verificando um dashboard operacional matinal toma decisões diferentes, e precisa de informações diferentes, de um analista de crédito revisando uma carteira de empréstimos. O fato de ambos estarem olhando para dados financeiros é quase irrelevante para o design.
Pegue um dashboard de carteira de empréstimos para um analista de crédito. As principais decisões diárias: quais contas estão caminhando para a inadimplência, quais propostas estão paradas em análise além da meta de atendimento, e onde a carteira está em relação aos seus limites de risco e volume. Três decisões. Tudo no dashboard é avaliado com base em se apoia uma dessas três. Se um dado não se conecta a nenhuma delas, não pertence ao dashboard principal. Vai para uma visão de detalhamento acessível sob demanda.
Hierarquia de informação: o padrão F não é suficiente
A maioria dos guias de UX recomenda projetar para o comportamento de leitura em padrão F. Usuários escaneiam o topo da página, depois descem pelo lado esquerdo. Isso é preciso para conteúdo editorial. Para dashboards de apoio à decisão, o padrão de leitura é diferente: usuários escaneiam em busca de anomalias, não por informação em ordem de leitura. Eles estão procurando algo que está errado, inesperado ou que requer ação.
Isso muda a hierarquia de informação fundamentalmente. A informação mais importante em um dashboard financeiro não é o número mais proeminente. É o número que está fora da faixa normal. Projete para destaque de exceções em vez de abrangência. Indicadores de status, mudanças de cor baseadas em limites e setas de tendência são mais valiosos do que números precisos quando o caso de uso principal é detecção de exceções.
Na prática, projeto dashboards financeiros com três zonas de peso visual. A zona um é a zona de exceções. Itens que requerem ação ou atenção, sempre no topo ou em posição proeminente à esquerda. A zona dois é a zona de status. Estado atual das métricas principais, confirmando que operações normais estão em andamento. A zona três é a zona de contexto. Tendências históricas e dados comparativos que ajudam a interpretar as duas primeiras zonas.
Design de KPI Cards: o que realmente importa
KPI cards são o elemento mais comum em dashboards financeiros e também o mais comumente mal projetado. Um KPI card que mostra apenas um número não diz quase nada ao usuário. Um KPI card que mostra um número em contexto diz ao usuário se ele deve se preocupar.
Os elementos que incluo em um KPI card bem projetado: o valor atual (primário), a referência de comparação (versus período anterior, versus meta ou versus orçamento), o indicador direcional (seta para cima/baixo/neutro), a magnitude da mudança (percentual ou absoluta) e o período que o valor cobre. São cinco informações em um card compacto. O desafio de design é organizá-las para que a mais relevante para a decisão, geralmente a comparação e a direção, seja a mais proeminente visualmente, não o número absoluto.
Convenções de cor em KPI cards devem ser usadas com cuidado em aplicações financeiras. Vermelho não significa universalmente ruim em finanças. Um indicador vermelho em reservas para perdas com empréstimos pode significar que a reserva está abaixo dos níveis exigidos, claramente ruim. Um indicador vermelho em um centro de custos pode significar que os custos estão acima do orçamento, geralmente ruim. Um indicador vermelho em uma métrica de receita pode significar que a receita está acima da meta, o que é bom. A cor deve ser consistentemente vinculada à direção do desvio em relação ao resultado desejado, e a direção desejada deve ser contextualmente apropriada para a métrica.
Escolhendo o tipo de gráfico certo
A seleção do tipo de gráfico é uma das decisões mais consequentes no design de dashboards, e frequentemente é feita com base em estética em vez de estrutura de dados. Aqui estão as escolhas de gráfico que uso em contextos de dashboards financeiros e por quê:
- Gráficos de linha: para dados de séries temporais contínuas onde a tendência e a taxa de mudança importam. Saldo de carteira de empréstimos ao longo do tempo, volume diário de transações, movimentação de taxas de juros. Não use gráficos de barras para séries temporais quando a linha de tendência é a mensagem.
- Gráficos de barras (agrupados ou empilhados): para comparar categorias ou períodos discretos. Comparar receita por linha de produto, ou mostrar este mês vs mês passado vs orçamento em múltiplas métricas. Barras empilhadas funcionam quando a relação parte-todo é significativa; barras agrupadas funcionam quando a comparação direta entre categorias é a prioridade.
- Sparklines: para indicação de status em vez de análise. Um pequeno gráfico de linha dentro de um KPI card mostra a tendência recente sem exigir um gráfico completo. Para dashboards com muitos KPI cards, sparklines adicionam contexto significativo com custo visual mínimo.
- Tabelas com visualização inline: para dados que exigem precisão. Quando usuários precisam saber valores exatos e comparar entre muitas linhas, uma tabela com gráficos de barras inline ou células coloridas é mais útil do que um gráfico. Profissionais financeiros frequentemente precisam dos números reais, não apenas da forma dos dados.
- Gráficos de dispersão: use com moderação e apenas quando a correlação entre duas variáveis é a pergunta real sendo respondida. Para análise de risco de crédito ou análise de portfólio, gráficos de dispersão são poderosos. Para dashboards operacionais, geralmente são a escolha errada.
Padrões de exibição de dados em tempo real
Dashboards financeiros precisam cada vez mais exibir dados em tempo real ou quase tempo real. Dados de mercado, volumes de processamento de pagamentos, contagem de sessões ativas. Esses valores mudam continuamente. Projetar para dados em tempo real introduz desafios específicos de UX que dashboards estáticos não têm.
O princípio mais importante: não anime cada atualização de dados. Se um número muda a cada segundo, animar cada mudança cria ruído visual que torna o dashboard exaustivo de monitorar por períodos prolongados. Minha regra é animar uma mudança de valor apenas quando a magnitude dela excede um limite que você define por métrica. Defina esse limite a partir do que é movimento normal para aquela métrica: um preço que oscila a cada segundo precisa de uma faixa muito mais larga do que uma contagem diária de aprovações. Flutuações pequenas atualizam silenciosamente, movimentos significativos chamam atenção através de animação.
Indicadores de frescor de dados são essenciais em dashboards de tempo real. Os usuários precisam saber se os dados que estão vendo são atuais ou obsoletos. Isso é especialmente crítico em contextos financeiros onde agir com dados obsoletos pode ter consequências monetárias. Exibo um timestamp de última atualização em termos relativos ('Atualizado há 3 segundos') com um timestamp absoluto disponível no hover. Se o feed de dados está atrasado ou interrompido, exibo um aviso visível de obsolescência em vez de mostrar dados antigos silenciosamente.
// Staleness detection service
@Injectable({ providedIn: 'root' })
export class DataFreshnessService {
private readonly STALE_THRESHOLD_MS = 30_000; // 30 seconds
isStale(lastUpdated: Date | null): boolean {
if (!lastUpdated) return true;
return Date.now() - lastUpdated.getTime() > this.STALE_THRESHOLD_MS;
}
freshnessLabel(lastUpdated: Date | null): string {
if (!lastUpdated) return 'Data unavailable';
const secondsAgo = Math.floor((Date.now() - lastUpdated.getTime()) / 1000);
if (secondsAgo < 5) return 'Just now';
if (secondsAgo < 60) return `${secondsAgo} seconds ago`;
return `${Math.floor(secondsAgo / 60)} minutes ago`;
}
}Revelação progressiva para conjuntos de dados complexos
Revelação progressiva é a prática de mostrar informação resumida primeiro e revelar detalhes sob demanda. Para dashboards financeiros, isso não é apenas uma preferência de design, é uma necessidade para gerenciar carga cognitiva em telas densas de dados.
Minha hierarquia de revelação progressiva para dashboards financeiros: o nível um é o dashboard resumido mostrando KPIs e exceções, o nível dois é a visão de detalhe da métrica mostrando a série temporal completa, desdobramento por subcategoria e dados comparativos contextuais, o nível três é o detalhe no nível de transação ou registro, acessível apenas quando o usuário tem uma necessidade investigativa específica.
A navegação entre esses níveis deve ser eficiente. Clicar em um KPI card deve ir diretamente para a visão de nível dois relevante para aquela métrica, não para uma página genérica de analytics. Clicar em um ponto de dado anômalo em um gráfico deve revelar os registros subjacentes que explicam a anomalia. Esses caminhos contextuais de drill-down reduzem o tempo investigativo que o usuário precisa para entender o que está acontecendo, que é a proposta de valor central do dashboard.
A experiência na GFT: dashboards em tempo real para empresas de investimentos
Na GFT, construí dashboards de trading em tempo real para empresas de investimentos com Angular, D3.js e WebSockets, mantendo a latência dos dados abaixo de um segundo. Esse foi um contexto particularmente instrutivo porque traders e analistas são usuários sofisticados com necessidades de informação muito específicas e muito pouca paciência para lag. Um dashboard projetado para um usuário casual de banco de varejo está errado para eles. A densidade de informação precisa ser maior, o tempo até a informação-chave precisa ser menor e os dados precisam estar visivelmente atualizados.
A lição mais valiosa naquele contexto foi sobre atualidade dos dados. Quando os dados mudam a cada segundo, a tela precisa tornar impossível não perceber que algo está desatualizado: um feed que para de atualizar silenciosamente é pior do que um que mostra um erro, porque alguém vai agir com base no número desatualizado. A outra lição foi contenção nas animações. Com D3.js é fácil animar cada tick, e fazer isso torna uma tela impossível de acompanhar em minutos.
Um dashboard que mostra tudo não é otimizado para ninguém. Projete para a decisão, não para os dados.
Acessibilidade em visualização de dados
Dashboards financeiros têm um problema de acessibilidade que é específico da visualização de dados: gráficos são inerentemente visuais, e seu significado é inacessível para usuários de leitores de tela que recebem apenas o texto alternativo do gráfico. Essa é uma lacuna real que a maioria dos designers e desenvolvedores de dashboards não aborda adequadamente.
Minha prática atual: todo gráfico inclui uma visualização tabular de dados acessível via toggle, para que usuários de leitores de tela possam acessar os números subjacentes. O texto alternativo do gráfico não é 'Gráfico de barras mostrando dados de receita'. É um resumo conciso do insight principal: 'Receita cresceu 12% mês a mês, atingindo $4,2M em junho, o maior valor nos últimos 12 meses.' O texto alternativo conta a história que o gráfico está contando, não apenas que tipo de gráfico é.
Cor nunca é o único indicador de significado nos meus dashboards financeiros. Todo status que usa cor também usa um ícone ou um rótulo de texto. Isso é tanto um requisito de acessibilidade quanto uma melhoria prática de usabilidade. Dashboards são frequentemente visualizados em monitores com calibração de cor ruim, em ambientes de escritório com muita luz ou por usuários com deficiência na visão de cores. Projetar para essas condições beneficia todos os usuários.
Referências
- WCAG 2.1 non-text contrast. https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast
- Apache ECharts. https://echarts.apache.org/en/index.html
- Chart.js. https://www.chartjs.org/