
- merci! Utile
- Pas utile
- Pas sûr
@Marine Wolffhugel canon ! Merci Marine
@Laurent Sadeg Hello Laurent - Oui je vois ton point de vue, et je suis d'accord. Ensuite c'est une question de définition et de hauteur à laquelle on se place.
A cause de limite de compréhension des autres "fonctions" ou C-levels, la recherche pour moi doit être un cercle indépendant.
La prise de décisions est transverse et va au delà du produit. Ca inclut de servir ces autres fonctions, et ne pas être rattaché à un groupe en particulier.
Surtout, ca amènerait du poids pour aller monter au niveau Exec, et pas être là de temps en temps ou par stakeholders interposés. (C'est là que l'on réalise le meilleur travaille)
Un exemple réel revient à se baser sur l'organisation des services de renseignements et le dialogue direct qu'ils ont avec les membres du gouvernement.
Toujours aussi à rapide à transmettre les dernières actu!
Je venais de le lire un jour avant que tu le partage.
Voici une liste des fees de Wise que j'ai reçu après avoir demandé au support, en gros de 1 à 2.9% sur les paiements.
Pensez-y lorsque vous facturez.
Connais-tu l'Atomic Research ? C'est une méthodologie de structuration de la recherche sur 4 niveaux :
Outre la structure qui apporte de la clarté, cela permet également de justifier plus facilement de la valeur des remontées :
Tu vas donc pouvoir avoir progressivement une arborescence permettant de prioriser les Recommandations qui découlent du plus d'Idées, de Faits et d'Expériences et qui ont donc le plus de valeur (je simplifie un peu car toutes les expériences n'ont pas forcément la même valuer intrinsèque).
Du coup, quand tu présentes tes Recommandations par ordre d'importance, tu peux facilement la justifier avec tout ce qu'il y a derrière : "la Reco 1 est prioritaire car elle découle de ces 2 Insights. Ces derniers viennent des 5 Faits suivants qu'on a collectés en menant X, Y et Z (les Expériences)".
Et dans certains cas, surtout au début de tes recherches où tu auras peu d'Expériences, tu vas avoir des Recommandations assez hypothétiques. C'est normal et c'est l'occasion d'itérer. Tes recommandations principales deviennent tes hypothèses de recherche pour tes prochaines Expériences et iront nourrir le modèle pour obtenir de nouveaux Faits qui découleront sur des Idées puis des Recommandations : ça en renforcera certaines que tu avais déjà et ça permettra d'en découvrir de nouvelles.
Il me semble normal d'être challengé sur des remontées individuelles uniques. C'est plutôt sain et il faut derrière chercher à comprendre s'il s'agit bien d'un problème isolé ou au contraire généralisé.
La première approche peut être d'essayer de confirmer la problématique via d'autres sources : observer / demander à d'autres utilisateurs (futures interviews ou enquête pour avoir du quanti éventuellement), vérifier via les données d'analytics, confronter par rapport à des standards / heuristiques / bonnes pratiques / concurrents, etc.
Suivant le sujet et si ça parait potentiellement important, ça peut également devenir une nouvelle hypothèse de recherche pour lancer une étude quali et/ou quanti sur le sujet pour vraiment le creuser.
@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 🌟
Je pense que ça dépend de l’organisation de ton équipe et de la capacité de l’équipe de recherche à faire de la recherche. Parfois il y a trop de recherche à faire pour le nombre de researchers en place et ça devient essentiel d’avoir d’autres “people who do research” (PWDR) comme des Product Managers. Dépendament du contexe, c’est pas nécessairement une mauvaise chose.
D’un côté, il y a quelque chose de cool à ton histoire. Le PM est intéressé, il a l’air de vouloir faire de la recherche, d’aller chercher des données pour prendre ses décisions. Et pour moi c’est exactement là que tu dois jouer tes cartes. Apprendre à parler le même langage business que lui, et prendre ça comme une opportunité de l’éduquer sur la validité des résultats qu’il va recevoir en leadant la recherche. Ultimement, un PM va vouloir faire de la recherche pour quoi? —> Pour prendre des bonnes décisions produit. Si les résultats sont mauvais, ses décisions le seront tout autant.
C’est plate à dire, mais c’est nécessaire d’expliquer que sa recherche ne sera/n’est pas valide et d’expliquer les raisons pourquoi. Je pense que c’est important de s’affirmer comme la personne experte de son domaine et d’amener le PM à te voir comme son partenaire plutôt que son exécutant. Cette dynamique-là est aussi entre nos mains comme UXR.
J'aime beaucoup ce retour d'expérience et ta question, car elle fait écho à l'expérience de nombre de UXR. J'ai observé cette évolution et je crains qu'il ne soit trop tard pour faire retour arrière. La pression venant de la hiérarchie n'aide pas: les PM sont invités (pressés) de connaître les utilisateurs, de comprendre les dynamiques d'achat et de conversion.
Dans ce contexte, il me semble qu'il ne te reste qu'une chose à faire: te positionner de façon stratégique. Mais avant toute chose, je m'interrogerais sur ce qui fait que tes PM te court-circuitent:
Se pourrait-il qu'ils craignent que faire appel à un UXR les ralentisse? Ont-ils une pression de leurs stakeholders et des KPIs reposant sur le nombres d'utilisateurs auxquels ils ont parlé?
Dans la situation actuelle, la collaboration est quasi-nulle et tout le monde en pâtit (toi surtout, car tes collègues ne semblent pas être conscients de leur incompétence). Pour rétablir l'équilibre et te permettre de te positionner comme référence en terme de UXR, il va te falloir:
Une stratégie qui a bien fonctionné pour moi a été de me positionner comme un chef de projet de recherche. Ma première initiative a été d'aligner nos objectifs communs: cela m'a permis de ré-établir la communication et de mieux comprendre ce qui les amène à "envahir" sur mon terrain. Une fois que nous nous étions mis d'accord sur un point commun, il était temps d'établir les "frontières" de nos domaines de compétences.
Nous avons alors établi de grands axes de recherche et j'ai pu leur démontrer les forces et faiblesses de leur approche. Ici, mon rôle était celui d'un consultant: je comprenais leur objectif et leur proposais des activités efficaces et correspondant à leurs capacités.
En parallèle, j'établissais mon propre plan de recherche plus "foundational" et stratégique, et renforçais ainsi ma position. Les PM avaient un guide et des méthodes établies et adaptées leur permettant de "mener" des activités de recherche indépendamment — je les ai coaché pour leur permettre d'obtenir des résultats satisfaisants. Mais en aucun cas je n'ai cédé mon expertise: j'ai simplement pivoté vers un travail de fond, de gestion de l'insight.
Idem pour l'analyse: établie un score de qualité de la data. Si celui-ci n'est pas atteint, la data n'est pas valide et devra être écartée. Montre leur de façon très concrète les conséquences néfastes d'un mauvais insight (impact financier, réputation, etc.)
Enfin, propose leur de te soumettre leurs questions en amont, avant même de penser à mener des entretiens: peut-être as-tu déjà les réponses à leurs questions: passe d'un statut réactif (je dois faire de la recherche sur leur demande) à un statut pro-actif (tel et tel insight vous permet de prendre une décision informée). Tu peux aussi te joindre à leur sprint planning ou aligner ton research backlog sur le product backlog.
Ceci n'est pas une solution magique, mais pourrait te permettre de rétablir le dialogue et te sécuriser ta position.
@Laurent Sadeg Très bonne question.
@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 ?
@Kevin Richard Merci kevin pour ta réponse - Super intéressant Faudra peut être que l'on organise une session sur utiliser le Cynefin Framework sur un as concret qu'en dis-tu?
Tiens j'ai lu ce post sur les Wardley maps - une autre idée qui me vient à l'idée pour organiser une session: https://www.davesresearch.com/wardley-mapping/
@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ù?
Le PM c'est juste un marketeux déguisé... pas de research qui ne soit organisée, conçue, menée à bien, et exploitée par quelqu'un hors de l'équipe Research&Design... Chacun sa spécialité. Ce n'est pas la sienne. En début de projet, avant ou pendant le kickoff, rappel des roles et responsabilités de chacun. on met les pied dans le plat et les points sur les i. mais on attend pas d'avoir commencé.
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.
Merci du share - en effet c'est intéressant. En ce moment il y a une renaissance du côté hardware à cause de l'AI. C'est malheureusement hyper dystopique entre black mirror et d'autres films de SF.
My 2 cent c'est que ces entreprises lèvent avec un but B2C en tête, mais que les applications actuelles seront peut-être plus tournées B2B car c'est un usage restreint et moins contraignant que la vie de tous les jours (vie privée etc..)
Je vais reposter des articles sur la renaissance du hardware - c'est un peu ce que j'ai lu récemment - le dernier article de Stratechery en parle aussi: https://stratechery.com/
Bien vu Quentin ! Merci :)
Ca fait une belle addition aux ressources.
Je ne "like" pas, mais visiblement le buzz du design thinking est passé à autre chose.. Merci pour le partage !
Super question effectivement!
Avant de répondre veuillez noter plusieurs points:
Ce que le monde du business et du design aime appeler "discovery" et plus généralement appelé "exploratory research" dans la littérature. Et à l'inverse de ce que certains product manager aimerait nous faire croire, ce n'est pas une nouvelle (ni récente) discipline. Je parle moi-même bien plus souvent "d'exploration" que de "discovery".
Ce qu'il est important de comprendre dans une telle phase, c'est que nous essayons d'abord de résoudre un *problème de connaissances*, ou pour être plus exact, un problème de "création de sens" (sense-making) qui a un niveau de granularité suffisante pour nous permette d'agir. Ici on ne sait pas ce qui sera utile de savoir jusqu'a ce qu'on le trouve ! C'est important car une approche réductive comme on en voit beaucoup en UX/produit ne fonctionne pas dans ce genre de situation.
On appel cela des "domaines de prise de décision", et ils impliquent une relation entre le contexte, notre niveau de compréhension de ce contexte, et notre capacité d'agir dans celui-ci.
On peut donc différentier plusieurs domaines (ou contexte) de prise de décision (voir Cynefin framework) :
Cela requière deux choses dans la nature de l'approche :
Je ne peux que conseiller d'être critique (voir méfiant) face à ceux qui vous promettent des merveilles au travers d'une approche rigide et qui pousse systématiquement vers une convergence forcé: c'est ce qu'on appel un "processus entonnoir" (funnelling process) qui amène toujours vers la selection de "la meilleure option" (ex. Lean startup, Design Thinking, Discovery discipline, etc.) est ici dangereux.
C'est dangereux car le processus favorise un glissement rapide du complexe vers le compliqué et le clair. Le risque est de se retrouver dans une "convergence prématuré" (local optima/sub-optima), un état où la diversité des options à disposition s'effondre et où l'on est forcé dans des choix limités –et donc qui paraissent "évident" sur le moment– mais du coup extrêmement fragiles aux changements et variations du contexte.
Cela parait contre-intuitif, mais le genre de de processus souhaitables ici sont des processus dit "de superposition" (layering process) qui permettent d'ajouter des options et des nuances plutôt que les réduires. Ce que l'on cherche à faire c'est pouvoir assimiler la complexité du contexte (faire du sens), puis de pouvoir la décomposer (de façon non linéaire) et la recombiner pour pouvoir en adresser certains aspect de manière plus ou moins direct (résoudre vs. dissoudre les problèmes). Ce genre de processus donnent un cadre sans pour autant prédéterminer le résultat, laissant donc de la place pour la découverte (et l'inattendue).
Car, pour revenir au problem de connaissance, on ne peut pas planifier pour ce que l'on sait pas mais on peut créer un cadre qui amène à une certaine compréhension qui nous permet d'avancer malgré l'incertitude.
La Participatory Narrative Inquiry (PNI) (1) (2) est approche de recherche qui, à l'inverse d'un questionnaire où l'on pose des questions sur des éléments pré-établis qui à tendance à ne donner des réponses uniquement à ce que l'on à penser demander, commence par une invitation à partager une histoire ou une expérience, puis de demander de catégoriser cette expérience sur des critères comparables d'un répondant à un autre.
C'est une approche est appelé "MassQual" car elle combine qualitatif (l'histoire) et quantitatif (critères de qualification de l'histoire).
Par exemple, dans cette étude ciblant des designers de tout horizons, il leur était demandé de partager une histoire sur leur expérience de devenir designer (1), puis de catégoriser leur histoire sur des critères de qualification (2), par exemple si leur histoire est positive ou négative (échelle), comment leur histoire les fait se sentir, ce qu'ils avaient besoin (échelle), etc.
PNI utilise aussi un format de capture de l'inclination des participants sur des sujets imbriqués, appelé "tripole". Cela à l'avantage de créer beaucoup plus de nuances dans les réponses.
Dans l'exemple ci-dessus, chaque point est une histoire. Cela permet d'identifier des clusters, puis pour chaque cluster de voir le genre d'histoires associés.
@Alexis Gérôme @Inès Chupin merci pour vos réponses !
Je suis assez d'accord avec vous, bien que ça m' arrive de dévier de temps en temps. Par exemple, de faire une mission d'UX writing, car j'ai fait de la rédaction dans le passé et c'était cool de retourner à ça. Mais le métier d'UX writing étant beaucoup évolué depuis, je ressens de plus en plus un syndrome d'imposteur par rapport à ces expertises.
Donc en effet faut avoir une vision claire de son métier, et avoir une minimum d'appétence pour la compétence requise en plus, je dirais.
Merci ! belle piqûre de rappel - C'est dans ma liste de lecture depuis bien trop longtemps. Je serais curieux d'avoir ton REX et pourquoi pas une anecdote de comment tu te prépares à ce genre de discussion en amont et comment tu as mis en pratique le livre.
Je vais l'acheter de ce pas!
@Mathieu Baudonnat de rien, c'est vraiment une méthode simple et qui peut se faire en asynchrone en envoyant à chacun la grille à noter et à commenter. Et c'est vraiment très pratique en phases très amont mais aussi quand on a des éléments plus précis, la faisabilité devenant alors quelque chose de beaucoup plus précis.
@Thierry Raguin
Merci! J'aime bien ton approche qui permet d'évaluer simplement avec toutes les parties prenantes, on va s'en inspirer je pense :)
@Mathieu Baudonnat, voilà ce que j'ai l'habitude de faire dans ce genre de situation :
@Inès Chupin - Oui ils ont un coin B2B pour ton entreprise, et en un clic tu peux activer la paiement par CB (ça envoie un lien) - J'ai activé - pas encore essayé (discussion avec les finances du côté de mon client) - mais ça peut être pas mal pour les paiements en mode advising ou les acomptes.
J'utilise aussi Wise que je trouve un super moyen de voyager et payer dans des devises étrangères sans se faire assassiner par le taux de change pratiqué par sa banque et les frais annexes.
Je ne connaissais pas l'option "paiement en CB" mais c'est très bon à savoir.
Vaste question et je crois qu'on est beaucoup à être dans cette situation.
Je suis strictement UX Designer. Toutes les demandes de profils hybrides UX/UI, j'explique que cela ne correspond pas à mon expertise, que de mon point de vue ce sont deux métiers très différents et que j'ai préféré me spécialiser en UX.
De plus en plus souvent, il y a la question du copywriting/UX writing/content design qui se pose dans la phase UX. Là encore, j'explique que c'est un métier et une expertise spécifiques (qui n'est pas la mienne). Mais je considère que c'est important de poser des intentions en mettant des titres de contenus type "Titre de section expliquant en quelques mots la valeur du produit", ou je mets des contenus de texte dans les CTAs (Ajouter au Panier, Commander, etc) sinon je considère que ca rend difficile la lecture des wireframes, et la passation en Content Design. Je précise néanmoins à chaque fois que c'est un contenu indicatif qui a vocation a être retravaillé par une personne experte.
Pour ce qui est du SEO, là encore, c'est une expertise (qui va bien souvent à l'encontre des besoins de l'utilisateur) donc en fonction des projets, on tâche de mettre dans la boucle un(e) spécialiste en SEO pour implémenter dans les wireframes les bonnes pratiques.
Pour la recherche, je trouve que c'est la ligne la plus difficile à établir. Personnellement, je trouve que c'est très utile de participer à une phase de discovery pour réaliser au mieux de la phase de UX Design. Si je peux la mener moi-même je trouve ça top, donc j'accepte les missions qui demandent une phase de recherche.
La différence c'est que je ne vais pas prendre une mission stricto sensu de UXR sur un temps long.
Très bonne question Julia - je pense que cela arrive car maintenant les entreprises sont limitées niveau cash, donc elles essayent de tout avoir.
Après, il y a une ignorance forte de nos métiers qui est normale. (Connaître les subtilités c'est pas leur quotidien - un peu comme mon cas récemment j'ai eu le cas entre un chauffagiste et un Frigoriste pour de la clim)
Du coup de mon point de vue il y a 3 trucs à faire:
Super - merci beaucoup !
N'hésitez pas à me contacter directement, je suis UX dans le médical et co-fondateur de Health Squad france :)
@Mathieu Baudonnat Ok je comprends, je suis passé par là. En fait dans l'esprit des équipes on est recherche. La recherche historiquement c'est du market research.
C'est ce qu'ils apprennent à l'école, dans les bouquins etc..
Donc bien que les deux se complémentent c'est très dur dans l'esprit des gens de comprendre la différence mais c'est comme les devs. Il y a des front et des backs, peu de full-stack pour une raison.
Après faut attention dans le discours, il ne faut pas braquer l'équipe en rejetant ces responsabilités. Historiquement c'est le rôle du PM de faire ce travail là, avec des analystes etc.. mais dernièrement les PM préfèrent la discovery..
@Alexis Gérôme
Tu me rassures dans ce que tu dis.
Ca fait quelques jours que j'essaye d'expliquer à tout le monde que le taff de la research ce n'est pas de prioriser des opportunités business car nous n'avons pas tous les tenants et aboutissants mais qu'on peut aider sur les solutions (et encore, il y a la complexité technique qui ne nous appartient pas).
J'avais proposé une méthode de calcul dérivée du RICE qui permet de scorer les opportunités sur la base des connaissances utilisateur tout en rappelant que ce n'était qu'une estimation qui devait être challengée par le business...
Bref il va falloir que je revoies mon argumentaire :D
Merci pour ton avis éclairé :)
J'ajoute ma réponse à la question - Accepter les paiements e cartes bancaires.
Je suis tellement dans le logiciel B2B avec paiement à 30 jours que je n'y avais pas pensé. J'utilise Wise comme compte de banque en ligne - 50€ à l'année et il suffit d'un clic pour activer l'option paiement en carte.
Merci ! Bon à savoir .
@Mathieu Baudonnat Ok je vois, mais là on parle d'opportunité business non ?
Du coup pour moi cette étape est généralement plus orienté sur des données de marchés et la stratégie de la boîte. Notre partie aide à définir le besoin et les problèmes terrains en mappant les besoins trop servis ou trop peu servis - ca peut guider la réflexion du côté business pour monter le cas.
Mais à partir de là c'est de l'analyse business pure. Chaque boîte aura son process interne de validation (ou pas.)
Après je suspecte que vous réfléchissez comme ça car vous mappez les opportunités en arbre de Teresa Torres, et elle est très vague sur ce point.
J'irais regarder dans la littérature d'experimentation et map d'hypothèses, pre-totyping, fake door test etc... Je crois que l'auteur du BN canvas à fait un bouquin dessus aussi.
Plus que des données de marchés, l'idée c'est de challenger et tester en réel, mais c'est aussi compliqué avec nombres de cultures de boîtes.
@Alexis Gérôme
Oui j'avais vu ce post et la critique qu'on avait formalisé dessus était la même que pour le RICE. Ces frameworks sont utiles pour évaluer des solutions et non des opportunités.
Telles qu'on les défini, les opportunités sont des insights actionnables pour lesquels aucune solution n'est encore trouvée. De ce fait il est compliqué d'évaluer l'effort.
Après, peut être que c'est un problème insolvable...
Salut Mathieu, est-ce que tu as vu passer cet article que Amandine a partagé récemment ? https://itamargilad.com/the-tool-that-will-help-you-choose-better-product-ideas/
Ca détaille le framework ICE, et sur quelles bases tu ranks tes critères. Est-ce que vous avez cette base de ranking établie entre vous ?
Ca sert de base, mais au fond le ranking peut être personnalisé suivant votre fonctionnement interne.
Autre chose, est-ce que vous suivez le ranking ?
La scorecard doit être suivie pour être efficace sinon ça reste du doigt mouillé. J'ai souvent vu beaucoup d'effort être déployé pour commencer à avoir un process mais lors de l'action, le PM ne le suis pas.
Sinon, pour départager certaines features entre elles réaliser une étude Maxdiff peut être intéressante pour comparer - ca demande du quanti mais c'est quelque chose qui peut aider et qui est pas trop lourd si tu travailles sur ta base de données.
@Equipe Wikihero j'ai un peu de mal à m'y retrouver avec le système de commentaires, visuellement principalement (espacements / séparation entre commentaires, commentaires pas toujours tous affichés et lien pour afficher les autres commentaires assez dur à trouver) mais aussi à cause des ancres qui ont tendance à partir un peu n'importe où lorsqu'on clique.
@Thierry Raguin Ah bon ? Qu'est-ce qui cloche ? C'est le but au final :)
Je me suis permis de répondre dans un post dédié car les commentaires ne sont pas super pratiques pour échanger ensuite.
Commentaires additionnels de Jakob Nielsen sur cette publication de Baymard : https://jakobnielsenphd.substack.com/p/ai-ux-evaluation
@Equipe Wikihero Merci à vous d'avois pris le temps de m'expliquer les termes en usage en France. Comme je suis travailleuse indépendante (freelance), je travaille à mon propre compte. Alors, mon profil est peut-être mal configuré!
@Nat Ouellet Hello Nat, bienvenue sur Wikihero :)
Merci de ton retour, c'est une liberté volontaire. la notion de lead est ce qui est utilisé sur le terrain. L'autre option c'est manager, et cela amène d'autres problèmes (Quel niveau hiérarchique etc..)
Pour confirmé c'est un terme utilisé en France - c'est entre le junior et le senior et je ne lui connais pas d'autres équivalents pertinent.
Preneur d'améliorations si jamais :)
Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, jobs etc sur la recherche utilisateur!
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur le product design.
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur l'accessibilité numérique.
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur l'utilisation des sciences cognitives dans le monde produit.
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur l'éthique dans le monde produit.
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur la green UX qui comprend l'éco-conception et la sobriété numérique.
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur l'UX writing.
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur la vie de freelancer.
Groupe pour partager les offres d'emplois, et de missions freelance en France ou ailleurs ainsi que de discuter de nos choix de carrières. Postage libre aux professionnels UX. Pas de recruteurs/RH.
Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, et retours d'expériences sur la facilitation d'ateliers, de réunions.
Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, jobs et plus encore sur le sujet de la stratégie UX.
Un groupe pour fédérer tous ceux qui enseignent l'UX afin de partager vos questions ressources et astuces.
Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, jobs et plus encore sur le sujet du management d'équipes UX.