Design de Painel de Controle que Gera Decisões, Não Vaidade

Terça-feira, 21h47. A notificação no Slack chega. "Ei, esse relatório está errado, nosso MRR aparece como 4,1M mas o Financeiro diz 4,3M, você pode verificar?"

Você abre o painel de controle. Não toca nele há sete meses. O campo de responsável diz "Sarah K" e Sarah saiu em outubro. Há 14 gráficos. Três deles afirmam mostrar MRR e todos discordam entre si. O último visualizador foi há três semanas, e era você, abrindo-o para compartilhar o link neste mesmo histórico de conversa.

Essa notificação não é um problema de qualidade de dados. É um problema de design. Provavelmente o seu problema de design, de uma implementação que você publicou durante um Sprint que já esqueceu.

A maioria das ferramentas de BI reporta silenciosamente o mesmo número: entre 60 e 80 por cento dos painéis de controle são abertos menos de cinco vezes em toda a sua vida útil. Os dados de uso do próprio Looker, os logs de administração do Tableau Server, as análises de taxa de adoção do Hex: o mesmo padrão em todos. O cemitério é maior do que o andar ativo. E cada painel morto ainda tem um custo: gasto com consultas no warehouse para a atualização agendada, erosão de confiança quando partes interessadas encontram números conflitantes e o seu calendário quando alguém o ressuscita às 21h47.

Este guia é a disciplina de design que mantém a sua contagem de painéis de controle estável ou em queda enquanto a confiança das partes interessadas cresce. É habilidade de IC, não teatro de fornecedor de BI.

Os princípios que eliminam a "pia de cozinha"

Antes de qualquer regra específica, três princípios. Se você os internalizar, o restante se escreve sozinho.

Uma decisão por painel de controle. Escreva a decisão no título. Não "Visão Geral de Vendas". Isso é um tópico, não uma decisão. Escreva "Devemos rever a previsão das vendas do Q3?" ou "Quais pipelines de AE precisam de revisão do gestor esta semana?" Se você não consegue escrever a decisão em uma frase, você não sabe para que serve o painel, e nem a pessoa que o abre. Tópicos se multiplicam. Decisões, não.

Hierarquia visual, não democracia visual. O número principal do painel de controle deve ser pelo menos 3x maior do que qualquer outra coisa na página. Estudos de rastreamento ocular sobre ferramentas de BI (Tableau Research, 2023) mostram que os usuários passam 60% dos primeiros 8 segundos no bloco maior. Se tudo tiver o mesmo tamanho, você disse ao usuário que nada é importante. Escolha o único número que responde à decisão. Deixe-o enorme. Todo o restante é evidência de suporte.

Disciplina de cores. Uma cor de destaque para a marca ou a métrica principal. Cinza para todo o restante. Vermelho e verde apenas para variação em relação a uma meta, nunca para séries categóricas. Se o seu gráfico "Receita por Região" tem barras vermelhas, verdes, azuis, amarelas e laranjas, você treinou o usuário de que o vermelho não significa nada. Então, quando o vermelho realmente significa "não atingimos o plano", isso não causa impacto. Cor é um orçamento finito. A maioria dos analistas o esgota no primeiro gráfico.

Esses três são a base. O restante é aplicação.

A regra das 5 métricas

Nenhum painel de controle é publicado com mais de 5 métricas primárias. Ponto final.

Esta é a regra que todos contestam e que todos erram ao contestar. O argumento é sempre o mesmo: "mas o VP quer ver X, e Y, e também Z". Tudo bem. Construa-os em algum lugar. Só não na mesma superfície da decisão.

Por que 5? A pesquisa sobre carga cognitiva (Miller, 1956, sim, o estudo do "número mágico sete", refinado por Cowan em 2001 para uma capacidade de memória de trabalho de 4, mais ou menos 1) é o piso. Em uma reunião, com alguém apresentando, com o Slack notificando, o limite prático é ainda menor. Um painel de controle com 14 blocos não é lido. É escaneado. O usuário escolhe os dois que parecem surpreendentes e ignora o restante. Você fez 12 blocos de trabalho para dois blocos de atenção.

A regra, aplicada:

• Se você tem 5 métricas primárias e alguém pede uma 6ª, você está construindo dois painéis de controle. Um atende à Decisão A, o outro à Decisão B. Divida.
• Se você não consegue decidir quais 5, você não decidiu qual decisão o painel atende. Volte ao passo um.
• Detalhamentos não são métricas. Um número clicável que abre uma análise mais aprofundada é uma métrica, não sete. Trate a contagem de blocos na superfície como o limite.
• Blocos de "referência" (uma definição, um carimbo de hora de atualização, um painel de filtros) não contam entre os 5. Apenas os blocos que a parte interessada lê para tomar a decisão.

Já publiquei painéis de controle com três métricas. Três. O CFO os abre semanalmente. Já publiquei painéis com onze métricas. O CFO abriu uma vez e pediu para eu "resumir o ponto principal". Esse é o mesmo painel falhando.

Contexto supera visualização, sempre

Aqui está a heresia: um número com um diagnóstico escrito supera um belo gráfico sem narrativa. Sempre.

"MRR: 4,18M (-4,2% MoM)" com uma anotação de uma linha ("Queda causada por 3 churns de enterprise na EMEA, todos os três sinalizados no QBR; receita de expansão de 2,1M compensa o resultado líquido para -1,8%") é mais útil do que o gráfico de linhas mais bonito do mundo. Porque o gráfico mostra que algo aconteceu. A anotação diz o que aconteceu, por que e se há motivo para entrar em pânico.

Torne esta uma regra para cada bloco que vai em um painel de controle que um humano vai ler: uma linha dizendo "o que mudou e por quê". Não um parágrafo. Uma linha. Se você não consegue escrevê-la, o bloco não está pronto para ser publicado.

Esta é a parte que a maioria dos analistas pula porque parece redação, não análise. É análise. O ato de escrever "queda de 4,2% por causa de três churns de enterprise na EMEA" força você a realmente responder à pergunta em vez de apresentar o gráfico e ir embora. Se a resposta for "ainda não sei", isso também é uma anotação válida. "Queda de 4,2% MoM, causa raiz a ser apurada até sexta-feira, veja #data-investigations" diz à parte interessada que você viu, está cuidando disso e ela não precisa te notificar. Essa notificação que você não recebe é a linha de texto de maior ROI que você vai escrever na semana.

Ferramentas que facilitam isso: os blocos de texto ao lado de blocos de gráfico do Hex, o bloco HTML do Looker com um comentário de template, as dashboards do Tableau com uma nota de texto por bloco. Todas suportam o padrão. Nenhuma o impõe. Você o impõe.

A análise pós-incidente do pânico "esse relatório está errado"

Em algum momento uma parte interessada vai questionar um número. Não é opcional. A questão é se você lida com isso como um profissional ou como alguém tentando ganhar um debate no Slack.

Aqui está o protocolo. Memorize-o. Vai salvar a sua carreira pelo menos duas vezes.

Passo 1. Reconheça em 5 minutos, não em 5 horas. "Recebi, estou verificando, respondo até o fim do dia com o que encontrar." Essa é a mensagem inteira. Não defenda. Não argumente. Não explique por que o seu número está certo antes de você ter realmente verificado. A ansiedade da parte interessada cai no momento em que ela vê "estou verificando".

Passo 2. Confirme a consulta. Abra o SQL subjacente. Execute-o do zero. Você reproduz o número do painel de controle? Se sim, o painel não está mentindo. Ainda há uma questão sobre se a consulta está correta, mas a superfície é consistente. Se não, você tem um problema de cache ou agendamento; sinalize e atualize.

Passo 3. Confirme a fonte da verdade. O que o Financeiro, o RevOps ou o sistema de registro diz? A sua coluna mrr é derivada de subscriptions.amount ou de uma view materializada monthly_recurring_revenue construída em 2022 por alguém que saiu? O Financeiro está consultando o Stripe diretamente enquanto você está consultando um sync do Fivetran com 6 horas de latência? 90% dos chamados "esse relatório está errado" se resolvem aqui, e a resolução raramente é "o painel está errado" ou "o Financeiro está errado". É "estamos calculando duas coisas ligeiramente diferentes e chamando ambas pelo mesmo nome".

Passo 4. Documente a discrepância. No template de análise pós-incidente, preencha: carimbo de hora do relatório, consulta utilizada (cole), valor da fonte da verdade, valor do painel, causa raiz (divergência de definição, dados desatualizados ou bug real), correção (nova execução, mudança de definição ou nova anotação) e comunicação à parte interessada.

Passo 5. Publique uma correção ou uma ressalva em 24 horas. Ou você corrige o problema subjacente, ou adiciona uma anotação no nível do bloco explicando a diferença. Ambos são aceitáveis. O que não é aceitável é deixar o problema de lado enquanto duas partes da organização continuam operando com números diferentes.

Nunca discuta em históricos do Slack. Discussões em históricos são como os analistas ganham a reputação de "defensivos". Mova a conversa para o documento de análise pós-incidente em até 30 minutos. O documento é o artefato. O histórico é o ruído.

Mantenho um registro de cada análise pós-incidente de pânico que já publiquei. Relê-los é o único exercício de desenvolvimento de habilidades que faço. Consigo ver exatamente quais divergências de definição continuam se repetindo (é sempre reconhecimento de receita, sempre) e onde investir em correções upstream. Cada pânico também é um sinal sobre qual bloco precisa de uma anotação permanente para que a próxima pessoa não precise notificar.

A taxa de adoção é a métrica que prova que o painel funciona

O painel de controle que você construiu no trimestre passado: está funcionando? A maioria dos analistas não consegue responder essa pergunta, o que é desconcertante porque somos profissionalmente obcecados com mensuração.

Instrumente a taxa de adoção. Toda ferramenta de BI tem os dados:

• Looker tem System Activity, um Explore interno. history.query_run_count, dashboard.view_count, user.id, todos consultáveis.
• Tableau Server / Cloud tem o projeto Admin Insights. views_workbooks e views_dashboards mostram aberturas por ativo por usuário.
• Hex tem análises de uso integradas na página de configurações do workspace.
• Mode tem a Discovery API e relatórios de administração.
• Power BI tem relatórios de métricas de uso por workspace.

Rastreie três números por painel de controle, mensalmente:

1. Visualizadores únicos. Não aberturas. Humanos. Um painel com 200 aberturas de 2 visualizadores é uma aba que alguém deixou fixada, não um painel funcional.
2. Tempo no painel. Um painel que ninguém rola é um painel que ninguém lê. A maioria das ferramentas de BI registra a duração da sessão; menos de 30 segundos significa que o usuário abriu e saiu.
3. Taxa de retorno de visualizadores. Dos visualizadores do mês passado, quantos voltaram este mês? Os visualizadores recorrentes são o público real. Todos os outros vieram uma vez e seguiram em frente.

Um painel com menos de 3 visualizadores únicos por mês, por dois meses consecutivos, é candidato à descontinuação. Não um "candidato à reformulação de design". Um candidato à descontinuação. Pare de otimizar coisas que ninguém abre.

O exercício mais útil que realizo trimestralmente: classificar todos os painéis que mantenho pelo número de visualizadores recorrentes. Os 5 primeiros recebem meu tempo e cuidado. Os 5 últimos passam por uma revisão de descontinuação. O meio recebe negligência benevolente, o que está ótimo. Negligência é barata, descontinuação é honesta e cuidado ativo é caro. Gaste onde há retorno.

A revisão de descontinuação de 6 meses

Descontinuação é uma funcionalidade, não uma falha. Adote isso e você nunca mais se sentirá mal por eliminar um painel de controle.

A cada seis meses, você faz a varredura. Reserve uma manhã. Puxe os dados de taxa de adoção para cada painel no seu espaço. Ordene por visualizadores únicos, em ordem crescente. Depois:

1. Qualquer coisa com menos de 3 visualizadores por mês nos últimos 6 meses: arquive. Não delete. Arquive. Mova para uma pasta oculta, deixe um aviso em #data-archive anunciando o que foi movido, com o link da lista de arquivos. Se alguém reclamar, você pode restaurar em 60 segundos. Ninguém vai reclamar. Eles não abriram.
2. Qualquer coisa com 3 a 10 visualizadores por mês: reconfirme a responsabilidade. Notifique o responsável nomeado. "Ainda é responsável por este painel? Ainda é relevante? Ainda tem uma decisão nomeada?" Se o responsável saiu, você é o novo. Decida se vale manter ou enviar para o arquivo. Sem resposta em uma semana, arquive.
3. Qualquer coisa com mais de 10 visualizadores por mês: mantenha, audite as anotações dos blocos, atualize os números desatualizados e atualize a decisão no título se o negócio mudou. Esses são a sua superfície real. Merecem manutenção.
4. Publique a lista de eliminados publicamente. Uma mensagem curta no canal de dados da organização: "Varredura concluída: 12 painéis arquivados, 47 mantidos, aqui está a lista." Três coisas acontecem. (a) Ninguém reclama porque nada que realmente usavam desapareceu. (b) Outras equipes veem a cadência e começam a fazer a própria varredura. (c) A liderança percebe que alguém está tratando a instância de BI como infraestrutura, não como depósito.

Na primeira vez que fiz uma varredura assim em uma empresa anterior, arquivei 38 painéis. Duas pessoas me notificaram, ambas sobre o mesmo painel, que restaurei em três minutos. Essa é a superfície total de risco. A recompensa foi uma instância de BI que carregava mais rápido, tinha resultados de busca mais claros e visivelmente menos históricos de Slack com "espera, qual é o painel de receita real?".

Em seis meses, a sua instância de BI deve ter menos painéis do que hoje. Não mais. Se tiver mais, a disciplina de design não está funcionando e a cadência de descontinuação está sendo ignorada. Ambos são corrigíveis. Ambos são trabalho seu.

Modelos para usar

Especificação de uma página do painel de controle. Preencha antes de construir:

• Decisão que este painel responde: (uma frase, termina com um verbo)
• Público: (cargo nomeado, não "partes interessadas")
• 5 métricas primárias, por prioridade: (1, 2, 3, 4, 5)
• Cadência de atualização: (tempo real, por hora, diária, semanal; compatível com a velocidade da decisão)
• Responsável: (humano nomeado, não uma equipe)
• Critérios de encerramento: ("arquivar se menos de 3 visualizadores únicos por mês durante 60 dias")

Template de análise pós-incidente. Preencha dentro de 24 horas de cada questionamento:

• Relatado por quem, quando, em qual canal
• Número esperado pela parte interessada vs número no painel
• Consulta utilizada (cole o SQL completo)
• Comparação com a fonte da verdade (valor do Financeiro, do RevOps ou do sistema)
• Causa raiz (definição, atualização, bug, erro do usuário ou realmente correto)
• Correção publicada (link para PR ou anotação)
• Comunicação de volta à parte interessada (cole a resposta)

Checklist da revisão de 6 meses. Reserve uma manhã e execute a varredura:

• Puxar dados de taxa de adoção para todos os painéis sob responsabilidade
• Ordenar em ordem crescente por visualizadores únicos
• Arquivar: menos de 3 visualizadores por mês durante 6 meses
• Reconfirmar responsabilidade: de 3 a 10 visualizadores por mês
• Auditar e atualizar: mais de 10 visualizadores por mês
• Publicar a lista de eliminados publicamente
• Atualizar o registro de descontinuação (data, contagem arquivada, contagem mantida)

Esses três documentos representam 90% da higiene de painéis de controle. Imprima-os. Fixe-os. Use-os.

Erros comuns

Alguns padrões que vejo repetidamente em todas as equipes:

• Construir a partir da solicitação, não da decisão. A parte interessada diz "quero um gráfico de conversão por origem". Você constrói. Você publica. Seis semanas depois, ninguém abre, porque a decisão real era "devemos continuar pagando pelo contrato com o Google Ads?", e isso precisava de CAC por origem mais sobreposição de retenção, não de um gráfico de barras de conversão. Sempre pergunte a decisão antes de escrever o SQL.
• O painel executivo com 14 blocos porque o VP "quer ver tudo". O VP não quer ver tudo. O VP quer se sentir informado e encontrar as duas surpresas. Dê a ele um painel com 5 blocos e um resumo escrito de uma linha no topo, e ele vai agradecer. Provavelmente vai te promover, eventualmente.
• Paletas arco-íris. Oito séries, oito cores, todas com a mesma saturação. O usuário não lê nada. Use uma cor de destaque, deixe todo o restante em cinza e destaque apenas a série da qual a decisão depende.
• Nunca descontinuar, só adicionar. Esta é a morte lenta. A cada trimestre, a contagem aumenta. A cada trimestre, a qualidade média do painel cai. Seis meses depois, a instância de BI é impossível de buscar e três painéis diferentes dizem três coisas diferentes sobre o MRR. A correção é a cadência de varredura. Sem ela, você está acumulando dívida técnica para sempre.

Como é o "bom"

Você internalizou isso quando:

• Cada painel de controle que você mantém tem uma decisão nomeada no título, não um tópico.
• Você consegue listar, de memória, os seus 5 painéis com maior taxa de adoção e os 5 candidatos à descontinuação.
• As notificações "esse relatório está errado" diminuem trimestre a trimestre, porque cada bloco tem um diagnóstico escrito que a parte interessada lê primeiro.
• A instância de BI tem menos painéis em 6 meses do que hoje, não mais.
• O seu documento de análise pós-incidente tem pelo menos 5 entradas do último ano e você consegue apontar a correção upstream que saiu de cada uma.

Essa é a barra. Não "construí mais painéis". Não "as partes interessadas adoram meus gráficos". É: publiquei superfícies que as pessoas usam, documentei as falhas e eliminei as que não mereciam seu espaço.

Design de painel de controle não é um exercício estético. É um exercício de orçamento de atenção. Cada bloco custa a atenção de uma parte interessada. Cada painel custa o seu tempo de manutenção. Gaste ambos como se fossem escassos, porque são.

Saiba Mais

• Gestão de Partes Interessadas para Data Analysts
• SQL e Modelagem de Dados que Escalam
• Métricas do Data Analyst: Tempo até o Insight, Taxa de Adoção e Impacto
• Modelo de Descrição de Cargo para Data Analyst