O Dashboard Canvas é a evolução de canvases de BI desenvolvidos por Paulo André Jesus ao longo de atendimentos consultivos e aulas. Em vez de partir pelo gráfico, o método conduz a equipe a responder, bloco a bloco, por que o dashboard existe, para quem ele serve e de onde seus dados vêm.
A maior parte do retrabalho em BI vem de começar a tela antes de entender a pergunta. A anamnese transforma o projeto em um documento vivo, não em uma série de suposições.
Desorganização e falta de planejamento
Dashboards começam pela tela, não pela pergunta de negócio. Resultado: muitos visuais, pouca utilidade.
O Canvas obriga a responder Problema, Nível de Decisão e Contexto de Uso antes de qualquer gráfico.
Falta de documentação
Regras de cálculo, origens e premissas ficam na cabeça de uma pessoa.
Cada bloco gera um registro estruturado que vira entregável em PDF ou Markdown.
Integração de dados problemática
Fontes surgem no meio do projeto, atrasando modelagem e cálculos.
Origem dos Dados, Frequência e Horários são mapeados antes da construção.
Visualização confusa ou desalinhada
Relatório bonito que não responde a pergunta do stakeholder.
O Canvas 2 separa narrativa, hierarquia visual e elementos de página.
Ausência de revisão e otimização
Dashboards entregues e abandonados, sem versionamento.
Salvar Versão gera histórico, log de mudanças e incremento automático de versão.
De onde vem o método
A lógica de canvas vem do planejamento visual em blocos: cada área de negócio ganha uma célula, e a relação entre elas revela falhas de estratégia. Ao aplicar essa ideia a BI, o Dashboard Canvas torna explícito o que geralmente fica implícito: a doria, a decisão, a origem dos dados, a segurança e a narrativa. Essa versão prática foi aperfeiçoada em consultorias reais e em sala de aula, onde os blocos que mais geravam dúvida foram refinados até virarem uma anamnese objetiva.
As duas etapas do canvas
1
Canvas ETL & Modelagem
O que o projeto é e de onde vêm os dados
Problema, decisão, contexto, origem, frequência, governança, cálculos e cronograma de fundação.
Use quando:
• No início do projeto
• Antes de abrir o Power BI
• Durante revisões de escopo
2
Data Visualization
Como a história é contada em cada página
Narrativa, tema, mensagem principal, painel visual, hierarquia e cronograma por página.
Use quando:
• Após a Fundação
• Durante a construção dos visuais
• Para validar cada página com o stakeholder
As 4 fases da anamnese
Descoberta
1–3
Problema, quem decide e onde consome.
Dados
4–6
Origem, frequência e horários de carga.
Governança
7–9
Segurança, riscos e premissas.
Execução
10–12
Cálculos, cronograma da fundação e encerramento do projeto.
Os 12 blocos, bloco a bloco
1
1. Problema
Descreva a dor concreta que o dashboard precisa resolver — não a solução.
Por que importa
Todo dashboard que nasce sem uma dor clara vira um monitoramento genérico. Quando a dor está quantificada, o projeto ganha critério de sucesso e a equipe deixa de discutir sobre gosto pessoal.
Como preencher
Escreva a situação que gera prejuízo ou retrabalho hoje. Use números: tempo gasto, dinheiro perdido, risco de decisão ou frequência do problema. Evite descrever a solução ("preciso de um gráfico"); foque na causa do pedido.
Exemplo
Ex.: O time perde 12h/semana consolidando planilhas e decide reposição com dados de 7 dias atrás.
Aceite: a dor está quantificada em tempo, dinheiro ou risco.
2
2. Nível de Decisão
Defina a vocação do relatório inteiro: Estratégico, Analítico ou Operacional, e o público que decide com ele. Isso vale para o dashboard inteiro, não varia por página.
Por que importa
A vocação do relatório define o ritmo de atualização, a granularidade dos dados e o formato visual. Um mesmo indicador vira um número para diretoria, uma análise para gerência e uma lista de tarefas para operação.
Como preencher
Escolha uma das três vocações para o relatório inteiro e nomeie o público que decide com ele. Não mude por página — a unidade é o projeto.
Estratégico — visão de longo prazo (trimestre/ano), acompanha metas e tendências; público: alta liderança.
Analítico — visão de médio prazo (semana/mês), investiga desvios e compara cenários; público: gerência e analistas.
Operacional — visão do dia a dia, acompanha execução e alertas; público: equipe de campo e operação.
Exemplo
Ex.: Analítico — gerentes de filial investigam desvios de meta semanalmente; diretoria acompanha o consolidado no mesmo relatório.
Aceite: uma opção selecionada e o público decisor nomeado.
3
3. Contexto de Uso
Selecione os dispositivos em que o dashboard será consultado. Cada um tem limitações próprias de filtros e complexidade.
Por que importa
Dispositivos diferentes exigem densidades diferentes de informação. Um relatório que funciona bem na reunião pode ser inútil no celular se o canvas não antecipar a restrição.
Como preencher
Liste onde o dashboard será consumido: computador, celular, TV de reunião, tablet. Para cada um, anote o que muda de filtro, de complexidade e de ação.
Computador: filtros completos, tabelas detalhadas e múltiplos visuais.
Celular: poucos KPIs, filtros reduzidos e leitura rápida.
TV: visão macro, pouca interação, alto contraste.
Exemplo
Ex.: Computador na reunião comercial e Celular em visita a cliente.
Aceite: ao menos um dispositivo de consulta selecionado.
4
4. Origem dos Dados
Sistemas, arquivos e APIs de origem, com tipo de acesso e responsável por cada um.
Por que importa
A maioria dos atrasos em projeto de BI vem de fontes mal mapeadas. Documentar a origem, o tipo de acesso e o dono da informação evita retrabalho na fase de ETL.
Como preencher
Para cada fonte, registre sistema, formato (SQL, API, planilha, arquivo), responsável e a forma de acesso. Indique ainda a taxonomia das tabelas envolvidas.
Tabela monolítica — mistura fatos e dimensões; requer modelagem antes de escalar.
Tabela fato — registros de eventos/medições; centro do modelo dimensional.
Tabela dimensão — atributos descritivos; usada para filtrar e agrupar.
Exemplo
Ex.: ERP Protheus (SQL Server, acesso via TI), planilha de metas (SharePoint, dona: Ana), CRM (API).
Aceite: cada fonte tem tipo de acesso e responsável identificados.
5
5. Frequência de Atualização
Com que periodicidade os dados são atualizados e em quais dias da semana.
Por que importa
A periodicidade certa equilibra frescor dos dados e custo de carga. Atualizar de hora em hora um indicador que só é lido semanalmente gera processamento desnecessário e expectativa confusa.
Como preencher
Escolha a menor frequência compatível com a velocidade da decisão. Registre os dias da semana em que a carga deve ocorrer.
Exemplo
Ex.: Diária, de segunda a sexta.
Aceite: uma frequência escolhida e os dias de execução definidos.
6
6. Horários de Atualização
Horários exatos de refresh, considerando a janela de disponibilidade da origem.
Por que importa
Horários de refresh mal escolhidos competem com a carga dos sistemas de origem e deixam os dados inconsistentes durante o dia. O planejamento antecipa janelas de disponibilidade.
Como preencher
Liste os horários exatos de refresh. Confirme com a TI a janela de carga dos sistemas de origem para não conflitar com processamentos críticos.
Exemplo
Ex.: 06:00 e 13:00; janela do ERP livre entre 5h e 7h.
Aceite: horários não conflitam com a janela de carga dos sistemas de origem.
7
7. Regras de Usuários
Segurança por linha (RLS/OLS): quem vê qual dado.
Por que importa
A segurança em BI é por dado, não por página. Definir as regras de acesso desde a anamnese garante que a modelagem e o RLS sejam construídos corretamente, sem gambiarras no fim.
Como preencher
Descreva quem vê quais dados. Indique o campo que relaciona usuário e permissão (e-mail, filial, departamento) e a fonte dessa relação.
Lembre-se: no Dashboard Canvas, todas as páginas do relatório são vistas por todos os usuários autorizados. A restrição é feita por linha de dados.
Exemplo
Ex.: Gerente enxerga apenas a própria filial (RLS por e-mail); diretoria enxerga todas as filiais.
Aceite: regra de RLS descrita com o campo-chave e a fonte da relação usuário↔dado.
8
8. Riscos
O que pode atrasar ou inviabilizar o projeto, com impacto e responsável.
Por que importa
Projetos de BI são interrompidos por dependências externas: acesso a sistemas, mudança de regras de negócio, indisponibilidade de responsáveis. Mapear riscos permite mitigar antes que virem bloqueios.
Como preencher
Para cada risco, descreva o impacto, a probabilidade e um responsável pela mitigação. Foque nos que podem atrasar a entrega.
Exemplo
Ex.: Liberação de acesso ao banco depende de fila da TI (2 semanas) — mitigação: abrir chamado na semana 1.
Aceite: cada risco tem impacto e um responsável por mitigá-lo.
9
9. Premissas
O que está sendo assumido como verdadeiro para o projeto funcionar.
Por que importa
Premissas são acordos que o projeto assume como verdade. Se não forem documentadas, uma mudança silenciosa em metas ou em formatos de arquivo pode desmontar os cálculos.
Como preencher
Liste cada suposição que precisa ser verdadeira para o projeto funcionar. Cada premissa deve ter um dono que confirma ou refuta.
Exemplo
Ex.: As metas serão enviadas até o dia 5 de cada mês; o histórico de 24 meses está íntegro no ERP.
Aceite: cada premissa é verificável e tem um dono que a confirma.
10
10. Cálculos
Dicionário único de métricas do projeto. Cada cálculo crítico precisa de definição formal.
Por que importa
Cálculos com nomes diferentes em cada página ou definidos no último minuto geram dashboards incoerentes. O dicionário de métricas é a fonte de verdade do projeto.
Como preencher
Para cada métrica crítica, registre nome, fórmula, granularidade e origem. Estes cálculos alimentam também os filtros e visuais do Canvas 2.
Exemplo
Ex.: Margem % = (Receita líquida − CMV) ÷ Receita líquida; devoluções entram como valor negativo no mês da nota original.
Aceite: cada métrica crítica tem fórmula, granularidade e fonte de verdade.
11
11. Cronograma & Esforço
Esforço de FUNDAÇÃO do projeto (ETL, modelagem e governança) — datas, horas, responsáveis e status.
Por que importa
A Fundação (ETL, modelagem e governança) precisa de datas próprias. Sem elas, o cronograma vira apenas uma estimativa informal e o dashboard adia a entrega.
Como preencher
Defina início, entrega, esforço em horas, responsáveis e status. A fase de fundação é separada da construção visual das páginas do Canvas 2.
Exemplo
Ex.: Início 05/08, entrega 30/08, 64h, responsáveis: Ana (ETL) e Rafael (modelo), status Em Andamento.
Aceite: datas, esforço em horas e responsáveis preenchidos e acordados.
12
12. Encerramento do Projeto
Esforço de fechar o projeto inteiro — testar e publicar todas as páginas juntas, não por página.
Por que importa
QA/Testes e Publicação são esforço de fechamento do projeto inteiro, não de cada página. Quando ficam diluídos por página, o total é contado várias vezes e a entrega final aparece subestimada no cronograma.
Como preencher
Registre uma única vez o esforço de QA/Testes e o de Publicação para o projeto todo, com validador e status. Esses valores entram no Cronograma Consolidado como a linha de encerramento, depois da fundação e das páginas.
QA/Testes — conferência de números, filtros, performance e acessibilidade do relatório completo.
Publicação — workspace, app, permissões, agendamento de refresh e comunicação aos usuários.
Este esforço foi movido para fora do Canvas 2 justamente para não ser repetido por página.
Exemplo
Ex.: QA 6h de testes cruzados entre páginas; publicação 90 min (workspace, app e permissões); validador: Ana; status Planejado.
Aceite: esforço de testes e de publicação estimados, com validador nomeado.
As duas matrizes
5W2H nos filtros
Os filtros da Seção Comum seguem o 5W2H para garantir que cada visão responda a uma pergunta de negócio.
O quê:
Métrica ou indicador chave.
Por quê:
Justificativa do negócio.
Quem:
Público ou papel que decide.
Quando:
Periodicidade e momento de análise.
Onde:
Canal, região ou dispositivo.
Como:
Visual e formato de apresentação.
Quanto:
Valor, volume ou impacto.
Tipo de Dado × Segmentação
Cada tipo de dado admite diferentes controles de filtro. Escolher o controle certo melhora a performance e a experiência do usuário.
Tipo de dado
Segmentação adequada
Texto
Lista suspensa, botão de opção.
Número inteiro
Lista vertical, intervalo (entre).
Número decimal
Intervalo, caixa de listagem.
Data / Hora
Data relativa, hierarquia de datas.
Booleano
Botão de opção, alternância.
Checklist de verificação
Antes de considerar a anamnese completa, confira se cada fase tem seus critérios de aceite atendidos.
Descoberta
Problema quantificado
Nível de decisão escolhido e público nomeado
Dispositivos de consumo definidos
Dados
Fontes mapeadas com responsável
Frequência e dias de carga definidos
Horários de refresh compatíveis com origens
Governança
Regras de RLS descritas
Riscos com impacto e mitigador
Premissas verificáveis com dono
Execução
Dicionário de cálculos com fórmula
Cronograma de fundação com datas e responsáveis
QA/Testes e Publicação estimados no Bloco 12, com validador e status
Versionamento
O Dashboard Canvas nasce para acompanhar mudanças. A cada revisão, o app incrementa a versão automaticamente (0.1 para ajustes, 1.0 quando a anamnese está completa) e registra o log de mudanças. Isso cria um histórico auditável que pode ser consultado ou revertido em arquivos salvos pelo usuário.
Para quem usa a ponte com o Background Builder: existem três campos opcionais espalhados pela interface. Os créditos de projeto (Idealização / Realização) e o Subtítulo do relatório ficam na tela inicial, recolhidos atrás de “Créditos do projeto”. O Ícone de cabeçalho personalizado fica na Seção Comum, junto da Paleta de cores. Quem não exporta para o Background Builder nunca precisa tocá-los — são metadados, não blocos da anamnese.
Perguntas frequentes
Para quem é essa metodologia?
Para consultores, analistas de BI e líderes de dados que precisam levantar requisitos de um dashboard de forma estruturada, antes de abrir o Power BI. A anamnese reduz retrabalho e alinha expectativas.
Preciso preencher todos os 12 blocos?
Não é obrigatório, mas cada bloco cobre um risco comum de projeto. Blocos críticos deixados em branco aparecerão como pendência na Visão Geral e no Cronograma Consolidado.
O que sai no final?
Uma especificação viva: PDF, Markdown com os dados embutidos e Tema.json de cores. Também é possível exportar uma Ficha Técnica compatível com o Background Builder.
