A visualização de dados fica no encontro de duas disciplinas que nem sempre conversam entre si: data e design. Muitos dashboards são tecnicamente corretos, mas pouco eficientes na comunicação. Eles mostram os números certos e, ainda assim, não conseguem gerar uma decisão, apontar uma direção ou provocar uma mudança de entendimento.

O cenário muda quando o pensamento estruturado de UX é aplicado a dashboards e apresentações de dados, desde as perguntas feitas antes mesmo de abrir qualquer ferramenta até as decisões que determinam se um insight realmente será compreendido.

Hoje, nunca houve tanta disponibilidade de dados dentro das organizações. Dashboards e apresentações de performance existem para praticamente todas as áreas — vendas, produto, marketing, operações — e as ferramentas para construí-los nunca foram tão acessíveis.

Ainda assim, em reuniões semanais e revisões trimestrais, uma situação continua se repetindo: alguém apresenta os números, todos concordam com a cabeça e a reunião termina sem uma decisão ou uma direção clara.

Quando isso acontece, a culpa costuma cair sobre os dados. Os números não eram detalhados o suficiente, o dataset estava incompleto ou seria necessário reunir mais informações antes de agir.

Mas, na maioria das vezes, o problema não está nos dados.

O problema é que ninguém projetou a apresentação para gerar insights. O gráfico foi construído a partir do que estava disponível, e não da pergunta que precisava ser respondida. O público foi presumido, em vez de compreendido. E uma questão fundamental sequer foi feita: o que deveria mudar depois que essas pessoas vissem esses dados?

Visualização de dados e UX tentam resolver, no fundo, o mesmo problema: entregar a informação certa para a pessoa certa de uma forma capaz de provocar alguma mudança.

O vocabulário pode ser diferente, mas o desafio é essencialmente o mesmo. Quando as duas disciplinas passam a ser tratadas como complementares, dashboards deixam de ser uma coleção passiva de gráficos e passam a cumprir uma função real.

Para designers que trabalham com dados, analistas que precisam apresentar informações para públicos não técnicos e profissionais de marketing que querem que seus números façam mais do que simplesmente ocupar um slide, essa abordagem é especialmente importante.

O gráfico nunca foi a história inteira

Em 1973, o estatístico Francis Anscombe publicou um estudo que demonstrava um ponto simples, mas extremamente revelador.

Ele construiu quatro datasets estatisticamente idênticos: mesma média, mesma variância, mesmo coeficiente de correlação e mesma linha de regressão. Ao analisar apenas os números, os quatro conjuntos parecem iguais.

Quando são transformados em gráficos, porém, tornam-se completamente diferentes.

A lição de Anscombe para os estatísticos estava relacionada ao diagnóstico: a visualização revela uma realidade operacional que os números brutos podem esconder.

O chamado Quarteto de Anscombe demonstra justamente isso. Quatro datasets com as mesmas estatísticas resumidas produzem quatro scatterplots completamente distintos quando visualizados.

Mas a visualização não tem apenas uma função diagnóstica. Ela também é uma ferramenta de comunicação.

É na escolha da forma visual que a compreensão pode surgir ou desaparecer em meio ao ruído. A pergunta passa a ser: o público termina a apresentação apenas lembrando de alguns números ou sai dela com uma história que conseguirá repetir e discutir com outras pessoas?

Um bom exemplo disso é o projeto History of Pandemics, do Visual Capitalist.

Em vez de apresentar uma enorme tabela com números de mortes, o projeto organiza as principais pandemias da história em uma única timeline e utiliza bolhas proporcionais para representar o número de vítimas de cada evento.

Antes mesmo que o cérebro leia qualquer número, o sistema visual humano consegue compreender a dimensão da Peste Negra em comparação com praticamente todos os outros eventos apresentados.

Uma boa visualização não apenas coloca os dados em um gráfico. Ela torna a história impossível de ignorar.

Edward Tufte consolidou um dos princípios fundamentais da área com o conceito de data-ink ratio: cada elemento visual de um gráfico deve contribuir para representar os dados, e não simplesmente decorá-los.

O conceito continua sendo uma referência importante em visualização de dados e parte da ideia de que clareza e limpeza visual devem ser objetivos centrais.

Para um gráfico analisado isoladamente, isso faz bastante sentido.

O problema é que um gráfico quase nunca é interpretado de forma isolada.

Ele é visto por uma pessoa, dentro de um contexto específico e, muitas vezes, sob determinada pressão.

Ao reduzir um gráfico até sua forma mais simples possível, existe o risco de remover justamente a camada de contexto necessária para que alguém consiga tomar uma decisão.

A simplicidade, portanto, não deve ser tratada como objetivo absoluto. O objetivo deve ser encontrar o nível adequado de complexidade.

Dados são uma mensagem, e a quantidade correta de sinal depende inteiramente de quem está recebendo essa mensagem.

Esse raciocínio leva a um dos principais fundamentos de data UX: aproximadamente 80% do trabalho que determina se um dashboard terá sucesso acontece antes mesmo de qualquer gráfico ser desenhado.

Os 80% que acontecem antes do gráfico

A parte de maior impacto do trabalho quase nunca acontece na tela.

Ela acontece antes de qualquer ferramenta ser aberta, antes de qualquer dataset ser carregado e antes de qualquer decisão visual ser tomada.

Tudo começa com três perguntas fundamentais. Quando elas passam a fazer parte do processo, também mudam aquilo que o profissional observa, questiona e contesta logo no início de cada projeto.

• Contexto: o que estamos tentando mostrar com esses dados?

É nesse momento que se define qual função as visualizações realmente precisam cumprir antes mesmo de trabalhar com os dados brutos. Registrar com precisão as perguntas operacionais que precisam ser respondidas, em um nível de detalhe suficiente para determinar quais dados serão utilizados e quais serão filtrados, é o que permite construir um dashboard capaz de apoiar decisões.

• Público: para quem estamos criando isso e como essas pessoas pensam?

Essa é a etapa de empatia. Saber quem estará diante da informação, por quais resultados essas pessoas são responsáveis e como costumam lidar com dados determina o nível de complexidade que a visualização pode apresentar e a maneira como ela deve ser estruturada.

• Insight: o que deveria mudar depois que esses dados forem apresentados?

Pode ser uma decisão, uma nova direção ou uma mudança de compreensão. Se o resultado estratégico esperado não estiver claro durante a etapa de design, dificilmente aparecerá depois que o dashboard estiver pronto.

Contexto: o que estamos tentando mostrar com esses dados?

Muitos projetos que envolvem grandes volumes de dados começam ao contrário.

As equipes extraem todas as métricas que suas ferramentas internas de analytics já acompanham e constroem visualizações em torno delas. Enquanto isso, a pergunta que os dados deveriam responder acaba sendo presumida ou simplesmente nunca é feita.

Isso acontece porque existe uma tendência natural de tratar os dados disponíveis como o limite daquilo que pode ser explorado.

Definir primeiro um objetivo parece óbvio, mas, na prática, raramente isso acontece com o nível necessário de clareza.

“Mostre como o produto está performando” não é um objetivo específico.

“Identifique quais funcionalidades aumentam a retenção entre usuários que se cadastraram no primeiro trimestre” é.

A segunda formulação inclui três elementos que a primeira não apresenta: uma métrica, uma população e uma ação implícita.

É esse nível de especificidade que transforma uma investigação aberta em um problema de design delimitado e possível de responder.

O ponto de partida determina tudo o que vem depois: quais informações serão incluídas, quais comparações realmente importam e quais elementos podem ser completamente deixados de fora.

Começar pelos dados disponíveis produz um dashboard que não responde nenhuma pergunta específica, justamente porque ele nunca foi criado para isso. Todos os números estão presentes, mas nenhum aponta para uma direção.

Começar pela pergunta operacional produz o efeito inverso. Cada elemento presente na tela precisa justificar sua existência porque está ali para ajudar a responder a uma questão específica.

Imagine, por exemplo, uma equipe de UX tentando corrigir problemas de abandono no checkout de um e-commerce.

Uma abordagem data-first poderia reunir tudo o que estivesse disponível: cliques, profundidade de scroll, tipos de dispositivos e diversas outras métricas. O resultado seria um enorme dashboard que provavelmente deixaria todos com a mesma pergunta: “Certo, mas o que exatamente precisamos mudar?”

Uma abordagem context-first começa com uma restrição clara: “Em qual etapa do checkout os usuários abandonam o processo?”

Ao eliminar 90% do ruído, a equipe pode construir um funnel simples, identificar imediatamente um gargalo na tela de pagamento e saber exatamente qual parte da experiência precisa ser redesenhada.

Público: para quem estamos criando e como essas pessoas pensam?

Projetar uma visualização para determinado público depende principalmente de dois fatores: familiaridade e responsabilidade.

Familiaridade está relacionada ao nível de data literacy daquele público.

Essas pessoas interpretam gráficos de forma intuitiva ou uma visualização complexa cria uma barreira adicional?

Entregar o mesmo dashboard detalhado para um Head of Sales e para um analista sênior seria como oferecer o mesmo mapa para uma pessoa que se orienta por pontos de referência e outra que navega utilizando coordenadas.

Os dados continuam corretos, mas a apresentação pode ser realmente funcional para apenas uma delas.

Responsabilidade determina como essa complexidade deve ser apresentada.

Um gráfico mostrando uma queda de 12% tem um peso muito diferente para o executivo responsável por aquele resultado e para o analista cuja função é simplesmente reportar os dados.

Compreender o público também significa entender essa relação. Dados raramente são processados de maneira completamente neutra quando a própria performance de quem está olhando para eles está em jogo.

Familiaridade e responsabilidade, quando consideradas juntas, ajudam a determinar uma questão bastante prática: quanto conteúdo pode ser colocado diante daquela pessoa.

Em visualização de dados, simplicidade não é uma virtude absoluta. O nível adequado depende de quem está lendo e do que essa pessoa precisa fazer com a informação.

Um analista, por exemplo, depende de um ambiente com alta densidade de informações para realizar investigações diagnósticas.

Ao isolar comportamentos específicos e mapear os fluxos brutos dos usuários, ele consegue analisar os dados em um nível granular e encontrar insights ocultos ou investimentos com baixa performance que poderão influenciar campanhas futuras.

Um executivo, por outro lado, precisa de uma tradução altamente sintetizada dessas mesmas informações para identificar rapidamente aquilo que está impulsionando o crescimento comercial.

Adaptar um dashboard ao público significa ajustar esse controle de densidade, entregando o máximo possível de sinal dentro de um nível de complexidade adequado à pessoa que precisa tomar a decisão.

Insight: o que deveria mudar depois que esses dados forem apresentados?

Muitos projetos de dados trabalham com uma premissa confortável: se um gráfico estiver correto e claro, o insight surgirá naturalmente.

Na prática, informação e insight são coisas completamente diferentes.

Informação é aquilo que os dados mostram.

Insight é a decisão específica, a mudança de compreensão ou a correção de rota que alguém realiza como consequência de ter visto aquela informação.

Se a mudança esperada no negócio não estiver definida antes do início do design, o dashboard provavelmente acabará funcionando apenas como uma ferramenta passiva de reporting, em vez de impulsionar uma ação.

Equipes de marketing e engenharia vivenciam o risco dessa diferença sempre que alguma métrica central do negócio sofre uma queda repentina.

Um dashboard construído apenas para informar funciona como um alarme. Imagine um gráfico mostrando uma queda acentuada de 15% na taxa de reservas.

Como os dados não apresentam profundidade suficiente, a liderança pode entrar imediatamente em modo de crise e chamar a equipe de UX, presumindo que o aplicativo está com algum problema ou que o checkout possui uma falha.

Como a visualização não identifica a origem do problema, ela pode disparar uma mobilização cara e completamente equivocada.

Um dashboard construído para gerar insight isola as variáveis necessárias para uma decisão informada.

Em vez de mostrar apenas uma métrica isolada de reservas, a visualização relacionaria a queda às fontes de tráfego e aos lançamentos de campanhas.

Isso poderia revelar imediatamente que a performance do aplicativo e a conversão dos usuários principais permanecem estáveis, enquanto a taxa geral do site foi artificialmente reduzida por uma grande entrada de tráfego de baixa intenção proveniente de uma campanha recém-escalada.

Nesse cenário, a equipe deixa de perder tempo redesenhando um aplicativo que funciona corretamente.

Ela recebe exatamente o insight necessário para interromper uma campanha de marketing com baixa performance e ajustar sua estratégia de aquisição.

Toda visualização sugere um próximo passo, mesmo quando esse passo é simplesmente “nada precisa mudar neste momento”.

A questão é se o design deixa essa implicação suficientemente clara para que o público consiga percebê-la.

Das perguntas ao dashboard: como esse processo funciona na prática

Um projeto para uma plataforma B2B SaaS voltada à gestão de talentos corporativos e ao acompanhamento de competências ajuda a demonstrar como esse pensamento pode ser aplicado.

A plataforma registrava uma enorme quantidade de telemetria diariamente, e o briefing inicial era bastante aberto: havia um grande arquivo de atividades dos usuários e era necessário encontrar uma forma de apresentar essas informações às equipes corporativas.

Seria fácil simplesmente transformar tudo o que estava sendo registrado em gráficos.

Mas isso apenas criaria um cemitério de dados para os usuários.

O desafio deixou rapidamente de ser apenas construir uma boa interface e passou a ser arquitetar uma ferramenta prática para pessoas reais, que acessariam aquele dashboard regularmente e precisariam obter uma leitura honesta e imediata sobre seus próprios workflows.

Contexto

A empresa acreditava que aquele grande volume de dados poderia ajudar os usuários a melhorar sua performance e queria uma interface capaz de permitir esse desenvolvimento.

Transformar uma ambição tão ampla em visualizações concretas exigia definir primeiro quais eram, na prática, os mecanismos de performance.

Quais variáveis indicavam evolução e quais representavam apenas uso passivo? O que significava exatamente “performar melhor”? Como isso poderia ser medido?

Uma possibilidade óbvia era acompanhar o tempo gasto em cada produto.

Praticamente todas as plataformas conseguem medir esse dado. É fácil de visualizar e parece uma informação relevante.

Mas o tempo de uso é apenas uma proxy. Ele indica que alguém esteve utilizando determinado produto, mas não revela necessariamente se aquela experiência gerou algum resultado.

Sinais mais relevantes eram os scores de competência por área, taxas de conclusão de certificações e trajetórias históricas de performance.

Integrar o tempo de uso a essas métricas acrescentava uma camada útil de interpretação, permitindo identificar quais módulos estavam sendo pouco utilizados e se isso apresentava alguma relação direta com scores abaixo do esperado.

O tempo gasto na plataforma deixou de ser a história principal e passou a funcionar como um sinal de apoio dentro de uma narrativa maior.

A segunda questão estava relacionada ao nível adequado de granularidade.

Uma mesma métrica pode assumir significados completamente diferentes dependendo de quem está observando.

Um profissional acompanhando sua própria taxa de conclusão precisa entender se está avançando no ritmo esperado.

Um gestor analisando dados agregados da equipe precisa identificar exatamente quem necessita de suporte imediato.

Essa diferença orientou todas as decisões posteriores relacionadas à exposição e à filtragem dos dados.

Definir essa estrutura narrativa logo no início determinou exatamente o que deveria ser mostrado e para quem.

Público

Uma solução previsível para esse tipo de projeto seria utilizar os mesmos gráficos em duas versões: uma visão individual e outra visão agregada da equipe.

Muitos dashboards utilizam esse atalho, fazendo pequenas alterações na escala das mesmas visualizações e chamando isso de “personalização”.

Uma análise real do público, porém, revela diferenças muito mais profundas.

Líderes de equipes e colaboradores individuais precisavam de estruturas narrativas e princípios de design distintos.

Para o profissional individual, o workspace precisava funcionar como um espelho altamente personalizado e autodirigido, oferecendo uma leitura granular, honesta e pessoal sobre sua situação.

A experiência deveria permitir que ele compreendesse imediatamente seu nível atual, seus principais pontos fortes e quais métricas estavam começando a apresentar queda.

A interface do gestor precisava funcionar de maneira diferente.

Em um primeiro momento, ela deveria ignorar milestones individuais e oferecer uma visão macro das vulnerabilidades da equipe.

O design precisava responder a outra realidade operacional: como o grupo está progredindo e onde estão as lacunas recorrentes?

Essa visão priorizava primeiro a situação agregada, mas mantinha um caminho intuitivo para aprofundar a análise e chegar à coordenação tática do dia a dia quando necessário.

Insight

A estratégia de insights foi definida ainda na fase conceitual, muito antes da criação de qualquer wireframe de gráfico.

A ideia de construir um registro passivo e extremamente denso de dados foi abandonada em favor de uma narrativa pensada em etapas.

Para os colaboradores individuais, o valor central era a autodireção.

A interface deveria permitir que alguém abrisse o sistema na manhã de segunda-feira e conseguisse imediatamente construir uma lista clara de prioridades para a semana.

Para os gestores, o objetivo era mudar fundamentalmente o momento em que as conversas operacionais aconteciam.

Eles deveriam receber informações suficientes para intervir antes que uma lacuna de competências evoluísse para uma falha crítica em algum projeto.

As visualizações precisavam indicar exatamente os momentos em que uma conversa entre pessoas poderia ser útil, alterando o workflow de uma lógica reativa, baseada na análise posterior dos problemas, para uma lógica de orientação preventiva.

Uma das funcionalidades mais relevantes acabou sendo justamente uma que não havia sido solicitada originalmente: a ferramenta de comparação.

Um dashboard para gestores e outro para colaboradores individuais são soluções relativamente previsíveis.

A questão menos óbvia surgiu ao considerar outra necessidade: e se um gestor quisesse comparar dois integrantes específicos da equipe utilizando as mesmas métricas, lado a lado?

Essa visualização surgiu de uma hipótese de design e acabou se tornando uma das funcionalidades com maior aceitação.

As decisões mais importantes do projeto, portanto, nem sequer estavam presentes no briefing original.

Elas envolveram capturar dados que a empresa ainda não havia pensado em solicitar e estruturá-los de forma a responder perguntas que os próprios stakeholders ainda não sabiam formular.

Esse é um dos principais diferenciais de uma estratégia de dados realmente centrada no usuário.

Construindo o mental model desde o início

A escolha do formato de visualização precisa acompanhar a própria natureza geométrica dos dados.

Nesse projeto, um dos principais problemas de design era permitir que um usuário individual respondesse imediatamente a uma pergunta: entre oito áreas distintas de competência, onde estão meus pontos fortes e minhas principais lacunas?

Para resolver isso, os dados foram organizados em um radar chart.

Ao distribuir múltiplas variáveis em eixos que partem de um ponto central utilizando coordenadas polares, a interface conecta os diferentes dados e forma uma única figura.

Um polígono equilibrado comunica imediatamente uma proficiência consistente.

Uma forma bastante distorcida direciona rapidamente o olhar para uma área fora do padrão.

Um bar chart tradicional obrigaria o usuário a analisar oito barras separadamente e calcular mentalmente suas diferenças.

Já um layout radial concêntrico organiza as diferentes dimensões de maneira que o progresso e as lacunas de competência possam ser identificados mais rapidamente.

Quando todas as dimensões utilizam exatamente a mesma escala e o mesmo método de pontuação, o radar chart deixa de ser apenas uma opção estética diferente e se torna uma ferramenta funcional para análise multidimensional.

O sistema de cores foi outra decisão tomada ainda no início do projeto.

Durante o trabalho de branding, cada um dos três produtos recebeu uma cor específica.

Essas cores não ficaram restritas ao brand guideline. Elas foram incorporadas ao próprio modelo de dados desde o início e apareceram de maneira consistente em todos os gráficos, filtros e detalhamentos.

Quando o usuário acessava o dashboard pela primeira vez, o mental model já estava estabelecido.

Não era necessário ensinar aquela linguagem visual. Ele já a reconhecia.

O que mudou

A passagem de informação passiva para insight ativo apareceu primeiro na própria maneira como o dashboard passou a ser utilizado.

Depois da implementação dos dashboards personalizados e das ferramentas de comparação lado a lado entre integrantes das equipes, houve um aumento perceptível no engajamento semanal com os recursos de analytics da plataforma, segundo dados internos reportados pela empresa.

Os gestores deixaram de abrir a ferramenta apenas uma vez por mês para gerar relatórios estáticos.

Ela passou a fazer parte do planejamento das segundas-feiras.

Receita e crescimento de usuários também avançaram na direção positiva durante os dois trimestres seguintes.

Como acontece na maioria dos projetos desse tipo, entretanto, é difícil isolar exatamente quanto dessa evolução pode ser atribuído especificamente ao dashboard, já que outras mudanças ocorreram simultaneamente.

A empresa também reportou que o churn da plataforma caiu para um dos níveis mais baixos já registrados.

A evidência mais clara do impacto, porém, veio do feedback qualitativo.

Os gestores relataram que, em vez de utilizarem os dados apenas para analisar um mês ruim depois que o problema já havia acontecido, as visualizações permitiam identificar rapidamente sinais de queda de performance e agendar uma conversa de acompanhamento antes que a situação se transformasse em uma lacuna realmente significativa.

Visualização de dados deve começar antes do design

O design de dados atinge todo o seu potencial quando a apresentação visual é tratada como uma escolha arquitetural feita no início do processo, e não como uma etapa de formatação aplicada depois que todo o resto já foi decidido.

Levar pensamento estruturado de UX para os dados transforma visualizações em ferramentas ativas de tomada de decisão e ajuda a garantir que cada gráfico, relatório e métrica esteja conectado a uma necessidade humana concreta.

• Definição upstream: cada escolha visual deve partir de uma pergunta operacional específica, em vez de simplesmente utilizar as métricas que já estão disponíveis.

• Densidade calibrada: o nível de complexidade deve ser ajustado diretamente à data literacy e à responsabilidade de quem receberá aquela informação.

• Insight orientado à decisão: os dados devem ser estruturados para revelar possíveis resultados estratégicos, em vez de simplesmente apresentar estatísticas isoladas, transformando sinais visuais em ações operacionais.

Na próxima vez em que surgir a necessidade de criar uma visualização de dados — seja um dashboard corporativo, um relatório executivo ou um infográfico voltado ao público —, vale a pena se afastar inicialmente das ferramentas de design e das plataformas de BI.

O primeiro esforço deve estar concentrado nas decisões humanas que existem por trás daquela tela.

Somente depois disso os dados deixam de funcionar como um registro passivo do passado e passam a ajudar a definir a direção do futuro.