Dados antes do design
Três coisas decidem se uma visualização de dados é boa, e todas as três são resolvidas antes de você escrever marcação: qual decisão a visualização serve, o que realmente está no campo e qual dos vários layouts a pessoa deseja. Pular qualquer uma delas produz uma visualização que parece pronta e está errada.
Quando usar
- Qualquer cartão, painel, tabela, dashboard ou visualização detalhada sobre registros que você não criou
- Um stakeholder diz "mostre-me X" e X é o nome de uma coluna
- Você está prestes a resumir, truncar, adicionar badge, ordenar, colorir ou contar um campo
- Você está escolhendo entre duas maneiras de dispor a mesma informação
Pule quando os dados são sua própria fixture, ou a visualização é um único valor que você já imprimiu.
Um gráfico ou tabela que será postado, compartilhado ou colocado em um relatório ainda começa aqui quando mostra
registros que você não criou. Uma vez que os dados estão definidos, practical-charts cobre como ele é lido:
o título principal, eixos honestos, uma série destacada, a fonte dentro da imagem.
Passo 0: nomeie a decisão
Escreva uma frase antes de tocar nos dados: "Alguém olhando para isso está decidindo ___." Se você não conseguir completá-la, está construindo um despejo de dados e a questão do layout não tem resposta.
- Cada campo ganha seu lugar por mudar essa decisão. Interessante, mas neutro em relação à decisão, pertence à visualização detalhada, não ao cartão.
- A proeminência segue o peso da decisão, não a conveniência da consulta. O campo mais fácil de obter não é o campo que merece o maior tipo.
- Um stakeholder nomear uma coluna disse a você os dados que deseja, não a decisão. Pergunte o que eles fariam de diferente dependendo do seu valor.
Passo 1: analise o campo, depois projete
Consulte antes de projetar. Para cada campo que a visualização mostrará:
| Verificação | Por que muda o design |
|---|---|
| Contagem não nula | Um campo NULL em cada linha não precisa de um cartão — precisa de um relatório de bug |
| Valores distintos | Quatro valores é um conjunto de chips; quatro mil é uma caixa de busca |
| Comprimento: min / média / p95 / max | A média esconde o estouro — dimensione o contêiner para p95 e decida deliberadamente o que a cauda faz |
| Cobertura entre registros | Um cartão que dispara para 1,6% dos registros é um estado vazio com uma exceção rara |
| Cardinalidade por pai | Uma nota por pessoa é um parágrafo; vinte é uma lista com seus próprios recursos |
| Presença de data | Você não pode mostrar obsolescência para um campo que não carrega data |
| Vocabulário | Texto livre com oito redações de casa precisa de normalização, não de renderização |
| Existe um comparador | Um número puro é ilegível — veja abaixo |
Informe o que encontrou antes de propor o design, em números.
Cada número na tela precisa de algo para compará-lo
52 notas não diz nada ao leitor: ele não consegue saber se é muito. 52 notas (mediana 4)
é uma descoberta. Antes de exibir qualquer contagem, total ou pontuação, encontre seu comparador — uma mediana,
um alvo, o período anterior ou o restante do conjunto — e exiba-os juntos. Se nenhum comparador
existir, isso é evidência de que o número não deveria estar na tela.
O caso degenerado é um número que nunca varia: uma contagem verdadeira para todo registro lê-se como uma descoberta e é ruído.
Passo 2: crie mocks das opções, depois construa
Para qualquer coisa em forma de cartão, produza vários mocks estáticos a partir de registros reais e deixe a pessoa escolher. Construa apenas depois disso.
- Diga em uma linha o que cada opção otimiza e o que custa
- Mocks são HTML descartável, não um componente — não os conecte
Mock seis estados, não um
Projete todos os estados em que a visualização pode estar, cada um a partir de um registro real:
| Estado | Extrair de |
|---|---|
| Ideal | O registro típico — aquele na mediana, não o que você escolheu |
| Vazio | Um registro sem nada no campo, e uma conta nova sem nenhum registro |
| Parcial | Alguns campos preenchidos, outros não — em dados reais este é o caso comum, não a exceção |
| Carregando | O que ocupa o espaço antes dos dados chegarem, no tamanho que os dados terão |
| Erro | A busca falhou, ou o valor está malformado e não pode ser renderizado |
| Concluído | O que confirma que uma ação que a visualização oferece realmente ocorreu |
Depois, o caso de estresse
Extremos de volume (mais ocupado, típico, vazio) não são os únicos extremos. Um caso de estresse é um dado que está presente, bem formado e doloroso: o nome que o campo distorce, o registro cujo status torna um badge alegre errado, a pessoa cuja conta excluída o resumo ainda conta. Escolha um único registro que mais envergonharia esta visualização e renderize-o.
Vários cartões em uma página: uma chave para todos
Um leitor aprende o significado de uma cor no primeiro cartão e o aplica a todos os cartões seguintes. Portanto, antes de desenhar qualquer cartão em uma página com vários, escreva uma tabela de categorias para a página inteira: o nome canônico, uma ordem fixa e uma cor para cada categoria. Todos os cartões, legendas e dicas de ferramentas a usam.
- Uma categoria, uma cor; uma cor, uma categoria. Uma cor pertence à sua categoria mesmo em cartões onde essa categoria está ausente. Usá-la novamente para outra coisa, mesmo em um cartão que nunca mostra a original, diz ao leitor que as duas são a mesma coisa.
- Um nome por categoria. "Saúde Global & Desenvolvimento" em um cartão e "Desenvolvimento Global & Saúde" no próximo faz o leitor se perguntar se são duas categorias.
- Uma taxonomia onde os cartões cortam os mesmos registros. Antes de um cartão adicionar seu próprio balde, verifique se ele se mescla em uma categoria que a página já possui. Se um cartão realmente precisa de uma divisão mais fina, dê às subcategorias tons da cor do pai, não novas cores.
- Categorias que são realmente diferentes recebem cores não usadas, além de um subtítulo dizendo que a divisão é diferente. Nunca reutilize uma cor que a página já deu a outra categoria.
- Mesma ordem em toda legenda, com "Outro" sempre por último e sempre o mesmo cinza neutro.
Concluído quando listar cada par (rótulo, cor) na página dá um mapeamento um-para-um. Grep na marcação ou stylesheet pelos valores de cor, não na captura de tela renderizada.
Regras de renderização que decorrem dos dados
- O estado vazio funciona. "Nenhuma nota ainda" é um beco sem saída. Diga por que está vazio e o que o preenche. Um estado vazio que um usuário encontra no primeiro dia é onboarding e merece design.
- Números em uma tabela: alinhados à direita, algarismos tabulares (
font-variant-numeric: tabular-nums), uma precisão para toda a coluna, unidades no cabeçalho em vez de repetidas em cada célula. A regra 13 depractical-chartstem o restante: sem grade, uma linha chave realçada, barras inline. - A ordenação padrão é uma decisão de design. Registros chegando na ordem da chave primária é a ausência de uma.
Erros comuns
| Erro | O que acontece |
|---|---|
| Projetar a partir do esquema | A coluna existe; os dados não |
| Construir sem uma decisão nomeada | Tudo recebe peso igual, porque nada tem um motivo para ser maior |
| Dar ao campo mais fácil a maior proeminência | O layout descreve o esquema, não a tarefa |
| Mostrar um número sem nada para comparar | O leitor não consegue dizer se é bom e para de olhar |
| Contar algo que é sempre verdadeiro | Uma contagem que nunca varia lê-se como uma descoberta e é ruído |
| Confiar em um plano escrito antes que os dados foram vistos | Você constrói a coisa que o plano nomeou, não a coisa que os dados suportam |
| Mockar apenas o estado ideal | O design desmorona no registro que não tem nada, ou metade de algo |
| Testar apenas extremos de volume | A visualização sobrevive ao maior registro e humilha alguém em um ordinário |
| Construir uma opção porque foi descrita primeiro | A pessoa não pode escolher o que nunca foi mostrado |
| Escolher cores e rótulos cartão por cartão | O mesmo azul significa duas coisas em uma página e o leitor cria um vínculo que não existe |
De onde vêm as partes não óbvias
- Primeiro a decisão, e proeminência pelo peso da decisão — Stephen Few, Information Dashboard Design
- Um número precisa de um comparador — Few novamente, sobre contexto como a coisa que faz um número significar algo
- Os seis estados — Scott Hurff's UI Stack
- Casos de estresse — Eric Meyer & Sara Wachter-Boettcher, Design for Real Life