KjerrUn modèle de demande de fonctionnalité
prêt à copier.
Un bon modèle de demande de fonctionnalité interroge sur le problème, pas sur la solution : ce que la personne cherche à faire, ce qui l’en empêche, qui est concerné et à quoi ressemblerait un bon résultat. Copiez le modèle ci-dessous dans un document, un formulaire ou votre outil de tickets, ou utilisez un tableau qui pose ces questions à votre place.
Le modèle de demande de fonctionnalité
Six questions. Seul le titre devrait être obligatoire.
Titre
Une ligne qui nomme le résultat attendu, pas la solution.
Exemple : Exporter les rapports en CSV
Qu’essayez-vous de faire ?
La tâche, avec vos mots.
Qu’est-ce qui vous en empêche aujourd’hui ?
Ce que vous faites à la place, et ce que cela vous coûte.
Qui est concerné, et à quelle fréquence ?
Vous seul, votre équipe, tous les clients d’une offre ? Chaque jour, chaque mois ?
À quoi ressemblerait un bon résultat ?
Ce qui vous ferait dire que le problème est réglé. Laissez la conception à l’équipe.
Quelque chose à montrer ?
Une capture d’écran, un fichier d’exemple, un lien.
À quoi sert chaque champ
- Titre. Un résultat en une ligne rend les demandes faciles à chercher, et les doublons se retrouvent tout seuls.
- Qu’essayez-vous de faire ? L’objectif survit même quand la solution proposée ne tient pas.
- Qu’est-ce qui vous en empêche ? Le contournement dit ce que le problème coûte.
- Qui, et à quelle fréquence ? La portée et la fréquence : la portée d’une note RICE, avec les mots de l’utilisateur.
- À quoi ressemblerait un bon résultat ? Un test d’acceptation, avec les mots de l’utilisateur.
- Quelque chose à montrer ? Une capture d’écran remplace trois paragraphes.
Du modèle au formulaire de demande
Un formulaire de demande de fonctionnalité doit être plus court que le modèle. Gardez le titre et une question ouverte, et posez le reste en commentaire quand vous en avez besoin.
- N’exigez que le titre.
- Affichez les demandes proches avant l’envoi du formulaire, pour qu’on puisse voter au lieu d’écrire.
- Laissez joindre une capture d’écran d’un simple coller.
- Confirmez l’e-mail une fois, pas à chaque demande.
- Dites ce qui se passe ensuite : où la demande apparaîtra et comment la réponse arrivera.
Le même modèle pour le feedback produit
Les mêmes questions font un bon modèle de feedback produit, pour les bugs comme pour les remarques générales. Gardez la première question ouverte et retirez les deux dernières.
- Pour un bug, demandez ce qui était attendu et ce qui s’est passé à la place. Le modèle de rapport de bug donne la série complète de questions.
- Pour les compliments et les réclamations, les deux premières questions suffisent.
- Gardez tout dans une seule liste, pour qu’une réclamation et une demande sur le même sujet se rencontrent.
Comment le formulaire d’idée de Kjerr couvre ce modèle
Le formulaire de Kjerr part de la version courte : un titre, une description facultative et des captures d’écran. Le reste du modèle, c’est le tableau autour du formulaire qui s’en charge.
- Le champ de description demande : « Qu'essayez-vous de faire, et qu'est-ce qui vous en empêche ? »
- Jusqu’à 5 captures d’écran ou fichiers de 10 Mo chacun.
- Les idées proches s’affichent pendant la saisie du titre, chacune avec son bouton de vote.
- Qui est concerné, ce sont les votes et Users & Companies qui le disent : entreprise, offre et MRR.
- Le formulaire est à vous : renommez les deux champs d’origine, rendez la description obligatoire et ajoutez jusqu’à 8 champs, d’une ligne ou d’un paragraphe.
Des questions, des réponses franches.
Qu’est-ce qu’un modèle de demande de fonctionnalité ?
Un modèle de demande de fonctionnalité est une courte série de questions qui aide un utilisateur à décrire son besoin : l’objectif, ce qui le bloque aujourd’hui, qui est concerné et à quoi ressemble un bon résultat. Les demandes deviennent comparables, et l’équipe s’épargne un aller-retour de questions.
Que doit demander un formulaire de demande de fonctionnalité ?
Le moins possible. Un titre et une question ouverte recueillent plus de demandes que dix champs obligatoires. Interrogez sur le problème, pas sur la solution, et laissez joindre une capture d’écran.
Un formulaire de demande doit-il avoir des champs obligatoires ?
Seulement le titre. Chaque champ obligatoire de plus réduit le nombre de personnes qui vont au bout du formulaire, et le détail peut se demander plus tard, en commentaire.
Est-ce la même chose qu’un cahier des charges fonctionnel ?
Non. Un cahier des charges fonctionnel décrit en détail ce qu’un projet doit faire, avant sa réalisation ; une demande de fonctionnalité vient d’un utilisateur et décrit un problème, en quelques lignes. La demande se situe en amont, et c’est à l’équipe d’en tirer la conception.
En quoi un modèle de feedback produit est-il différent ?
Un modèle de feedback produit couvre tout ce qu’un utilisateur veut dire, bugs et compliments compris ; un modèle de demande de fonctionnalité ne porte que sur ce qui n’existe pas encore. Les mêmes questions servent aux deux si la première reste ouverte.
Où se situe le formulaire d’idée de Kjerr par rapport à ce modèle ?
Par défaut, il demande un titre court et une description facultative, avec l’invite « Qu'essayez-vous de faire, et qu'est-ce qui vous en empêche ? », et accepte jusqu’à 5 captures d’écran ou fichiers. Vous pouvez renommer ces deux champs et en ajouter jusqu’à 8. Pendant la saisie du titre, les idées proches s’affichent avec un bouton de vote : beaucoup de demandes finissent ainsi en vote plutôt qu’en doublon.
À lire aussi
Donnez une réponse à vos utilisateurs.
Kjerr est gratuit pendant l’accès anticipé : toutes les fonctionnalités, sans carte bancaire. Quand les offres payantes arriveront, elles seront facturées par espace de travail, jamais par siège administrateur.