La chose la plus formidable que vous puissiez comprendre en construisant un produit est quelles sont les motivations derrière les actions des gens.
How we accidentally invented Job Stories
https://www.intercom.com/blog/accidentally-invented-job-stories/ par Paul Adams
Chez Intercom, nous réévaluons constamment nos processus pour construire un excellent produit, un produit que les gens trouvent de valeur et utile, un produit qu’ils aiment.
Une chose sur laquelle nous portons une énorme attention est la recherche. Nous embauchons des personnes avec de l’expérience dans la recherche directe et chacun dans l’équipe produit parle directement aux clients. Nous avons aussi embauché un Directeur de Recherche bien plus tôt que la plupart des autres startups : Sian Townsend qui a précédemment mené les équipes de recherche pour Google Maps.
Bien sûr, il est évident que vous devriez parler aux clients fréquemment pour essayer de comprendre leurs besoins, mais quel est le meilleur outil pour y répondre n’est pas évident.
Chez Intercom, nous pensons constamment aux choses à partir des premiers principes et très tôt nous avons appliqué ce focus sur comment nous parlons à nos clients. Nous étions les grands supporters de l’approche Jobs-to-be-Done (JTBD), mais la plupart de ce qu’a été écrit sur JTBD a été appliqué aux milk-shakes et barres chocolatées. Il y avait peu de recherches publiées sur la façon d’appliquer JTBD au développement de logiciel. Alors, nous avons créé notre propre processus basé sur ce que nous savions.
Les Personas pour l’empathie, pas pour la pensée nouvelle
Pendant la majorité de ma carrière j’ai utilisé des personas et des scénarios comme des outils pour comprendre les clients.
Popularisé par Alan Cooper dans The Inmates are Running the Asylum, ils sont depuis devenus l’un des outils le plus largement utilisés dans le panel de recherche et conception de l’équipe.
Cooper a aussi écrit un livre fantastique appelé About Face que je recommande à tous les designers qui rejoignent mon équipe, mais je leur dis de sauter les chapitres sur des personas.
Quand je travaillais chez Google, j’ai créé des douzaines sinon des centaines de personas à travers beaucoup de projets. Nous suivions souvent la soigneusement méthode de Cooper et nous créions aussi souvent des itérations de notre propre fait. Universellement, j’ai constaté que leur valeur était limitée. Ils aidaient souvent à construire de l’empathie entre les employés qui étaient déconnectés de leurs utilisateurs, mais ils menaient rarement à des idées révolutionnaires ou fraîches de réfléchir à un problème.
Nous n’avons jamais utilisé de personas chez Intercom.
Les motivations des personnes peuvent être très similaires quelques soient les démographies
La première fois que j’ai vraiment commencé à mettre en doute la valeur des personas était quand j’ai quitté Google et rejoint Facebook. Une des choses saisissantes à propos des données comportementales de Facebook sur leurs utilisateurs était combien le comportement des gens était similaire. Les personas m’avaient amené à croire que les gens sont vraiment différents, avec des objectifs vraiment différents, mais les similarités sont beaucoup plus grandes que les différences et peu importe la démographie que vous pouvez imaginer : la race, l’âge, le genre, etc. Par exemple, les motivations d’une mère mariée avec trois enfants aux États-Unis postant les photos d’un barbecue familial est essentiellement la même que celle d’un adolescent coréen postant les photos de la fête à la maison le soir précédent. Les buts et attributs semblent totalement différents, mais leurs motivations sont les mêmes.
Les personas ne nous mèneraient jamais à un même produit conçu et construit pour ces deux audiences. Alors que les meilleurs personas se concentrent sur les buts (les buts dirigent le comportement des personnes) aussi bien que les attributs, la réalité est que la plupart des personas se concentrent seulement sur les attributs des personas et même des personas dirigés par leurs objectifs ségrèguent artificiellement ces audiences. Les personas limitent artificiellement la cible de votre produit parce qu’ils se concentrent sur des attributs plutôt que des motivations et des résultats. Cette observation a détruit ma foi en eux comme outil.
Concevoir pour les motivations et les résultats est bien meilleur que concevoir pour des attributs. C’est la différence clef entre les personas et JTBD. Les personas regardent des rôles et des attributs, JTBD regarde des situations et des motivations. Les personas expliquent qui sont les gens et ce que font les gens. Mais ils jamais expliquent entièrement pourquoi les gens font quelque chose. Pourquoi les gens font certaines choses est beaucoup plus important.
Passer de ce que veulent les gens à pourquoi ils le veulent
Ainsi à la mi-2013 chez Intercom, nous nous sommes demandé quel pourrait être un meilleur outil que des personas. Nous parlions à des douzaines de clients chaque semaine et notre équipe de support client parlait à des centaines de plus, recueillant des demandes de fonctionnalités et comprenant les problèmes et les contraintes de notre produit.
Avoir cette relation directe avec nos clients a été inestimable, mais il y avait deux défis que nous avions besoin de surmonter :
- Les gens sont des experts dans leur problème pas la solution, mais il est plus naturel de suggérer une solution en forme d’une demande de fonctionnalité. La description d’une suggestion de solution est plus facile que la description d’un problème, mais vous devez retourner vers ces personnes avec des questions pour vraiment comprendre leur problème.
- Quand ils répondent, leur réponse initiale vous dira ce qu’ils veulent, sous forme d’attributs, mais pas pourquoi cela importe. Donc vous devez continuer à fouiller dans leurs motivations.
Il était donc critique que nous découvrions quel problème nos clients essayaient de résoudre et pourquoi ils avaient besoin de le résoudre.
Et une fois que nous aurions compris le problème, comment pourrions-nous faire de toute cette compréhension quelque chose d’actionnable pour l’équipe de conception ?
Les longs rapports de recherche et les packs de transparents de présentation avec des résultats de recherche sont difficiles à mémoriser et faciles à ignorer. Nous avions besoin de quelque chose de concis, de facile à communiquer et à se souvenir. Je ne peux compter chez Google le nombre de fois où nous faisions participer des gens à la recherche, à co-créer des Personas avec nous, seulement pour ensuite les ignorer parce qu’ils étaient trop difficiles à se souvenir, trop détaillés à analyser.
Se référer aux Personas n’est pas le chemin par défaut, en fait c’est le chemin de moindre résistance. Et souvent parce que les Personas ne sont pas assez concis pour des équipes développement rapide de produit.
En dehors des Personas, un autre outil très populaire est les User Stories, que le mouvement de développement de logiciel Agile avait popularisées. Nous n’avions jamais utilisé de User Stories non plus. Pour commencer, elles ne proviennent pas de recherche empirique et le format est technique plutôt que centré sur le client. Elles sont formatées pour décrire la fonctionnalité à construire, plutôt que les motivations des personnes.
Histoires de travail : Capturer des situations, motivations et résultats
Après avoir réfléchi à ce problème en repartant des premiers principes, nous avons inventé des Histoires de Travail, les Job Stories. Elles ne portaient pas ce nom en ce temps-là (Alan Klement l’a trouvé plus tard pour nous) mais le processus était là et fonctionnait bien pour nous.
Après avoir longuement considéré JTBD, nous avons créé notre propre approche centrée sur les situations, motivations et résultats :
[ Quand _____] [je veux faire _____] [pour pouvoir _____]
‘ Quand ____ ’ se concentre sur la situation, ‘ je veux faire ____ ’ se concentre sur la motivation et ‘ pour pouvoir ____ ’ se concentre sur le résultat. Si nous avons compris la situation dans laquelle les gens rencontrent un problème à résoudre, comprendre la motivation pour le résoudre et comprendre à quoi ressemble un bon résultat, nous sommes confiants que nous construirons un produit de valeur pour nos clients.
Les Histoires de Travail sont maintenant un outil clef pour nous. Elles garantissent que l’équipe est en mode recherche, que les membres de l’équipe comprennent si bien le problème qu’ils peuvent le capturer en un format concis. Et que leur résumé du problème peut être mis en action par toute l’équipe de conception et technique.
Avant que nous ne commencions un quelconque projet chez Intercom, nous créons un résumé d’une page pour le projet. C’est très simple et doit tenir sur une page d’A4 (qui est alors imprimée et collée sur les murs du bureau pour que les différentes équipes aient la visibilité du travail entrepris dans la société). Il a une section sur ses Histoires de Travail. Ces Histoires de Travail sont ce qui assure que nous comprenons le problème ou l’opportunité que nous abordons et elles nous tiennent focalisés sur celles-ci partout dans le projet.
Téléchargez le modèle au format Word ou PDF
Les personas y ont leur place. Dans des environnements politiques où les gens disent seulement ce que l’on veut entendre sur les besoins réels des clients, je les ai trouvés utiles pour gagner en acceptation; ils peuvent conduire un rapport plus fort avec les réels utilisateurs d’un produit.
Mais les personas sont :
- Laborieux à bien créer
- Trop concentrés sur les différences entre les personnes
- Et difficiles à se rappeler et à référencer.
En fait :
- Beaucoup de personnes avec des attributs divers ont des motivations très similaires
- Ces motivations sont faciles à rechercher
- Et le focus sur ce que vous construisez peut être capturé en une série de phrases courtes et mémorisables.
Commencez simple : Même si des 
Rassemblez les équipes projets et discutez des défis et des leçons apprises sur leurs projets. Facilitez les interactions avec le PMO. Ceci est une bonne manière de montrer la pertinence d’un PMO dans la promotion de l’apprentissage organisationnel et de le positionner comme le meilleur ami des équipes de projet.
DantotsuPM.com 