[dataviz] Usando UX para melhorar nossos dashboards

Vejo poucos posts aqui sobre as áreas de dados, e como essa área me interessa bastante, vou tentar postar alguns conteúdos, até pra diversificar o "cardápio" da plataforma.

O texto abaixo é direcionado principalmente aos dashboards que criamos em plataformas como PowerBI, Looker e similares, mas pode ser aplicado em outras ferramentas de visualização de dados, como as libs disponíveis em Python, R e Javascript, e até mesmo em aplicativos em geral.

Começando

Grande parte das discussões sobre design de dashboards que vejo em comunidades da internet se resumem à polêmica dos "graficos de pizza".

Saber a melhor maneira de dispor gráficos realmente é importante, mas visualização de dados não se resume apenas a isso. Penso que é possível ir mais fundo e aplicar conceitos de UX (User eXperience, ou "experiência de usuário", em português). Afinal, dashboards são, no fundo, aplicativos que serão utilizados por usuários que precisam entender o que está disposto na tela.

Nesse texto, vou resumir o que aprendi em um semestre de faculdade, utilizando um dos livros que tratam sobre o assunto: "Design Centrado no Usuário", de Travis Lowdermilk. Sei que livros técnicos nunca são unanimidade, mas os conceitos que vou tratar aqui estão presentes em qualquer livro inicial da área de UX.

O que é UX?

A Experiência do Usuário está relacionada não apenas com a funcionalidade, mas com o quão agradável é utilizar um aplicativo. UX está preocupada com toda a experiência do uso de um software.

Estamos falando de cores, de posicionamento dos botões e filtros, mas também do tempo de carregamento da aplicação e da disposição dos dados em diferentes tipos de tela, por exemplo.

Um aplicativo - e um dashboard - deve ser agradável de usar, o que significa ter os dados à mão de maneira intuitiva e simples. É mais do que simplismente "beleza".

Parte importante do projeto: o usuário

Assim como em praticamente todos os fluxos de criação de produtos digitais, colher os requisitos de usuário é o primeiro passo da abordagem centrada no usuário. Lowdermilk discute, no capítulo 2 do seu livro, os diferentes tipos de usuários e como lidar com suas dificuldades.

Na área digital, aprendemos que o usuário é parte do problema. É o "bichinho ignorante operando o sistema", mas a verdade é que o usuário é o motivo da existência do projeto. Não da pra começar a desenhar um produto sem antes entender o que o usuário precisa.

Aplicado à dashboards, isso significa entender quais dados o usuário precisa ver, e como ele precisa ver: granularidade, intervalos de atualização, divisão em diferentes páginas, etc. Até mesmo o storytelling de dados se encaixa como uma resposta aos requisitos do usuário.

Requisitos funcionais

Os requisitos funcionais tratam de tudo o que o dashboard, ou qualquer outra aplicação necessitará pra funcionar, do ponto de vista "técnico": plataformas de BI, fontes de dados, como APIs, data lakes e data warehouses, e até mesmo onde a solução de dados será exibida: nos telões espalhados pela empresa ou nos smartphones dos gerentes? A resposta para essa pergunta específica demandará diferentes soluções técnicas.

Protótipos

Esta é a hora de reunir as entradas anteriores e colocar tudo no papel, ou no figma, ou em uma planilha, que seja.

O seu protótipo pode ser funcional, se for possível testa-lo, ainda que seja em uma versão "menor" (pense em dashboards em uma planilha) ou não funcional, se for apenas desenhado em lápis e papel.

Nessa hora é importante as talvez infinitas rodadas com o cliente para alinhar as expectativas da entrega. Tenha paciência, rsrs.

Narrativas, Personas e Cenários

Imaginar quem utilizará seu dashboard e como este será usado é parte importante do processo. Ele será consumido a partir de celulares ou computadores? Quem os consumirá? Gerentes e diretores não precisam dos mesmos niveis de detalhamento dos líderes de área.

Nessa hora, a criação de personas e de narrativas envolvendo essas personas é algo importante.

Funciona assim:

Geraldo, gerente de abastecimento do setor têxtil, todos os dias antes da sua daily matinal com a Diretoria, dá uma olhada no Dashboard de Abastecimento a fim de saber como está o atingimento do abastecimento das mercadorias do seu setor. Ele precisa visualizar qual o percentual de abastecimento em relação ao esperado para cada uma das lojas da companhia, bem como se e quando a previsão de meta de abastecimento será cumprida.

Podemos imaginar uma segunda persona, com uma narrativa totalmente diferente:

Julia é gerente de loja. Diariamente, antes da sua daily matinal com a gerência regional, ela da uma olhada no Dashboard de Abastecimento a fim de saber quais produtos está com o estoque abaixo do "estoque de segurança", bem como a data prevista para esse estoque ser suprido e a data prevista para o desabastecimento de cada item. Se a data prevista do desabastecimento for anterior a data prevista para suprimento, Julia precisa informar aos seus superiores urgentemente, pois há risco real de que sua loja fique desabastecida do item, o que causará perda de vendas e o não atingimento das metas da loja.

Veja só como duas pessoas diferentes consomem o mesmo produto de dados, mas precisam de visões totalmente diferentes: Geraldo precisa saber de maneira macro se as lojas estão abastecidas de mercadoria textil, Julia precisa saber quais itens correm risco de faltar na loja dela.

É a partir dessas informações que é possível desenhar, de maneira assertiva, soluções que atendam tanto um quanto o outro tipo de usuário.

Essa fase é não se trata de inventar histórias aleatórias, e sim descrever possíveis cenários baseado na pesquisa anterior com os diferentes tipos de usuários.

Metas de experiência de usuário

Após a pesquisa e o desenho dos cenários, já está bem claro na nossa cabeça o que o nosso dashboard precisa ter.

Particularmente, eu gosto de emprestar o template de histórias de usuários utilizado na metodologia ágil.

Funciona assim:

Como: Gerente de Abastecimento
Quero: Visualizar o atingimento do nível de abastecimento das mercadorias do meu setor
Para: Justificar à diretoria a minha estratégia de abastecimento

Outra história:

Como: Gerente de Loja
Quero: Visualizar quais itens correm o risco de desabastecimento na minha loja
Para: alertar a minha gerência regional, a fim de conseguir um abastecimento emergêncial e evitar o desabastecimento na minha loja

Agora sim, mãos a obra

No capítulo 7 do seu livro, Lowdermilk vai tratar dos princípios de design. Penso que outra literatura boa para iniciantes é o famoso "Design para Quem não é Designer", de Robin Williams.
Lendo essas literaturas, você entenderá que disposição de cores e formas não é magia, tampouco "obra da criatividade". A palavra "design" nos obriga a entender que cada escolha precisa atender uma funcionalidade, que no nosso caso, precisa responder a uma dor dos usuários que relatamos na seção anterior.

Ferramentas de self service, como PowerBi e Looker Studio são projetadas para atender os princípios básicos de design, como proximidade, visibilidade, feedback visual, proeminência visual, hierarquia, metáforas, entre outros. Mas, como somos nós quem agrupamos diferentes visualizações em cada página, cabe a nós garantirmos que esses princípios continuarão a ser respeitados.

Essa á possível solução para o problema proposto. As cores laranja e azul ajudam a cumprir os princípios de agrupamento e hierarquia, deixando claro que existem duas visões diferentes dos dados, com suas próprias opções de filtragem. A cor vermelha nos itens que merecem atenção, por risco de desabastecimento, atende o princípio de visibilidade.

O princípio da consistência nos diz para "não inventar" e aproveitar ícones e expressões dominadas pelo usuário. Por exemplo: em algumas empresas, a informação que difere um item do outro pode ser chamado de 'id item", em outra, "id sku", em outra, "cod item" e outras variações. As vezes, até mesmo de um setor para o outro, o nome da informação pode ser diferente. É necessário utilizar o conhecimento prévio do usuário na composição do dashboard. Se o usuário chama o dado de "id item", não tem porquê colocarmos "cod sku" no dashboard.

Esse princípio de consistência também é verificado no uso da cor vermelha para alertar o leitor sobre os itens com perigo de desabastecimento. Pois a cor vermelha já tem um significado de "alerta" embutido na cabeça do leitor, pelo menos na cultura ocidental. Em outras culturas, é necessário se certificar que o sistema de simbologia das cores funciona da mesma forma.

Outros princípios, como disse, já são aplicados pela própria ferrramenta. O princípio da exibição progressiva é aplicado quando selecionamos opções em cada filtro. O modelo mental é aplicado, por exemplo, ao utilizar o conhecido sinal de "seta para trás" para indicar a volta para o status anterior no dashboard.

Feedback e melhoria contínua

O usuário é, inevitavelmente, parte indispensável do processo. Receber listas de melhorias após o deploy do dashboard não significa fracasso do projeto e nem deve ser visto como maus olhos por parte de quem construiu a visualização. Pelo contrário: aí começa um novo ciclo, de feedbacks e melhorias contínuas, que obviamente precisam ser apuradas, mas que em grande parte das vezes são necessárias.

Lembre-se: o usuário é o motivo da existência do projeto.

Conclusão

Nesse texto, eu proponho pensarmos dashboards, seja no PowerBI, Looker ou até mesmo no Excel, como aplicativos. Pois, no fim do dia, é isso que eles são.

Dessa forma, é necessário pensar em alguns passos na hora do desenvolvimento, e principalmente, incluir e ouvir o usuário no processo.

O objetivo não é engessar a entrega de um projeto que muitas das vezes é simples. O exposto aqui são conceitos, que devem ser utilizados ou ignorados com sabedoria.

No fim, o importante é termos produtos de dados que atendam as expectativas e necessidades dos usuarios, considerando também o orçamento disponível e tempo disponível, e evitando ao máximo ambiguidades. Como disse, isso não vale apenas para dashboards, mas para aplicativos em geral.