Comment gérez-vous les états vides, les erreurs et les cas limites dans vos designs ?

Concevez-les comme partie intégrante du parcours, pas comme des restes. Pour chaque écran, spécifiez les états vide, chargement, partiel, erreur et permission refusée, plus ce qui se passe avec un contenu très long ou absent. Écrivez des messages d'erreur qui disent ce qui s'est passé et quoi faire ensuite, en langage clair. Le chemin heureux bien fini est la partie facile ; les états autour sont là où la confiance se gagne ou se perd.

Je garde une liste standard et je passe chaque écran dessus : vide parce que vous êtes nouveau, vide parce que votre filtre n'a rien trouvé, chargement, données partielles, erreur, hors ligne, et pas de permission. Ce sont sept écrans différents et ils ne sont pas interchangeables, même si je les vois écrasés en une seule illustration triste tout le temps. L'état vide de première utilisation est celui où je passe du vrai temps, parce que c'est l'écran le plus vu du produit par quiconque décide s'il reste, et c'est l'occasion de montrer à quoi ressemble le bon usage plutôt que d'écrire aucun élément pour l'instant. Les textes d'erreur, je les écris moi-même puis j'en discute. Ils doivent dire ce qui s'est passé, si c'était de leur faute ou de la nôtre, et exactement quoi faire ensuite. Une erreur est survenue est un aveu qu'on ne s'est pas donné la peine. Et je mets le contenu sous tension : je colle un nom de soixante caractères et une entreprise sans logo, parce que les vraies données sont toujours plus moches que les données factices. Faire ça en amont évite aux ingénieurs de deviner et m'évite une salve de tickets de bug qui sont en réalité des trous de design.