1. Définir ce que la personne doit réussir

Écris une phrase avec un utilisateur, une situation et un résultat. Exemple fictif : une personne qui cuisine chez elle veut retrouver une recette enregistrée et cocher ses ingrédients pendant ses courses. Cette phrase est plus utile qu’une liste comprenant profil, fil d’actualité, recherche et assistant.

Définis ensuite la preuve attendue. Dans cet exemple, une personne doit enregistrer une recette courte, la retrouver après fermeture de l’app et utiliser sa liste sans aide. Tu peux observer ces actions. Tu ne peux pas encore conclure qu’elle utilisera le produit toutes les semaines ou qu’elle voudra le payer.

2. Classer les fonctions en trois groupes

Pour chaque idée, demande si elle est nécessaire à cette preuve. Si oui, conserve-la et décris le scénario qu’elle rend possible. Sinon, reporte-la ou retire-la du projet. Reporter une fonction signifie identifier la question qui justifiera de la reprendre plus tard.

Dans notre exemple, la liste de courses dépend d’une recette enregistrée. Un réseau social de cuisiniers ne dépend pas du même problème : il introduit une autre promesse et de nouveaux utilisateurs. Le supprimer du MVP rend la décision de test beaucoup plus lisible.

  • Garder : saisie simple, enregistrement local, liste des recettes, ingrédients à cocher.
  • Reporter : synchronisation entre appareils et import automatique, à réexaminer si les testeurs en ont besoin.
  • Retirer du MVP : fil public, abonnements à des créateurs et classement communautaire.

3. Inclure les états qui rendent le parcours complet

Un écran de recette rempli ne suffit pas. Que voit-on avant le premier ajout ? Que se passe-t-il si le titre est vide, si l’enregistrement échoue ou si la personne ferme l’application ? Décide ces comportements avant de considérer la fonction comme terminée.

Cela ne demande pas de concevoir toutes les évolutions du produit. Il faut rendre fiable le parcours choisi. Un message qui explique un échec et conserve la saisie peut avoir plus de valeur, à ce stade, qu’un nouvel écran de statistiques.

  • État initial sans donnée.
  • Entrée invalide et correction possible.
  • Résultat sauvegardé et retrouvé après redémarrage.
  • Échec expliqué sans confirmation trompeuse.

4. Rendre visibles les dépendances

Note ce que chaque fonction suppose : stockage, compte, connexion, autorisation ou service externe. Dans cet exemple, commencer avec une saisie manuelle et un stockage local peut permettre de tester l’usage sans créer immédiatement un système de comptes.

C’est un choix adapté à cet exemple, pas une règle pour toutes les apps. Si la valeur centrale dépend du partage entre personnes ou appareils, retirer le serveur peut retirer la raison d’être du produit. Réduis la complexité autour de la preuve, sans supprimer la preuve elle-même.

5. Transformer le cadrage en tâche pour l’IA

Donne à l’assistant le contexte, les limites et le résultat attendu. Exemple de consigne : ajoute l’enregistrement local d’une recette avec un titre obligatoire. Elle doit rester accessible après redémarrage. En cas d’échec, conserve la saisie et explique comment réessayer. N’ajoute ni compte ni synchronisation.

Demande-lui ensuite les fichiers modifiés et les vérifications pertinentes. Relis le résultat et exécute le scénario. Découpe la suite en étapes cohérentes : conserver une recette, la retrouver, puis gérer les ingrédients. Chaque étape doit pouvoir être évaluée avant la suivante.

6. Fixer la prochaine décision

Prépare une session courte avec quelques personnes correspondant à ton utilisateur principal. Observe si elles terminent la tâche, où elles hésitent et ce qu’elles font ensuite. Note séparément les difficultés actuelles et les idées de nouvelles fonctions.

Si elles ne retrouvent pas une recette, améliore ce parcours avant l’import automatique. Si elles réussissent mais reviennent systématiquement à leur ancien outil, cherche ce qui manque dans la situation réelle. Le MVP sert à choisir la prochaine étape à partir d’un usage observé.