Retour à Recherche et design

Modèles de cadrage du problème

Ne résolvez pas le mauvais problème. Utilisez le modèle de cadrage du problème pour aligner vos parties prenantes sur le ’Pourquoi’ avant le ’Comment’, en veillant à ce que chaque solution que vous construisez réponde à un besoin utilisateur vérifié ou à un objectif métier.

6 modèles

Explorer

Qu’est-ce qu’un modèle de cadrage du problème ?

Un modèle de cadrage du problème est un cadre collaboratif utilisé pour définir les contours, l’impact et la "véritable nature" d’un enjeu avant toute séance de brainstorming. Il fait passer une équipe d’une observation vague (par exemple, "Les utilisateurs quittent le site") à une mission structurée (par exemple, "Comment pourrions-nous réduire les frictions dans le parcours de paiement pour les utilisateurs mobiles effectuant leur premier achat ? "). Il sert de garde-fou contre le "biais de solution", lorsque les équipes se précipitent pour développer des applications avant de comprendre la difficulté humaine.

L’audit "Définition" : 3 façons de cadrer pour réussir

Un problème bien cadré est un problème à moitié résolu. Avant de finaliser votre énoncé de mission sur Miro, appliquez ces trois contrôles d’expert :

1. L’audit de profondeur "5 Whys"

Audit : Votre énoncé de problème n’est-il qu’un "symptôme" (par exemple, "Le site est lent") ? La solution : Vérifiez les causes profondes. Utilisez la méthode "5 pourquoi" dans votre modèle pour creuser davantage. Si le site est lent, pourquoi ? Parce que les images sont trop volumineuses. pourquoi ? Parce qu’il n’y a pas d’outil de compression. pourquoi ? Parce que le budget n’a pas été alloué. Formuler le problème comme un problème d’allocation des ressources conduit à une solution bien différente de la simple "correction du code".

2. Le test "Qui, quoi, où, pourquoi"

Audit : Votre énoncé de problème est-il trop vague (par exemple, "La communication est difficile") ? La solution : Vérifiez la spécificité. Un cadre professionnel doit répondre aux questions suivantes :

  • Qui : Qui rencontre précisément ce problème ?

  • Quoi : Quel est l’obstacle précis auquel ils sont confrontés ?

  • Où : Dans quel contexte ou environnement cela se produit-il ?

  • Pourquoi : En quoi cela compte-t-il pour l’entreprise ou pour l’utilisateur ? Si vous ne pouvez pas remplir ces quatre catégories, votre problème est un "thème", pas un "cadre".

3. Le pivot "How Might We" (HMW)

L’audit : Votre problème est-il formulé comme une "plainte" plutôt que comme une "opportunité" ? La solution : Contrôlez la présence d’un langage génératif. Transformez votre énoncé final du problème en une question How Might We. Un bon HMW est suffisamment large pour permettre plusieurs solutions, mais suffisamment ciblé pour orienter l’action. (par exemple, "HMW faciliter aux parents très occupés le suivi des indicateurs de santé de leur enfant ?")

Cadres stratégiques : de quel modèle de cadrage avez-vous besoin ?

Sélectionnez le modèle Miro qui correspond au point de départ de votre projet :

  • Le canevas d’énoncé du problème :

    • Idéal pour : Aligner de grandes équipes transversales sur une mission commune.

    • Objectif : Cartographier l’utilisateur, le problème, le contexte et l’impact dans une seule grille visuelle.

  • Le cadre « Tâches à effectuer » (JTBD) :

    • Idéal pour : L’innovation produit et la priorisation des fonctionnalités.

    • Objectif : Formuler le problème comme une « tâche » que l’utilisateur confie au produit (par exemple, « Quand je suis [Situation], je veux [Action], afin de [Outcome]. »).

  • La "Échelle d’abstraction":

    • Idéal pour : Quand une équipe est bloquée sur un problème technique très circonscrit.

    • Objectif : Se déplacer "vers le haut" de l’échelle (Pourquoi ?) pour identifier un problème plus large, ou "vers le bas" de l’échelle (Comment ?) pour trouver une exécution technique précise.

Composants clés d’un modèle de cadrage du problème

Un tableau Miro performant pour le cadrage du problème doit inclure ces cinq éléments essentiels :

  • Le persona utilisateur : Une brève description de la personne précise confrontée au problème.

  • État actuel vs. État souhaité : Une comparaison visuelle entre l’état actuel et l’état souhaité.

  • Galerie de preuves : Données réelles, citations d’utilisateurs ou captures d’écran qui démontrent l’existence du problème.

  • Métriques d’impact : Que se passe-t-il si nous ne résolvons pas ce problème ? (p. ex. : perte de revenus, taux de désabonnement élevé, risques pour la sécurité).

  • L’« énoncé du problème » final : Un résumé d’une à deux phrases qui sert de repère pour le projet.

Pièges courants dans le cadrage du problème

  • La « solution déguisée » : Présenter le problème comme « Nous avons besoin d’un chatbot IA ».

    • La solution : Supprimez toute mention de technologie de l’énoncé du problème. Le problème est « les utilisateurs ne trouvent pas de réponses rapidement », pas « nous manquons d’IA ».

  • Ignorer le cas d’affaires : Formuler un problème que rencontrent les utilisateurs, mais qui n’a pas d’importance pour l’entreprise.

    • La solution : Assurez-vous que chaque cadrage du problème inclut une section « Valeur pour l’entreprise » pour justifier l’investissement.