@Alexis Gérôme Merci pour ta réponse. Je pense personnellement qu'elle fait partie du design mais qu'il faut plutôt revoir notre définition et le caractère organisationnel de ce dernier. Actuellement le design est souvent incompris dans les entreprises même celles spécialisées. Il devrait être une ligne directrice dans les decisions de l'entreprise, dans sa culture et dans l'expérience de tous ses collaborateurs et non un moyen dans la case produit comme je le lis et vis beaucoup trop souvent. Le design c'est le pouvoir de motiver les meilleures décisions possibles à tout niveau et de ce fait la recherche a son rôle à jouer 🌟

@Laurent Sadeg Très bonne question.

1. Je pense que les structures actuelles qui gèrent la research sont une dette organisationnelle. Historiquement l'UX research vient de l'HCI, et dans un passé pas si lointain, un UX faisait tout (dont la research). Récemment les spécialisations ont commencés à être pertinente vu la nature très différente du métier et l'évolution du poids des équipes produits x design en interne. La research s'est greffé à l'évolution de ces fonctions car on est souvent la dernière roue du carrosse.
2. Cela a favorisé la construction silos de connaissances (market vs product par ex) où les fonctions sont dédoublées, et les process entre les deux pas très smooth. 
3. L'appartenance à un département particulier limite le champ d'action pour des questions méthodologiques (évaluatif en chaine etc..) ou des questions politiques ( priorité au département d'utiliser le researcher, ne pas partager la rare ressource de la research avec d'autres, le fait d'appartenir au design limite la diffusion etc..)
4. Au final cette structure (commune) limite l'apprentissage et l'impact de la profession en interne. Notre travail est souvent de manière très transverse entre différentes divisions, et nos insights pareil. J'ai souvent collaboré avec des divisions produits, hardware, PMM et Data sur un seul projet.
5. Pour finir skillset et évolution interne cet article en parle très bien: https://ux.wikihero.org/experience-utilisateur-ux/recherche-utilisateur/ux-researchers-are-not-designers-at

@Thierry Raguin Et encore... J'avais de l'espoir plus jeune que suite à de gros plantages ça pourrait faire évoluer les choses mais ma dernière expérience m'a convaincu du contraire.

Grosse licorne, je bosse sur un sujet d'innovation , nouveau BM, et hautement stratégique dans son portfolio produit. Les retours sont très mauvais pour notre base core, je change de mission et je découvre que 10 mois après ils lancent sans plus aucune research.

Ils se font dézingués par leur base client. Le chairman (ex-founder) écrit personnellement un mea culpa sur reddit mais ils surenchérissent (les users ont tort blablabla), et aujourd'hui continuent dans cette voie.

@Alexis Gérôme Sur la montée en maturité, pur design ops : observation + diagnostic + solution + test and adapt ;)

@Alexis Gérôme Sur la montée en maturité, pur design ops : observation + diagnostic + solution + test and adapt ;)

@Alexis Gérôme

Je pense que les équipes produits, en particulier en France, sont encore très juniors et n'ont pas eu le temps ni la maturité pour prendre du recul.

Cela s'illustre principalement par des PM qui pensent devoir et pouvoir tout faire, et notamment la recherche. Concrètement ça donne des recherches souvent très mal faites et biaisées, et ça se contente de faire de l'A/B testing dans tous les sens... et on part sur des feature teams qui produisent de la feature mais pas de valeur... Je caricature à peine ^^

Ce genre de fonctionnement ne peut pas durer éternellement et il va falloir une prise de conscience et une évolution...

Et tout bêtement on retrouve ce problème dans l'article que tu cites avec notamment cette phrase : "A product team means, at the least, one representative of the engineering, design, and product perspective."

C'est subtil mais pour moi la base du problème est là :

"Product" devient un fourre-tout qui n'a plus aucun sens et sert même à s'auto-définir...

Si on remet les bons termes (au passage j'ai ajouté un "User" en parenthèses pour le domaine "Design" et j'y reviendrai plus tard), c'est plus clair et ça devient plus facile de définir les rôles indispensables :

Soit Engineering / Tech Lead, Product Designer, Product Marketing Manager avec un PM qui chapeaute le tout si on veut un pilote unique. Ça peut très bien fonctionner avec un trio pour piloter aussi et ça évite le risque de déséquilibrer le produit.

Donc si on garde un PM (et même si on le fusionne avec le PMM), les choses sont plus claires et on évite le PM qui croit qu'il doit tout faire tout seul. Le PM va alors réellement devoir s'appuyer sur les spécialités et expertises de l'équipe dans chaque domaine. Son focus va être de maintenir le cap vers la vision et la stratégie produit, donc apporter de la valeur, piloter l'équipe, prioriser les activités, etc. Cela nécessite notamment d'avoir une compréhension des activités de chacun donc une connaissance de base dans différents domaines et une participation (mais pas réalisation) aux activités de recherche notamment.

En plus de ça, si on prend le domaine "Design (User)" (mais ce que je décris vaut pour les 2 autres domaines), c'est un vaste domaine qui touche à toute les phases du cycle de vie d'un produit (strategy, discovery et delivery). Une seule personne peut rarement tout traiter efficacement en même, pour des raisons de temps / disponibilité, pas forcément de compétences. La plupart du temps, il va falloir une équipe avec différents profils à temps plein ou partiel en fonction du contexte. On peut donc avoir un lead / head of qui intervient pour assurer une vision et une direction, un UXR freelance qui intervient pour mener une recherche spécifique à un instant T, un service tiers pour mener des tests utilisateurs, etc. Il y a plusieurs moyens d'organiser ça en fonction de l'entreprise, du produit et des équipes.

Donc je pense que les UXR ont clairement leur place dans les équipes produit mais pas toujours à 100%. Certains produits vont nécessiter un UXR à temps plein. Pour d'autres, ça sera plus ponctuel ou "saisonnier" et dans ce cas, l'UXR peut être multi-produits ou en freelance.

Mais il faut clairement un gain en maturité produit pour évoluer. Idéalement ça arrivera de manière organique avec de la pédagogie et du bon sens. Au pire, ça arrivera suite à une série de gros plantages...

@Alexis Gérôme pourquoi pas au design ?

@Antoine RIGAUDIAS (side question - tu utilises quoi pour "monter" de niveau de maturité ?)

Oui pour moi la Research en devrait pas appartenir au produit ni au design. C'est quelque chose à part, la question c'est comment l'organisation supporte et met les ressources pour. 

@Thierry Raguin Oui en effet. Au niveau CI et global c'est très clair. Mon interrogation porte sur la composition de ces équipes produits. Est-ce que l'UXR sera présent ou non.

est que cela va arriver seulement dans les grosses corporates qui ont le luxe de payer la spécialisation ?

Ca représentera combien de % du marché ? Est-ce que l'on peut parler de 20% de structures bien définie et spécialisées et le reste qui privilégiera les Pm?

Ce que j'observe petit à petit c'est que le travail de discovery est pris par les équipes produits . Avoir un UXR dans ce set up sera une exception plutôt que la norme. (dans le bouquin Torres n'en parle même pas)

j'ai échangé avec ce researcher qui à écrit ce post intéressant - https://www.davesresearch.com/continuous-discovery/

C'est là où va la discovery, et vu la force que cela à, ce n'est pas prêt de s'arrêter. La question jusqu'où? 

Je partage... mais pas complétement... dans la boite dans laquelle j'interviens, je prévois de passer à un niveau de maturité supérieur en sortant effectivement la recherche des équipes produits, mais pour lui donner plus de force, d'autonomie, et surtout de briser les silos qui existent dans cet environnement (presque 20 produits et programmes différents, en cadrage ou build, avec une squad sur chacun... ). Mais les researchers resteront dans cette zone pour continuer à influencer au max, et ne pas remettre de la distance avec ces squad produits qui doivent continuer à sentir leur influence et que la recherche doit nourrir encore et encore. Mais tu as raison, la recherche va s'émanciper un peu plus.

Je ne pense pas que les 2 approches soient incompatibles.

En effet, avoir une branche Insights globale est intéressante pour mener une recherche continue globale pour une entreprise, autour de ses clients (Consumer Insights) et des ses employés (Employee Insights). Suivant la taille de l'entreprise, CI et EI peuvent être 2 équipes indépendantes ou 1 seule et même équipe. Ça permet de traiter les sujets de fond avec des équipes pluridisciplinaires (User/Design Researchers, Marketing, HR, Data Scientists principalement).

Le travail de ces équipes transverses peut ensuite aller nourrir des équipes produits dédiées (ou donner naissance à une nouvelle équipe produit) qui vont avoir besoin de Product Researchers & Designers plus spécialisés et accompagnés de PM orientés Product Marketing Managers (pour le côté B2C) ou HR Manager (pour le côté Employee Experience) et Lead Tech. Ces équipes Produit vont donc avoir un périmètre plus ciblé que les équipes Insights et vont pouvoir remonter vers les équipes Insights avec les outputs de leur produit mais aussi parfois des "commandes" de recherches plus globales.

@Antoine RIGAUDIAS Oui je connais l'UX fund, c'est un exemple intéressant de 2015-2016. A voir ce que ça donne aujourd'hui. 

On n'a pas la même lecture de l'article. Niveau contexte, ça fait un an que les UX font face à des layoffs, des restrictions de budget et une introspection venant de plusieurs figures C-level des US (Ex research Director Meta et d'autres..). En gros on a fait du mauvais boulot, et on n'a pas réussi à prouver notre valeur.

Et c'est ça justement le bas du problème, et le postulat de ces dernières années. Advocate, advocate, être utile, et les budgets viendront.

La majorité des équipes se positionnent de base comme devant se justifier comme stratégie, et en réalité se démènent de répondre à toutes les demandes des autres équipes. 

Cela amène à une réduction de la qualité de notre travail, et comme Marévéry le dit si bien à habituer les équipes à une certaine médiocrité en termes de recherche. (en gros ca devient la new normal)

En réalité, l'auteure interviews des managers qui ont fait le contraire et où cela à marché.

Partir d'un point de départ où ton temps est précieux, car la qualité de ton travail n'est pas remise en question est un rappel important en termes de mentalité en ce moment.

Après il faut dire non, savoir argumenter , communiquer etc.. Cela ne veut pas dire être difficile à travailler, mais communiquer un certain standard en terme de qualité de travail.

Ce n'est pas la seule solution disponible, mais c'est au moins une piste solide. L'ayant vu autour de moi, cela amène plus de résultats que l'auto-flagellation.

Je sais pas si tu as vu passer l'article sur l'UXfund, les gens qui ont créé un portefeuille d'actions boursières dont le seul critère d'achat etait la maturité en design... en quelques années +450% et des brouettes. j'essayerai de le retrouver.

Pour cet article, je serais moins catégorique que toi peut etre.

il faut etre pret a demontrer et ca demande du travail... mais ce que je lis entre les lignes dans cette article, c'est que dans les exemples cité la personne n'a ni priorisé une initiative particulière pour démontrer une fois son impact réellement, elle a essayer de tout faire en meme temps, ni géré sa ressource (elle meme en fait) efficacement, en refusant également de travailler sur des sujets pour lesquels les conditions de réussite n'étaient pas réunis.

il faut aussi savoir refuser des collabs, meme en interne, et créer du fomo en meme temps qu'on démontre par ailleurs... je suis pas tout a fait en accord avec sa démarche, meme si sur le fond, elle a raison.

Etre placé en situation de tjs devoir démontrer et justifier, c'est aussi une technique manipulatoire qu'il faut savoir désamorcer. et qund on est junior on ne sait pas forcement le détecter, et le contrer. Ca montre a quel point la maturité, en design, comme dans l'entreprise, peut créer un contexte favorable ou non. Totalement raccord avec les conseils en fin d'article effectivement, mais je pense que ce genre de contexte s'installe souvent quand on est jeune dans sa pratique, moins quand on prend de la bouteille :)

@Alexis Gérôme pour commencer je pense que l'usage à tout va du terme empathie ou empathique doit être évité. Ce que j'adore voir, c'est des exemples concrets de pratique empathique: par exemple, une exploration qui a permis d'établir un besoin sous-jacent, une démarche visant à creuser les observations pour comprendre les motivations profondes. Cela peut passer par 10 minutes d'entretien à la suite d'un test utilisateur par exemple, ou la capacité de se détacher du produit pour explorer l'environnement des utilisateurs, sans penser à la solution. Mais cela passe aussi par le comportement du candidat pendant l'entretien: savoir mener un entretien d'embauche, c'est aussi savoir poser les bonnes questions, savoir identifier les besoins de l'équipe et y répondre de façon ciblée. En somme, c'est savoir démontrer sa capacité à creuser, à décortiquer, à comprendre. C'est une curiosité systématique et méthodique. J'observe aussi la capacité d'écoute du ou de la candidat(e). Ai-je droit à des réponses parfaites mais lambda ou s'agit-il d'une réflexion plus personnelle? Est-ce qu'on me challenge pour donner des infos valables ou on s'en tient aux 10 questions à poser trouvées sur Google? L'empathie cognitive se démontre, en somme :)

Super point ! Donc première question qui me vient à l'esprit. Quels bons exemples d'empathie cognitive as-tu pu observer sur des profils de professionnels ou comment le mets-tu en valeur dans ton propre cv / portfolio ? :)