Définir — cadrer le bon problème
Synthétisez votre recherche en un énoncé de problème unique et précis avant de résoudre.
Why it works
La façon dont un problème est cadré détermine l'espace de solutions que vous pouvez même voir. Un brief vague (« améliorer l'appli ») garde toutes les options ouvertes et donc inutile ; un énoncé de point de vue (« les parents occupés ont besoin d'un moyen plus rapide de faire X parce que Y ») restreint l'attention à une cible résoluble. Le recadrage est le levier — la plupart des mauvaises solutions sont des réponses à la mauvaise question.
How to do it
- Regroupez vos observations en thèmes et choisissez le besoin utilisateur qui revient.
- Écrivez un énoncé de point de vue : [utilisateur] a besoin de [besoin] parce que [intuition surprenante].
- Transformez-le en question « Comment pourrions-nous… » qui n'est ni trop large ni trop étroite.
Données probantes
Mécanistique. La recherche sur le cadrage de problème montre que le cadrage initial contraint fortement les solutions envisagées ; les experts passent un temps disproportionné à définir le problème avant de le résoudre. (mechanistic)
La formulation spécifique « Comment pourrions-nous » est une convention de praticien ; le point sous-jacent est que le cadrage façonne la réponse.
Erreur fréquente
Écrire l'énoncé du problème avec la solution déjà intégrée (« les utilisateurs ont besoin de notre nouveau bouton »), ce qui bloque la pensée divergente dont dépend l'étape suivante.
Pratiquez cela avec IX Coach
More practices for Le design thinking, étape par étape
- Empathie — comprendre l'utilisateur d'abord
Observez et interviewez les personnes pour qui vous concevez avant de former toute solution.
- Idéer — générer des options avant de juger
Produisez de nombreuses solutions candidates, en différant l'évaluation jusqu'à avoir de la quantité.
- Prototyper — rendez-le bon marché et réel
Construisez la version la plus rudimentaire possible qui vous permet d'apprendre quelque chose de spécifique.
- Tester — laissez les utilisateurs le casser
Placez le prototype devant de vrais utilisateurs et traitez leur confusion comme une donnée.
- Itérer — traiter les étapes comme une boucle, pas une ligne
Revenez aux étapes précédentes quand le test révèle que vous avez cadré le mauvais problème.