Les données avant la conception
Trois éléments déterminent si une vue de données est bonne, et ils sont tous réglés avant d'écrire du balisage : quelle décision la vue sert, ce qui se trouve réellement dans le champ, et laquelle parmi plusieurs mises en page la personne souhaite. En sauter un produit une vue qui a l'air finie et qui est fausse.
Quand l'utiliser
- Toute carte, panneau, tableau, tableau de bord, ou vue détaillée sur des enregistrements que vous n'avez pas créés
- Une partie prenante dit "montre-moi X" et X est un nom de colonne
- Vous êtes sur le point de résumer, tronquer, étiqueter, trier, colorer ou compter un champ
- Vous hésitez entre deux façons de disposer la même information
Ne pas utiliser lorsque les données sont vos propres fixtures, ou que la vue est une valeur déjà affichée.
Un diagramme ou un tableau qui sera publié, partagé ou mis dans un rapport commence toujours ici quand il montre
les enregistrements que vous n'avez pas créés. Une fois les données réglées, diagrammes-pratiques couvre la lisibilité :
le titre principal, les axes honnêtes, une série mise en évidence, la source dans l'image.
Étape 0 : nommer la décision
Écrivez une phrase avant de toucher aux données : "Quelqu'un qui regarde ceci est en train de décider ___." Si vous ne pouvez pas la terminer, vous construisez un vidage de données et la question de mise en page n'a pas de réponse.
- Chaque champ mérite sa place en influençant cette décision. Ce qui est intéressant mais neutre pour la décision appartient à la vue détaillée, pas à la carte.
- La proéminence suit le poids de la décision, pas la commodité de la requête. Le champ qui a été le plus facile à récupérer n'est pas celui qui mérite la plus grande police.
- Un partie prenante qui nomme une colonne vous a dit les données qu'elle veut, pas la décision. Demandez ce qu'elle ferait différemment selon sa valeur.
Étape 1 : profiler le champ, puis concevoir
Interrogez avant de concevoir. Pour chaque champ que la vue affichera :
| Vérification | Pourquoi cela change la conception |
|---|---|
| Comptage non-nul | Un champ NULL sur chaque ligne n'a pas besoin de carte — il a besoin d'un rapport de bug |
| Valeurs distinctes | Quatre valeurs est un ensemble de puces ; quatre mille est une zone de recherche |
| Longueur : min / moyenne / p95 / max | La moyenne cache le débordement — dimensionnez le conteneur à p95, et décidez délibérément ce que fait la queue |
| Couverture entre les enregistrements | Une carte qui se déclenche pour 1,6 % des enregistrements est un état vide avec une exception rare |
| Cardinalité par parent | Une note par personne est un paragraphe ; vingt est une liste avec ses propres affordances |
| Présence d'une date | Vous ne pouvez pas montrer l'obsolescence pour un champ qui ne porte pas de date |
| Vocabulaire | Un texte libre avec huit formulations maison nécessite une normalisation, pas un rendu |
| Un comparateur existe | Un nombre brut est illisible — voir ci-dessous |
Indiquez ce que vous avez trouvé avant de proposer la conception, en chiffres.
Chaque nombre à l'écran a besoin de quelque chose pour le comparer
52 notes ne dit rien au lecteur : il ne peut pas dire si c'est beaucoup. 52 notes (médiane 4) est une découverte. Avant d'afficher un compte, un total ou un score, trouvez son comparateur — une médiane,
un objectif, la période précédente, ou le reste de l'ensemble — et affichez-les ensemble. Si aucun comparateur
n'existe, c'est une preuve que le nombre ne devrait pas être à l'écran.
Le cas dégénéré est un nombre qui ne varie jamais : un compte vrai pour chaque enregistrement se lit comme une découverte et est du bruit.
Étape 2 : maquetter les options, puis construire
Pour tout ce qui ressemble à une carte, produisez plusieurs maquettes statiques à partir d'enregistrements réels et laissez la personne choisir. Construisez seulement après cela.
- Dites en une ligne ce que chaque option optimise et ce qu'elle coûte
- Les maquettes sont du HTML jetable, pas un composant — ne les câblez pas
Maquetter six états, pas un
Concevez chaque état que la vue peut avoir, chacun à partir d'un enregistrement réel :
| État | À tirer de |
|---|---|
| Idéal | L'enregistrement typique — celui à la médiane, pas celui que vous avez choisi |
| Vide | Un enregistrement sans rien dans le champ, et un compte tout nouveau sans aucun enregistrement |
| Partiel | Certains champs remplis, d'autres non — dans les données réelles, c'est le cas courant, pas l'exception |
| Chargement | Ce qui occupe l'espace avant l'arrivée des données, à la taille que les données auront |
| Erreur | La récupération a échoué, ou la valeur est mal formée et ne peut pas être rendue |
| Fait | Ce qui confirme qu'une action offerte par la vue s'est réellement produite |
Ensuite, le cas de stress
Les extrêmes de volume (le plus occupé, typique, vide) ne sont pas les seuls extrêmes. Un cas de stress est une donnée qui est présente, bien formée, et douloureuse : le nom que le champ déforme, l'enregistrement dont le statut rend un badge joyeux incorrect, la personne dont le compte supprimé est toujours compté dans le résumé. Choisissez l'enregistrement qui mettrait le plus cette vue dans l'embarras et rendez-le.
Plusieurs cartes sur une page : une clé pour toutes
Un lecteur apprend la signification d'une couleur sur la première carte et l'applique à chaque carte suivante. Donc avant de dessiner une carte sur une page qui en contient plusieurs, notez une table de catégories unique pour toute la page : le nom canonique, un ordre fixe et une couleur pour chaque catégorie. Chaque carte, légende et infobulle l'utilise.
- Une catégorie, une couleur ; une couleur, une catégorie. Une couleur appartient à sa catégorie même sur les cartes où cette catégorie est absente. L'utiliser pour autre chose, même sur une carte qui ne montre jamais l'originale, indique au lecteur que les deux sont la même chose.
- Un nom par catégorie. "Santé & Développement Mondial" sur une carte et "Développement Mondial & Santé" sur la suivante fait se demander au lecteur s'il s'agit de deux catégories.
- Une taxonomie là où les cartes coupent les mêmes enregistrements. Avant qu'une carte n'ajoute son propre compartiment, vérifiez s'il se fusionne dans une catégorie que la page a déjà. Si une carte a vraiment besoin d'une division plus fine, donnez aux sous-catégories des nuances de la couleur parente, pas de nouvelles couleurs.
- Les catégories vraiment différentes reçoivent des couleurs inutilisées, plus un sous-titre disant que la ventilation est différente. Ne réutilisez jamais une couleur que la page a déjà donnée à une autre catégorie.
- Même ordre dans chaque légende, avec "Autre" toujours en dernier et toujours le même gris neutre.
Terminé quand lister chaque paire (étiquette, couleur) sur toute la page donne une correspondance un-à-un. Grep les balises ou la feuille de style pour les valeurs de couleur, pas la capture d'écran rendue.
Règles de rendu qui découlent des données
- L'état vide fait du travail. "Pas encore de notes" est une impasse. Dites pourquoi c'est vide et ce qui le remplit. Un état vide qu'un utilisateur rencontre le premier jour est un onboarding, et mérite d'être conçu.
- Nombres dans un tableau : alignement à droite, chiffres tabulaires (
font-variant-numeric: tabular-nums), une seule précision pour toute la colonne, les unités dans l'en-tête plutôt que répétées dans chaque cellule. La règle 13 dediagrammes-pratiquescontient le reste : pas de grille, une ligne clé teintée, des barres en ligne. - Le tri par défaut est une décision de conception. Les enregistrements arrivant dans l'ordre de la clé primaire est l'absence de tri.
Erreurs courantes
| Erreur | Ce qui se passe |
|---|---|
| Concevoir à partir du schéma | La colonne existe ; les données non |
| Construire sans décision nommée | Tout a un poids égal, car rien n'a de raison d'être plus grand |
| Donner la plus grande proéminence au champ le plus simple | La disposition décrit le schéma, pas le travail |
| Afficher un nombre sans rien pour le comparer | Le lecteur ne peut pas dire si c'est bon, et arrête de regarder |
| Compter quelque chose qui est toujours vrai | Un compte qui ne varie jamais se lit comme une découverte et est du bruit |
| Faire confiance à un plan écrit avant d'avoir vu les données | Vous construisez la chose nommée dans le plan, pas la chose que les données soutiennent |
| Maquetter seulement l'état idéal | La conception s'effondre sur l'enregistrement qui n'a rien, ou la moitié de quelque chose |
| Tester seulement les extrêmes de volume | La vue survit au plus grand enregistrement et humilie quelqu'un sur un enregistrement ordinaire |
| Construire une option parce qu'elle a été décrite en premier | La personne ne peut pas choisir ce qu'on ne lui a jamais montré |
| Choisir les couleurs et étiquettes carte par carte | Le même bleu signifie deux choses sur une page, et le lecteur fait un lien qui n'existe pas |
D'où viennent les parties non évidentes
- Décision d'abord, et proéminence par poids de décision — Stephen Few, Information Dashboard Design
- Un nombre a besoin d'un comparateur — Few encore, sur le contexte comme ce qui donne du sens à un nombre
- Les six états — Scott Hurff, UI Stack
- Cas de stress — Eric Meyer & Sara Wachter-Boettcher, Design for Real Life