Une équipe chargée d'améliorer un écran de prise de rendez-vous pourrait commencer par réorganiser son calendrier. Une équipe qui s'appuie sur le design thinking chercherait plutôt à comprendre pourquoi la réservation pose problème. Le véritable frein se trouve peut-être ailleurs : les gens ne savent peut-être pas quel rendez-vous choisir, s'ils y ont droit, ou comment organiser leur trajet une fois le créneau sélectionné.
Le design thinking donne de l'espace à ce questionnement global avant qu'il ne devienne trop coûteux de modifier la solution envisagée. Il associe recherche, cadrage du problème, idéation, prototypage et tests, en naviguant entre ces étapes au fil des apprentissages.
Mieux comprendre le problème change ce que l'on conçoit
Le Double Diamant du Design Council décrit une démarche qui va de l'exploration d'un défi à sa définition, pour ensuite développer et concrétiser des réponses possibles. C'est une excellente façon de distinguer la phase où l'on cerne le problème de celle où l'on choisit comment y répondre ; aucune des deux ne se fait comme par magie simplement parce qu'un atelier a eu lieu.
La recherche donne du corps à cette première phase d'exploration. Les entretiens utilisateurs peuvent révéler le contexte autour d'une réservation, tandis que l'observation permet de repérer à quel moment l'équipe doit intervenir ou quand les usagers abandonnent le parcours. Les constats doivent rester ancrés dans ces faits concrets lorsque l'équipe les formule sous forme de problème à résoudre. Dire que « les gens ont besoin d'un calendrier plus simple » présuppose déjà la solution. Dire que « les gens n'arrivent pas à identifier le bon rendez-vous avant de choisir un créneau » laisse le champ des possibles bien plus ouvert.
Cette nuance est essentielle dans notre exemple de prise de rendez-vous. Un meilleur calendrier pourrait simplement faciliter la réservation du mauvais créneau. Des descriptions de services plus claires, une vérification rapide d'éligibilité ou la possibilité de parler à quelqu'un répondraient sans doute au problème de manière plus directe.
Donner corps aux alternatives
Une fois le problème bien cerné, l'équipe explore plusieurs pistes et leur donne suffisamment de matière pour pouvoir les évaluer. Une simple esquisse peut faire ressortir des différences entre plusieurs parcours ; un prototype cliquable peut être nécessaire pour vérifier si quelqu'un arrive à sélectionner et réserver le bon service. Le niveau de fidélité du prototype dépend directement de la question posée.
Les tests doivent laisser la place à l'échec. Les participants ont besoin d'une mise en situation réaliste et de la liberté d'agir, plutôt que d'une présentation leur expliquant pourquoi le concept est pertinent. Les tests de prototypes de Ballpark permettent justement d'accompagner cette évaluation lorsqu'il s'agit d'une interface.
Ce qu'un atelier ne peut pas apporter
Une session dynamique peut faire émerger des pistes et aider les équipes à s'aligner. En revanche, elle ne remplace pas le contact direct avec les personnes concernées et ne résout pas les contraintes opérationnelles si personne en charge de la livraison n'a été consulté.
Considérez les livrables d'un atelier comme des pistes dont la solidité reste à prouver. Notez quelles observations soutiennent la direction choisie, ce qui relève encore de l'hypothèse, et ce que la prochaine phase de recherche doit vérifier. Le design thinking prend toute sa valeur dans ces décisions suivantes, y compris le choix parfois inconfortable de revenir sur un problème que l'équipe pensait avoir déjà réglé.