Un bouton dans une maquette affiche généralement un état : celui par défaut. Dans le produit réel, le même bouton est survolé, mis au point avec un clavier, enfoncé, désactivé lorsqu'un formulaire est incomplet et chargé lorsqu'une demande est envoyée. Chacun d’entre eux est un état de l’interface utilisateur et chacun a besoin d’une conception.
Cela aide à séparer deux groupes. Les états d'interaction proviennent de l'utilisateur : survol, focus, enfoncé et désactivé. Les états des données proviennent du système : chargement, vide, données partielles, erreur et succès. Un écran de liste, par exemple, a besoin d'une conception pour le moment où il se charge, lorsqu'il ne contient aucun élément, lorsqu'il contient un élément, lorsqu'il en contient des centaines et lorsque la demande échoue.
Les états ciblés méritent une attention particulière. Les personnes qui utilisent un clavier ou un commutateur dépendent d'un indicateur de mise au point visible pour savoir où elles se trouvent. La suppression du contour du focus du navigateur sans remplacement est l’un des échecs d’accessibilité les plus courants.
Le changement entre les états fait également partie de la conception. Une transition courte et claire de la valeur par défaut à la touche enfoncée confirme le tapotement. Un état de chargement qui se transforme en douceur en succès indique aux gens que leur action a fonctionné. Des sauts brusques ou une animation trop lente rendent l’interface peu fiable.
Un moyen pratique d'éviter les états manquants consiste à les lister pour chaque composant avant la conception, ou à modéliser le composant comme une machine à états : un ensemble d'états et les événements qui se déplacent entre eux. ExodeUI, que nous fabriquons, fonctionne de cette façon. Vous concevez chaque état et les transitions entre eux dans un seul fichier, et votre code envoie les événements qui changent d'état dans l'application réelle.