Identifier les acteurs
Distinguez les personnes qui consultent, saisissent, valident ou administrent les données. Deux personnes utilisant le même écran peuvent avoir des responsabilités très différentes. Décrivez un exemple concret par rôle : le client dépose une demande, le chargé de suivi la complète, le responsable la valide. Cette description fait apparaître les passages de relais qui structureront le produit.
Décrire les états et les exceptions
Un dossier peut être en brouillon, envoyé, incomplet, validé ou annulé. Définissez les transitions autorisées et la personne qui peut les déclencher. Demandez aussi ce qui se passe si une pièce manque, si une demande est envoyée deux fois ou si une validation doit être corrigée. Ces cas ne sont pas des détails techniques : ils influencent directement l’expérience quotidienne.
Construire un premier parcours complet
Choisissez une opération que l’utilisateur pourra réaliser de bout en bout dès la première livraison. Une collection d’écrans isolés est moins instructive qu’un parcours utilisable, même réduit. Définissez les données nécessaires, la confirmation attendue et les critères de recette. Vous pourrez ensuite étendre ce parcours à d’autres cas sans remettre en cause son objectif.
Documenter les décisions ouvertes
Séparez les décisions prises des hypothèses à confirmer. Pour chaque point ouvert, nommez la personne qui tranche et la date utile. Le cadrage n’élimine pas toutes les inconnues ; il évite qu’elles se transforment en choix implicites pendant le développement.
Exemple : une demande de devis avec validation
Dans cet exemple illustratif, un client prépare une demande, un chargé de suivi vérifie les pièces et un responsable valide la proposition. Le premier parcours comprend le dépôt, le traitement et la consultation du résultat. Un tableau de bord analytique ou une messagerie intégrée peut attendre. Le cadrage précise qui reçoit une notification, qui peut rouvrir une demande et ce qui reste visible au client pendant la vérification. Ces questions sont plus utiles qu’une liste d’écrans sans règles.
Décrire une règle de façon testable
Une formulation utile ressemble à ceci : « Une demande envoyée peut être consultée par son auteur ; seul le chargé de suivi attribué peut modifier son état. » Ajoutez un cas interdit : un autre client ne peut pas accéder à cette demande en utilisant son adresse. Puis précisez une exception : une demande incomplète revient à son auteur pour correction. La règle devient un support commun pour la conception, le développement et la recette. Les droits doivent être contrôlés par le serveur, même lorsque l’interface masque les commandes non autorisées.
Choisir les données nécessaires au premier parcours
Listez les informations indispensables, leur format et la personne autorisée à les modifier. Évitez de demander une donnée simplement parce qu’elle pourrait servir un jour. Pour un fichier, examinez le type, la taille, les accès et la suppression. Pour un statut, définissez les valeurs et transitions possibles. Si une information vient d’un outil externe, identifiez la source de référence et ce qui doit se passer lorsqu’elle manque. Ces décisions réduisent les corrections tardives et les ambiguïtés entre systèmes.
Préparer la démonstration du premier lot
La démonstration devrait permettre de suivre un scénario entier avec des données de test. Faites jouer chaque rôle et vérifiez un cas nominal, un refus d’accès et une erreur de saisie. Notez les différences entre le comportement prévu et le résultat observé. Classez-les en correction nécessaire, question de périmètre ou évolution souhaitée. Cette séparation évite de confondre un défaut avec une nouvelle demande et rend la décision de livraison plus objective.
Rédigez un scénario complet avec un acteur, un objectif, les états traversés et deux situations d’échec.