ModèleCraft6 min de lecture
À quoi ça sert
Vérifier qu’aucun angle d’une fonctionnalité n’a été oublié avant le développement.
Les questions que ça aide à trancher
Où dans le cycle de design
Vingt-cinq points de vigilance à passer en revue avant de considérer qu’une fonctionnalité est conçue, précédés de trois questions sans lesquelles je ne commence pas.
Tous les points ne s’appliquent pas à chaque fonctionnalité. La liste sert à vérifier qu’aucun angle n’a été oublié, et à nommer ce qu’on choisit de ne pas traiter. Je la relis à deux moments : au cadrage, pour poser les questions, et avant le passage en développement, pour vérifier les réponses.
Quel est le besoin utilisateur pour lequel on conçoit une solution ? Un besoin remonté par un utilisateur réel, idéalement.
Comment prévoit-on d’y répondre ?
Pour quel résultat, quel aboutissement ?
Quel est l’objectif de l’utilisateur quand il utilise cette fonctionnalité ?
Cette fonctionnalité a-t-elle des particularités communes avec d’autres applications ? Par exemple : gérer une liste d’éléments, ajouter un élément, trier ou filtrer une liste, sélectionner, sélectionner plusieurs éléments.
Pour une fonctionnalité de type liste, les questions à se poser :
Une fonctionnalité similaire existe-t-elle ailleurs, et partage-t-elle la même approche de la solution ? Y a-t-il des métaphores, dans la vie réelle ou dans celle des utilisateurs, qui pourraient ressembler à la solution ? Si le concept est nouveau, est-on capable de le décrire en termes génériques ?
Quels autres outils utilisent nos audiences ? Sont-elles expertes de ces outils ? Cela influence-t-il leur manière de comprendre comment une fonction d’import fonctionne, par exemple ? Sont-elles plus habituées à la sauvegarde automatique qu’au clic sur un bouton « Enregistrer » ?
Quel niveau d’expertise demande cette fonctionnalité ? Est-ce une action utilisée dès la première connexion, ou réservée aux experts ? Pour supprimer un e-mail, le balayage est masqué mais connu des utilisateurs avancés. Souhaite-t-on guider l’utilisateur pour qu’il apprenne cette action, ou préfère-t-on la masquer pour éviter une interaction accidentelle des débutants ?
Quel est le contexte d’usage de cette fonctionnalité ? L’environnement de l’utilisateur peut-il influencer la manière dont il comprend l’information ou interagit avec l’interface ? Par exemple, un professeur qui partage un contenu depuis un ordinateur, dans une classe bruyante, avec des élèves dissipés.
Que fait l’utilisateur juste avant d’utiliser la fonctionnalité ? De quels endroits de l’application arrive-t-il ? Prévoir un parcours clair et rassurant pour lui permettre de revenir en arrière s’il s’est trompé.
Qu’est-ce qui déclenche l’utilisation de la fonctionnalité ? Quand et pourquoi le besoin intervient-il ? Le déclencheur peut être :
Si l’utilisateur a besoin d’être notifié, comment s’assure-t-on que la notification n’est pas intrusive ? Comment calibrer l’application pour qu’elle ne génère pas de stress par des notifications trop fréquentes ?
L’utilisateur a-t-il besoin de configurer des paramètres avant de pouvoir utiliser la fonctionnalité ? Le système mémorise-t-il cette configuration pour la prochaine fois (oui, de préférence) ? L’utilisateur sait-il où modifier ces paramètres si besoin ?
Un prérequis est-il nécessaire pour accéder à la fonctionnalité ? Comment le communique-t-on à l’utilisateur ? Par exemple, l’accès à la caméra du téléphone pour scanner un code-barres.
L’utilisateur a-t-il besoin de connaître certaines informations pour faire des choix avant de commencer le parcours ? Que doit-il voir ou savoir pour choisir correctement ? S’il est amené à visiter une page externe, comment l’en informer ? Par exemple, un tableau de bord consulté sur un autre site.
Certaines opérations prennent-elles du temps ? Comment gérer l’attente ? Un long chargement est-il à prévoir pour certaines informations ou pour initialiser un processus ? Comment montrer le chargement pour que l’utilisateur sente qu’il garde le contrôle ? Peut-il continuer ses tâches pendant ce temps, ou faut-il lui interdire des changements ?
Si une opération dure plus de cinq secondes, permettre de l’annuler. Où l’utilisateur se retrouve-t-il après l’annulation ? Le système revient-il à l’état précédent ?
Comment les utilisateurs sont-ils informés du succès d’une opération ? Les retours sont-ils informatifs, rassurants ? Sont-ils discrets mais suffisamment clairs ?
Quelles erreurs sont susceptibles de se produire ? S’il existe plusieurs niveaux de sévérité, comment le système les représente-t-il ? Que propose-t-on à l’utilisateur pour les résoudre ? Un accès à une section d’aide, ou un raccourci vers une information en contexte ?
À quelle fréquence cette fonctionnalité sera-t-elle utilisée ? Dix fois par jour, une fois par mois, une seule fois ? Combien de clics, de touches ou de balayages sont nécessaires ? Des raccourcis clavier ou des actions en masse permettent-ils d’éliminer les clics en trop ?
Comment l’accessibilité est-elle gérée dans la fonctionnalité ? Est-ce un paramètre qui conditionne son utilisation ? La fonctionnalité est-elle utilisable avec un lecteur d’écran ? Y a-t-il un mode opératoire particulier à la souris ? Les contrastes et les tailles de texte sont-ils corrects ?
Si plusieurs rôles existent dans le système, quels sont les niveaux d’accès à la fonctionnalité ? Implique-t-elle l’accès à une information réservée à certains utilisateurs ? Les personnes qui n’y ont pas accès peuvent-elles en être informées, et savoir sous quelles conditions elles pourraient y accéder ? Par exemple, un mode payant, ou un accès administrateur à demander au responsable.
Quelle sera l’expérience de l’utilisateur à la première connexion ? Comment l’embarquer ? Comment lui faire comprendre l’objectif et la valeur de la fonctionnalité ? Comment proposer un accompagnement suffisant au démarrage, sans être intrusif ?
Trois situations produisent un état vide :
Chacune est une occasion : éduquer et enrichir la compréhension du service, susciter un sourire à la lecture d’une information, clarifier la proposition de valeur et proposer une action.
Comment la fonctionnalité se comporte-t-elle sans aucune donnée à afficher ? Qu’affiche-t-on pour aider l’utilisateur à comprendre et à agir ? Quelles actions proposer pour éviter l’hésitation et la perte de repères ? Comment l’accompagner pour remplir l’état vide ?
L’application fonctionne-t-elle correctement sur des machines lentes ? L’équipement présente-t-il des lacunes de performance ? L’accès au réseau peut-il être un enjeu ? Peut-on proposer un mode dégradé pour rendre la fonctionnalité accessible dans le plus grand nombre de contextes ? Les jeux gourmands en ressources, par exemple, permettent de réduire la qualité graphique sur les téléphones peu puissants.
Cette fonctionnalité nécessite-t-elle un nouveau pattern d’interaction, comme une recherche avec autocomplétion ? Un composant existe-t-il déjà dans le design system ? Faut-il en créer un spécifique pour répondre au besoin ?
Est-il possible de simplifier la solution conçue ? La nouvelle fonctionnalité est-elle en accord avec le reste de l’application ?
Comment est-elle nommée ? Trouver un nom au début de la réflexion, et le clarifier auprès des différents interlocuteurs, pour que tout le monde parle de la même chose.
Comment les utilisateurs vont-ils apprendre l’existence de la fonctionnalité ? Par une lettre d’information, une mise à jour de l’application, une notification dans l’application ? Quelles seront leurs attentes ? Connaîtront-ils d’emblée la valeur de cette mise à jour, ou devront-ils tester pour comprendre toutes les possibilités ? Comment aligner le discours promotionnel et l’expérience ressentie dans l’application ?
Comment les utilisateurs peuvent-ils donner leur avis sur la nouvelle fonctionnalité ? Combien d’utilisateurs sont concernés ?
