Dessiner le trajet indispensable
Écrivez quatre étapes : comprendre la proposition, fournir ce qui est nécessaire, obtenir le résultat, savoir quoi en faire. Placez chaque fonction envisagée à l’étape qu’elle aide réellement. Une fonction qui n’aide aucune de ces étapes est candidate à une version suivante.
Distinguez aussi la fonction visible et le travail nécessaire en coulisses. L’export d’un document peut sembler secondaire dans une maquette ; s’il constitue le livrable promis, il devient indispensable au test du service.
Réduire les variantes, pas la clarté
Vous pouvez limiter le nombre de thèmes, de formats ou de cas pris en charge. Annoncez cette limite avant que la personne investisse du temps. Un exemple complet et utilisable est plus instructif qu’une liste de choix menant à des écrans vides.
Exemple fictif : un outil prépare une invitation. Pour le premier test, il ne propose qu’un format et un thème, mais permet de saisir les informations, relire le texte et récupérer le fichier. La galerie de thèmes attendra ; la vérification des informations reste dans le parcours.
Définir ce qui ferait changer la priorité
Pour chaque fonction reportée, notez le signal qui justifierait sa construction. « Plusieurs testeurs abandonnent parce qu’ils ne peuvent pas reprendre leur brouillon » fournit une raison observable. « Les concurrents l’ont » ne décrit pas encore votre besoin.
Après le test, relisez ces hypothèses au lieu d’ajouter automatiquement toutes les demandes. Une demande peut exprimer un problème qui possède une solution plus simple. Le périmètre de la première version doit rester cohérent avec ce qu’elle annonce et ce qu’elle permet effectivement de terminer.