# Arquétipos de dashboard — o padrão por tipo de tela

## Conteúdo

- Dispatch: pergunta da entrevista → arquétipo
- monitoramento-operacional
- visao-por-pessoa
- comparativo-temporal
- resumo-executivo
- demonstrativo-financeiro / DRE
- geo
- Convenções transversais

Este é **o padrão da skill** para cada arquétipo de dashboard: use as receitas
de layout como estão, e trate as armadilhas como regras de recondução (mesma
força das regras de integridade de `wireframe-kit.md`, skill `lumo-mockup`,
que valem para todos os arquétipos e não são repetidas aqui). Divergência do analista segue o protocolo
padrão de `calibracao-qualidade.md`: recomende → argumente uma vez → registre a
divergência. As citações "observado em dashboards reais em produção" são a evidência
de por que cada regra existe (destilada de ~24 telas reais + Few/IBCS) — quando
o analista pedir "faz igual ao dashboard X que já existe", aplique o padrão
daqui: aproveite da tela existente o que ela tem de conforme, reconduza o que
viola, e diga qual é qual. Nunca cite arquivo/cliente de origem.

## Dispatch: pergunta da entrevista → arquétipo

| Pergunta pra fazer na entrevista | Arquétipo |
|---|---|
| Quem vai olhar age agora sobre casos individuais (atende, entrega, resolve, cobra)? | monitoramento-operacional |
| O filtro natural da tela é uma PESSOA (vendedor, funcionário, responsável), não a empresa toda? | visao-por-pessoa |
| A pergunta é "como evoluímos" — comparar anos/períodos, meta vs. projeção? | comparativo-temporal |
| É pra reunião de diretoria — decidir em 1 minuto, sem scroll? | resumo-executivo |
| É controladoria/financeiro/benefícios — vocabulário contábil, conferência de valores? | demonstrativo-financeiro / DRE |
| Tem componente espacial — cobertura, expansão, distribuição territorial? | geo |

Um dashboard pode nascer "resumo-executivo" na intenção do analista e terminar "monitoramento-operacional" na execução (padrão recorrente nos dados — ver seção resumo-executivo). Reconduza pela pergunta acima, não pelo nome que o cliente deu à tela.

## monitoramento-operacional

**Quando usar:** público que AGE sobre o dado (supervisor de fila, PCP, gestor de estoque, dono de operação, gestor de frota) — a tela existe pra decisão do turno/dia, não pra leitura executiva.

**Receita de layout:** topo com 3-6 KPIs de totais/status (cor semântica ligada a threshold, ex. SLA verde/laranja/vermelho); meio com 1-2 gráficos de composição/ranking por dimensão operacional (pessoa, fila, produto, veículo); base sempre com tabela de detalhe linha-a-linha (às vezes PII mascarado). Filtros no topo, fora do corpo, SEMPRE com estilo de controle distinto do conteúdo (chip/dropdown — nunca card com número).

**Widgets característicos:** KPI+status com ícone semáforo, barra horizontal de ranking por operador/loja/veículo, linha para tendência intradiária, tabela de detalhe granular, ocasionalmente mapa.

**Regras deste arquétipo** (recondução obrigatória; evidência entre parênteses):
- É o arquétipo mais estourado em contagem de widgets — a maioria dos exemplares reais excede o teto, alguns tratando cada dimensão disponível como card próprio (chega a 25+ widgets numa tela só). Se o analista pedir "um card pra cada corte que a gente tem", reconduza: quem atua no dia a dia precisa de 5-7 cortes, não 20.
- Gráfico de barra com 1-2 categorias fazendo o papel de KPI (visto em fila/atendimento, delivery, cobertura territorial). Se o mockup só tem 1 barra, é KPI — não gasta espaço de gráfico com isso.
- Filtro com o mesmo estilo visual de card de dado (visto em atendimento e em fila de protocolo) — o usuário não distingue "isso eu clico pra filtrar" de "isso é conteúdo". Recomende estilo de controle sempre distinto (chip/dropdown), nunca card com número.
- Combo barra+linha em eixo duplo pra mostrar volume + tempo juntos. Reconduza pra 2 widgets separados sempre — eixo duplo é risco sistemático de correlação falsa.
- Tendência que acompanha só 1 KPI e cabe em ≤80px é **sparkline inline no próprio card** (`relacao: tendencia-inline`), não widget separado — reduz a contagem (o vício nº1 deste arquétipo) sem perder informação.

## visao-por-pessoa

**Quando usar:** uso de responsabilização/gestão individual — contas a receber por vendedor, headcount/RH por colaborador. O filtro principal é a pessoa, não a empresa.

**Receita de layout:** filtro de pessoa (dropdown, às vezes multi-select) no topo esquerdo + seletor de período à direita; linha de 3-4 KPIs; meio com composição em barra (faixas/buckets sempre em barra ordenada — nunca pizza) e ranking de pares; base com tabela nominal (nome, matrícula, valores individuais).

**Widgets característicos:** filtro de responsável/funcionário, KPI, barra ordenada de composição (demografia/aging), barra de ranking entre pares, tabela nominal detalhada.

**Regras deste arquétipo** (recondução obrigatória; evidência entre parênteses):
- Pizza aplicada a dado ORDINAL (faixa etária, faixa salarial, tempo de casa) — é o erro mais grave observado no lote inteiro: pizza esconde a progressão natural da faixa. Se o dado tem ordem (faixas, buckets), é sempre barra na ordem das faixas, nunca pizza.
- Título do widget não bate com o dado plotado (pizza rotulada "por cliente" mostrando na verdade faixas de vencimento/aging). Confira sempre: o título da ficha wireframe É a dimensão real, nunca aprove sem checar contra dados de exemplo.
- Uma categoria dominante esmaga as demais numa escala linear (uma unidade concentra quase todo o total, o resto vira ruído colado no zero). Recomende isolar o outlier num KPI próprio ou agregar cauda longa em "outros".
- Ícone de KPI sem relação semântica com a métrica. Se o ícone não reforça a métrica, recomende omitir.

## comparativo-temporal

**Quando usar:** a pergunta central é "como evoluímos" — tendência plurianual, comparação de cenários (ano corrente vs. anterior), realizado vs. projetado/meta.

**Receita de layout:** filtros de dimensão + seletor de período/"visão" no topo (às vezes um seletor que troca a lente de todo o dashboard, ex. valor total vs. participação); grid denso de gráficos comparativos por dimensão (grupo, vendedor, cidade…), sem tabela de transação individual.

**Widgets característicos:** barra agrupada para cenários discretos (anos, meta vs. realizado), linha para série contínua real, ranking Top-N complementar por dimensão.

**Regras deste arquétipo** (recondução obrigatória; evidência entre parênteses):
- Série de evolução anual/mensal em barra em vez de linha, repetida sistematicamente (visto num comparativo plurianual com 8 gráficos seguidos, todos em barra). Se o título diz "evolução"/"tendência", é linha — não vira regra "converter tudo pra barra só porque o resto do dashboard já é barra".
- Ordem do tempo invertida em barra horizontal anual (ano mais recente no topo, mais antigo embaixo) — inverte a leitura natural de progressão. Eixo temporal sempre cronológico crescente, mesmo em barra horizontal.
- Comparativo com dezenas de categorias × múltiplos anos em barra vertical fica ilegível (rótulos sobrepostos) e AINDA convive na mesma tela com um Ranking Top-N que já responde a mesma pergunta de forma legível — visto se repetindo em 4 dimensões diferentes no mesmo dashboard. Se a pergunta é "quem são os top N", o ranking já resolve; não aprove o comparativo ilegível ao lado dele.
- Real vs. projetado sem diferenciação visual dentro do gráfico de detalhe (só o KPI distingue por cor; dentro da série, o trecho projetado vira número idêntico repetido sem marca). Exija linha "hoje" ou tracejado pro trecho projetado sempre que houver projeção — honestidade visual IBCS.

## resumo-executivo

**Quando usar:** público é diretoria/gestão, promessa é "entender em 1 minuto, sem scroll" — reunião mensal, acompanhamento de meta.

**Receita de layout:** 1 linha de KPI (3-6, idealmente com destaque visual pro número mais importante); no máximo 2-4 gráficos de apoio; sem tabela de detalhe granular nem scroll.

**Widgets característicos:** KPI-row com variação/comparação, gráfico de meta-vs-realizado, mapa resumido (se geografia importa), no máximo 1 donut com ≤4 fatias (regra de `wireframe-kit.md`, skill `lumo-mockup`).

**Regras deste arquétipo** (recondução obrigatória; evidência entre parênteses):
- "Deriva analítica" é o padrão, não a exceção: a intenção é executiva mas a execução vira dashboard operacional com 10-19 widgets e tabelas densas — todos os exemplares reais deste arquétipo excederam o teto de 9, um deles ficando tão denso quanto um operacional. Se o pedido crescer além de 6 gráficos, proponha 2ª aba/dashboard operacional em vez de inflar este.
- Gauge/velocímetro aparece quase exclusivamente neste arquétipo (nunca nos operacionais) — reforça a proibição de `wireframe-kit.md`: é exatamente o público que mais precisa de leitura rápida, e o gauge é o widget que menos entrega por área de tela. Sempre reconduza para KPI+meta com variação, ou bullet chart.
- Mesmo corte de dado repetido em 3-4 formatos na mesma tela (gauge + tabela + barra + donut da mesma dimensão) sem responder pergunta nova. Escolha 1 representação por pergunta; se o analista quer "mostrar de vários jeitos", pergunte que decisão cada formato habilita.
- KPI sem indicação de variação/tendência (número isolado, sem seta nem comparação vs. período anterior ou meta). Todo KPI executivo carrega ▲/▼ + %, nunca número solto.
- Todo widget de dashboard executivo tem `mensagem` preenchida na ficha (IBCS/SAY: a conclusão, não só o rótulo) — a promessa de "entender em 1 minuto" depende disso; título 100% descritivo sem mensagem é recondução.

## demonstrativo-financeiro / DRE

**Quando usar:** controladoria, financeiro, billing, benefícios (odonto/saúde) — vocabulário contábil, leitura tabular pesada, conferência de valores.

**Receita de layout:** filtro de entidade (filial/conta) + período no topo; corpo dominado por tabela/pivot (linhas = contas, colunas = meses/métricas) ou múltiplas tabelas ranking lado a lado (fornecedor, centro de custo, produto); linha de evolução de resultado no rodapé, quando existe. KPI-row de abertura nem sempre está presente.

**Widgets característicos:** pivot/tabela contábil com subtotais destacados por cor, tabelas ranking, linha para evolução de resultado.

**Regras deste arquétipo** (recondução obrigatória; evidência entre parênteses):
- Pula direto pra tabela densa sem nenhum KPI de abertura — o primeiro elemento que o olho encontra já é a grade mais complexa da tela, o oposto do overview-first. Mesmo em demonstrativo financeiro, abra com 3-4 KPIs-âncora (receita líquida, resultado do mês) antes da grade.
- Efeito "kitchen sink": todo corte de compra/despesa vira widget próprio (visto passando de 16 e de 25 widgets em exemplares reais). Aplique corte Pareto (Top 10 + "outros") em vez de listar toda a dimensão.
- Pizza/donut com 7-10 fatias representando despesa por classificação/faixa (visto num demonstrativo de sinistralidade de plano de saúde) — mesma regra de `wireframe-kit.md`, barra ordenada substitui.
- KPIs de sinais opostos (custo, desconto, benefício, líquido) todos na mesma cor, sem distinção de sinal — caso real de dois KPIs com valor idêntico suspeito passando despercebido por estarem "camuflados" na mesma cor neutra. Cor semântica por sinal (+/-) é obrigatória quando há valores negativos ao lado de positivos na mesma linha de KPI.
- Combo barra+linha em eixo duplo pra combinar valor absoluto com ticket médio/margem % aparece com frequência neste arquétipo. Nunca eixo duplo — 2 widgets.
- Evolução de resultado que acompanha um KPI-âncora cabe como sparkline inline (`relacao: tendencia-inline`) em vez de mais um widget na tela já densa.

## geo

**Quando usar:** a pergunta central tem componente espacial — cobertura, distribuição territorial, expansão de canal, densidade de operação por região.

**Receita de layout:** filtro único no topo; mapa como elemento central e maior área de tela (coroplético pra visão de UF/macro, mapa detalhado de pontos pra visão municipal); ranking horizontal territorial complementar; raramente tem KPI-row.

**Widgets característicos:** mapa coroplético (macro), mapa de pontos/detalhado (micro), barra horizontal de ranking territorial.

**Regras deste arquétipo** (recondução obrigatória; evidência entre parênteses):
- Dois mapas (UF + cidade) mostrando a MESMA dimensão em granularidades redundantes, um deles quase vazio na prática. Se o pedido for "mapa de UF e mapa de cidade", pergunte se não é o mesmo mapa com drill-down — normalmente é, e resolve com 1 widget só.
- Falta de KPI-row antes do mapa — não há "por onde o olhar começa" na tela. Mesmo dashboard geo abre com 2-3 KPIs agregados (total coberto, % de cobertura) antes do mapa.
- Legenda de intensidade pequena/ilegível, dependente de hover pra ser interpretada. Legenda sempre visível e testada em tamanho de tela real, nunca só tooltip.
- Mesmo vício do monitoramento-operacional: gráfico de barra de 1 categoria fazendo o papel de KPI — se aparecer aqui, reconduza igual.

## Convenções transversais

**Convenções positivas — aplique como default:**
- Barra horizontal é o cavalo de batalha certo pra ranking categórico com labels longos — mantenha como default de ranking em qualquer arquétipo.
- Quando o autor reconhece uma série temporal real, ele sabe usar linha — o problema é falta de disciplina sistemática, e não desconhecimento (a mesma tela às vezes acerta e às vezes erra a mesma regra).
- Gauge é raríssimo nos dados reais (2 ocorrências em 24, ambas em resumo-executivo) — a proibição de `wireframe-kit.md` está alinhada com a prática real observada, e não é arbitrária.
- Cor semântica real aparece quando o contexto é financeiro/alerta explícito (atraso = vermelho, ok = verde, ligado a threshold) — use como referência positiva ao propor paleta na fase de wireframe.
- Existe um componente de KPI-row reconhecível entre produtos (ícone + número grande + label) — sinal de design system real na camada de widget; aproveite ao invés de inventar layout novo a cada projeto.
- Listas de alta cardinalidade viram tabela, não gráfico de barra forçado — a produção real não tenta espremer 50 categorias num chart.
- Toda tela declara 1 widget-âncora (a resposta mais importante) destacado por ≥1 atributo pré-atentivo — tamanho maior, posição top-left ou intensidade, nunca só cor de marca. Sem âncora, tudo tem o mesmo peso e nada é prioridade (o vício do kitchen-sink).

**Proibições transversais — policie em todo wireframe:**
- Contagem de widgets: no dump bruto do banco a maioria parece estourar o teto,
  mas 81,8% desses widgets pertencem a recursos mortos (dashboards fora de
  uso) — filtrando pra cadeia de validade viva, só 26,9% dos dashboards
  excedem 9 widgets (p50=6; a cauda é o achado real: p99=24, máximo 71).
  Continua sendo o primeiro ponto a policiar, mas o alvo é achatar a cauda
  longa, não redesenhar a mediana — a maioria dos dashboards já está OK.
- Pizza sai como default da PLATAFORMA, não escolha deliberada do analista:
  sem configurar nada, o widget de pizza nasce com `limitCount=10` — pizza de
  10 fatias. Em produção, 99% das pizzas têm mais de 4 fatias. Trate toda
  pizza no wireframe como o default cru vazando pro cliente até prova em
  contrário.
- KPI-row: o problema real é AUSÊNCIA, não posição — quase metade das telas
  reais (44%) não tem nenhum KPI. Quando o KPI existe, a posição quase sempre
  acerta (y=0 na esmagadora maioria dos casos); não gaste revisão policiando
  posição de algo que raramente erra — gaste checando se o KPI-row existe.
- Paleta de cor sem sistema — a mesma cor significa coisas diferentes em widgets diferentes da mesma tela; nenhuma cor é reaproveitada com significado constante.
- Ícones decorativos sem relação semântica com a métrica — viram ruído visual repetido em vez de reforço de leitura.
- Redundância: a mesma dimensão aparece frequentemente em 2-4 widgets diferentes (tabela + barra + mapa + gauge/pizza) sem responder pergunta nova — sintoma direto de falta de curadoria na entrevista, não de necessidade real do público.
- Datalabels aplicados por padrão em toda série densa (todo ponto, toda hora, todo dia) em vez de seletivamente (picos, vales, último ponto) — chart junk que compete com a própria forma do gráfico.
