Avant l’outil, posez la bonne question.

Décrire le geste, pas encore la solution.

« Il me faut une application » est un point de départ. « Je recopie les mêmes informations pour préparer chaque rendez-vous » décrit déjà un usage. Cette seconde formulation aide à comprendre qui intervient, quelles informations circulent et où se situe la difficulté.

Essayez de décrire une occurrence récente. Qu’avez-vous fait en premier ? Qu’avez-vous cherché ? À quel moment avez-vous hésité ou recommencé ? Il n’est pas nécessaire de chronométrer chaque étape pour commencer à voir le problème.

Poser une limite utile.

Un outil qui doit tout faire devient difficile à expliquer. Une première version peut se limiter à une tâche, un public et un résultat attendu. Les idées supplémentaires restent intéressantes : elles n’ont simplement pas toutes besoin d’entrer dans le premier périmètre.

• Qui utiliserait cet outil, concrètement ?
• Quelle information lui faudrait-il pour fonctionner ?
• Quel résultat rendrait son usage utile ?
• Que pourrait-on laisser volontairement de côté ?

Un besoin bien décrit permet aussi de découvrir qu’un nouvel outil n’est pas nécessaire.

Regarder les données avant les fonctions.

Une liste de tâches fictive et un fichier de clients ne demandent pas les mêmes précautions. Avant de bâtir, il faut identifier les données concernées, leurs destinataires et les règles de conservation. Un premier échange peut rester général et ne contenir aucune information sensible.

Le bon point de départ n’est donc pas un catalogue de fonctions. C’est une situation suffisamment précise pour discuter de ce qui pourrait la simplifier.