UX de dashboards começa pela velocidade

Há uma frase à qual eu sempre volto quando avalio um dashboard. Ela resume o segundo ano da construção de uma área de BI numa consultoria que atende escolas particulares no Brasil, quando tiramos os dados de arquivos Excel e levamos para o SQL Server. O motivo dessa mudança, no fim das contas, era a pessoa do outro lado da tela:

Tudo se resume a oferecer uma boa experiência ao usuário. Entregar um maravilhoso dashboard que leva minutos para renderizar não funciona. É preciso ter a informação correta e disponível, sem atrasos, sem bugs.

A maior parte dos conselhos sobre design de dashboard começa por cores e gráficos. Eu começo por essa frase, porque dashboard que ninguém espera carregar é dashboard que ninguém usa. O design vem em segundo lugar, e pesa muito depois que a primeira parte está resolvida.

Velocidade é o primeiro requisito de UX

Muita gente pensa em experiência do usuário como diagramação. Em BI, a primeira coisa que o usuário experimenta é a espera.

Os nossos dados moravam no Excel. Planilha tem limites óbvios de tamanho e de acesso à informação, e cruzar uma base com outra era penoso para quem tentasse. Levar as bases para o SQL Server facilitou a manutenção e a manipulação dos dados e deixou as informações mais seguras. Contei essa parte da história em do Excel ao SQL Server.

O ganho para quem lia veio no ano seguinte, quando refizemos todos os relatórios em Power BI em cima da base nova. A experiência do usuário melhorou, e o desempenho dos modelos semânticos também. As análises ficaram mais rápidas e mais precisas. Nenhum redesenho visual teria produzido essa melhora, porque o problema estava embaixo dos gráficos.

Daí saem alguns hábitos:

• Medir quanto tempo o relatório leva para abrir antes de discutir como ele parece.
• Resolver a lentidão na origem. O modelo de dados e o banco costumam importar mais que o gráfico.
• Num data warehouse, tabelas desnormalizadas trocam um pouco de redundância por leitura mais rápida. Para relatório, a troca muitas vezes compensa.
• Tratar número errado como o pior tipo de bug. Velocidade não vale nada se o leitor para de confiar no que vê.

Conte uma história, não despeje gráficos

Com o dashboard rápido e correto, a pergunta seguinte é se alguém entende o que está ali.

Storytelling com dados é construir uma narrativa em volta dos números, para que o leitor receba contexto, e não só valores. Um gráfico de vendas mensais sozinho mostra picos e quedas. O mesmo gráfico com as ações de marketing que aconteceram no caminho explica esses movimentos, e o leitor sai sabendo o que vale repetir.

Um jeito simples de aplicar isso é fazer três perguntas a cada página:

1. Qual é a pergunta que esta página responde?
2. O que o leitor deve notar primeiro?
3. O que ele pode fazer de diferente depois de ler?

Se a página não consegue responder à primeira pergunta, provavelmente são duas páginas fingindo ser uma.

Design que não obriga a pensar

Um bom dashboard parece óbvio. Essa sensação vem mais da consistência do que do talento.

Use cores, formas e diagramação sempre do mesmo jeito. Agrupe as informações que andam juntas. Dê a cada categoria uma cor própria, mas mantenha a paleta curta, porque cada cor a mais é mais uma coisa que o leitor precisa decifrar. Coloque os KPIs principais no topo, onde o olho bate primeiro, e deixe os detalhes para baixo.

A consistência também rende entre relatórios. Quando todos os dashboards de um portfólio seguem as mesmas regras, quem aprendeu a ler um lê o próximo sem ajuda.

Deixe o leitor fazer a próxima pergunta

Um relatório estático responde às perguntas em que o autor pensou. Um interativo deixa o leitor fazer as dele.

Filtros, controles deslizantes e drill-down transformam o dashboard em algo que dá para explorar. Clicar numa região do gráfico e ver os detalhes. Mudar o período e comparar. Um dos padrões mais úteis que conheço é o mapa que filtra todos os outros elementos da tela quando você clica numa área: o leitor escolhe um lugar e a página inteira acompanha.

Só que interatividade tem custo. Cada filtro é mais uma coisa para entender, e cada caminho de drill-down precisa fazer sentido. Acrescente interações que respondem a perguntas que o leitor realmente faz em seguida, e não todas as opções que a ferramenta permite.

Teste com quem vai usar

A última etapa é a que as equipes mais pulam. Antes de lançar um dashboard, coloque-o na frente de quem vai usá-lo e observe a pessoa tentando.

O teste de usabilidade pega problemas que o autor já não enxerga: um filtro que ninguém acha, um rótulo que significa outra coisa para o negócio, uma página que responde a uma pergunta que ninguém faz. Depois do lançamento, continue recolhendo opiniões. A interface deve seguir melhorando conforme as necessidades do leitor mudam.

Uma lista que eu usaria de novo

Para revisar um dashboard, passe por esta lista curta, nesta ordem:

1. Ele abre rápido, e os números estão certos?
2. Há uma pergunta clara por página?
3. Os KPIs principais estão no topo?
4. A paleta é curta e coerente com os outros relatórios?
5. Os filtros e o drill-down respondem a perguntas reais?
6. Alguém que vai usá-lo testou antes do lançamento?

Velocidade e correção vêm primeiro porque decidem se alguém chega ao resto da lista. Todo o resto transforma um dashboard que funciona num dashboard que as pessoas gostam de usar.

Se algum dashboard seu falha no primeiro item dessa lista, conte para a gente.