
Est-ce que vous avez des manières d'accélérer le closing ou de signifier "diplomatiquement" que l'offre expire ? Merci!
- Même problème
- Déjà posée plusieurs fois
- Pas sûr
Là où j’ai besoin d’aide et où je serais vraiment curieuse d'échanger et avoir des retours d’expériences et de tips, c’est comment l’UX s’intègre dans les organisations d'entreprises ? Parce que là, chez mon client, on est en train de développer la research, le product discovery et on se questionne beaucoup sur comment optimiser la chaîne de valeur de la discovery au delivery dans le contexte de cette grande entreprise. On ne peut pas se sortir de cette vision de parcours global parce que c'est le propre de l'expérience utilisateur. Mais par contre, on développe en agile par petits bouts. Je serais vraiment curieuse de savoir comment les autres entreprises équivalentes font pour intégrer le Design dans des organisations plus traditionnelles et anciennes, ayant déjà un socle technique et un historique long de plusieurs dizaines d’années.
@Marine Wolffhugel canon ! Merci Marine
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.
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.
@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/
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é.
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.
@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:
@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.
@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.
Hello Alexis, en effet je me rends compte que je n'utilise pas encore trop les hashtags pour chercher des sujets, c'est un réflexe qui va sûrement avoir de plus en plus de sens.
Puis je pensais que ça pourrait être intéressant de se positionner sur ce sujet, que ce soit par une section ou par hashtag. C'est peut-être encore tôt, mais il n'y manque pas d'intérêt sur le sujet.
Fais comme tu le sens et oui pourquoi pas pour une vote !
C'est quelque chose en cours sur les autres slacks , et j'ai pondéré cette question mais pour l'instant j'utilise les # dans les groupes en question. #ia, #intelligenceartificielle #chatgpt par ex..
De ma lecture l'IA est comme figma. C'est un outil qui va changer la pratique, mais qui va être intégré à tout ce que l'on fait. Donc un hashtag reste plus pertinent.
Comme Wikihero est segmenté par groupes, cela fait que tu retrouves toujours les posts x comments liés à ce thème au travers des hashtags.
je pense que ce genre de groupe sera intéressant à partir du moment où il y a quelque chose de plus avancé.
On peut peut-être mettre ça en vote cette semaine ?
Moi personnellement, le travail en remote m'a beaucoup aidé pour ça : j'arrive à mieux me concentrer et dès que l'on ferme son ordinateur, il y a le temps de faire autre chose. Maintenant que le travail retourne au bureau, beaucoup d'entreprises gardent le travail hybride.
Puis se lever avant le boulot pour faire du sport ou juste une petite balade peut faire un bien fou !
On m'a déjà demandé un tarif/heure et j'ai simplement splitté mon TJM par 8 heures, mais le projet ne s'est jamais concrétisé. Je me demande s'il faut pas ajouter un petit supplément, vu qu'il s'agirait de projets de courte durée avec quand même toujours un minimum d'onboarding à faire..
@Mathieu Baudonnat j adore !!!❤️
@Alexis Gérôme j adore merci !!! Je realise que dans les entreprises très silotées le sujet d alignement des stakeholders et de partage de connaissances est complexe.
Et je vais me manger cette remarque tant que je n arriverai pas à avoir l ensemble des interlocuteurs clés en cadrage... je ferai un post mortem là dessus😉
Hello Amandine, je pense que ça dépend de ton moment de carrière et de l'ambition que tu as derrière.
Je ferais un split entre ce qui est maitrisable et ce qui n'est pas maitrisable.
Ce qui n'est pas maitrisable et dépend de l'organisation:
Ce qui est maîtrisable:
Je verrais les ressources que je peux collecter pour cela :)
@Julie Po Merci ! En quoi le process actuel à ses limites ? (de ton point de vue) - Est-ce qu'il ya un focus sur les résultats des features vs l'output ?
Par expérience, ce genre de situation évolue par le haut. Si l'ownership est partagé, qu'il n'y a pas de responsabilité claires sur la recherche et une approche commune, ce n'est pas toi IC (individual contributor) qui va réussir à faire changer les choses.
---
Il faut commencer ce chemin par être raisonnable sur les attentes. Tu es product designer, toi et les PM faîtes probablement de la research, et il y a le côté Ops à gérer ensuite.
On parle de plusieurs casquettes là - donc s'attendre à tout faire tout en gérant tes activités actuelles est une voie sûre vers le burn-out. C'est mon premier conseil. Trop de personnes commencent avec un enthousiasme débordant pour structurer la recherche pour se brûler les ailes car il n'y a aucun support interne. Les supérieurs sont partants à l'idée, mais ne savent pas quoi faire et ne sont pas prêts à ce que tu lâches tes activités du moment pour te concentrer dessus.
A partir de là, cet alignement permettra d'identifier les gaps actuels et proposer des pistes d'améliorations en termes de process à commencer gentiment.
Généralement tu commences petit - par une équipe , une partie du produit comme pilote afi
Ca veut dire distribuer des responsabilités, suivre l'avancement, le mettre dans els objectifs trimestriels, reporting - être capable de faire évoluer le pratique etc..
J'espère que ça aide :)
Hello, en freelance, tu as toute la partie business évidement, mais je ciblerai présentation/ soutenance de projet, tout ce qui est relatif au cadrage et au program management, tout ce qui peut servir à construire des kpi/okr pour démontrer tout au long du projet, et tout ce qui aide a documenter, faire savoir... en fait tout ce qui donnera au researcher des moyens de s'intégrer au niveau stratégique et pas au niveau delivery... tout ce qui relève des compétences de PO ou de Business Analyst... ce genre de "chefferie de projet" qui ne sont que des intermédiaires et souvent des freins pour les designers :P
c'est macro, mais c'est vraiment les points clefs sur lesquels les designers, toutes spécialités confondues et freelance ou non, sont en deficit cruel face à leurs interlocuteurs, de n'importe quels métiers, avec lesquels nous collaborons.
Pour les ressources, regarde ce qui se fait en ops, les outils et méthodes que nous utilisons, c'est tres product/service comme approche, bien évidement la partie research c'est des choses que tu connais déjà forcément pour partie, et pour la partie business/market de la chose, ya plein de sites qui explique comment on construit des KPI et comment on rentre dans un processus de mesures d'impact et d'efficacité. va voir ce que Patrizia Bertini ou Farid Sabitov partagent sur linkedin par exemple , ca te donnera une orientation et surtout des idées d'outils et méthodes à répliquer :)
Ça dépend de que tu entends par compétence en dehors de la research.
Par exemple, je considère que l'écoute ou l'empathie sont des compétences de researcher.
Mais je dirai à chaud:
1) La communication : avoir des insights, c'est bien. Savoir les transmettre, c'est mieux.
Donc ça sous tend :
2) La collaboration : Travailler avec les autres, c'est pratique !
3) Business : On pourrait penser que c'est utile uniquement aux freelances, mais que nenni. Comprendre le business, c'est utile pour apporter des insights qui seront utilisés.
4) Analyse critique : Je pensais que ça faisait partie du lot commun des compétences de research, et les faits me démontrent le contraire. Mais l'objectif, c'est de savoir apporter des informations qui vont aider à la prise de décision du client, de la hiérarchie, des parties prenantes.
Ps : C'est mon point de vue en tant que lead UX, et consultant à 80%.
@Alexis Gérôme
Actuellement on en fait sur des problématiques identifiées et pour "dérisquer" des nouvelles features.
Au sujet de la hierarchie, historiquement on a des lead ancien PM qui sont très accès sur le business et la delivery. depuis peu une nouvelle manager plus user centric.
et l'ownership est mélangés et pas clair.
Salut Julie,
Tu peux nous en dire un peu plus sur tes problématiques? Où en es tu? Quelle est l'acceptation de la research dans ton entreprise?
Hello Julie merci de ta question. Afin que moi ou d'autres puissent te répondre, tu pourrais nous partager quelques informations sur ta situation actuelle.
Merci :)
Comme Mathieu, mais je dirais que ça dépend pourquoi ils te demandent cela.
Je vais te faire une réponse bateau mais perso je fais TJM divisé par 7.
Après la question plus importante derrière c'est comment tu vas faire pour chiffrer ton taf à l'heure et quels comptes ils vont te demander lors de la facturation
@Alexis Gérô Merci Alexis, tu as donné plein de pistes à explorer ! Il y a en effet plusieurs manières à aborder les choses :)
Hello Julia, c'est une très bonne question, et un sujet pas facile à cerner alors qu'il n'y pas beaucoup d'exemples disponibles.
Lors de notre dernier groupe d'entraide on en a parlé et j'ai aidé Sophie à justement traduire certaines parties de son CV de cette manière. Tu peux trouver l'article ici.
Et voici la partie principale avant/après.
De mon côté j'essaye de traduire l'impact de ma recherche en une donnée qui représente quelque chose pour le lecteur de ton portfolio. (Généralement gain ou éviter des pertes)
Ce sont les deux choses que les entreprises font attention, et tu peux l'estimer avec la taille de la user base ou du volume d'affaire.
Par exemple pour une recherche pour le lancement d'un nouveau produit, ma recherche est revenue avec des preuves que la cible de base n'était pas la bonne.
Cela a amené un ré-alignement interne pour le lancement du produit pour se focaliser sur des personas plus propices à acheter le produit.
L'impact final?
Sachant que c'était un lancement global, et l'entreprise avait des millions de clients je peux juste dire que j'ai sauvé des millions de $ à l'entreprise en se focalisant sur les bonnes cibles au lieu de jeter son argent par les fenêtres.
-- Pour un design lorsque tu n'as pas accès aux données "lives" du business essaye de te concentrer sur des données de tests ,par exemple.
-- Pour finir si tu n'as pas de données de tests alors essaye de mélanger la notion de temps + criticité de ton intervention et donnée de marché de l'entreprise ( CA x Volume achats etc..)
Bonjour!
C'est vrai que souvent il est difficile de trouver un échantillon de 200-300 personnes, mais c'est un chiffre très élevé qui n'est pas forcément nécessaire si on travaille sur un sujet assez précis.
Il est possible de regarder ce qui se fait dans d'autres études et dans la littérature afin de voir combien de participants ont été mobilisés pour quelle taille d'effet. Si ces données ne sont pas disponibles on peut faire un calcul de puissance de test.
Ce test met en évidence le nombre de participants requis pour atteindre une taille d'effet minimum. Ce lien explique bien la logique: http://www.txrating.org/spc/polycop/Puissance%20et%20NSN.htm
Le calcul de la puissance peut aussi être fait en considérant des comparaisons de groupe.
Il y a des outils pour calculer la puissance qui sont disponibles directement sur SPSS il me semble, ou R :)
Bonjour,
j'ai eu le même dilemme dans une entreprise du secteur de la FinTech, pour un produit niche, avec un accès super limité aux target group. Dans mon cas, j'ai souvent réduit l'échantillon à 30 personnes, par force des choses, mais j'ai bien établi les conditions de l'étude dans mon rapport et fait mention des réserves liées au nombre de participants limité.
Mon répondre à tes questions,
Sample size: Je suis d'abord toujours partie d'une sample size idéale, pour chercher à m'en rapprocher le plus possible. J'ai ensuite pris en compte les futures études à mener - en fonction du panel cécessaire, j'ai ajusté ma sample size et les "caveats" à prendre en compte dans mon rapport.
Qualité: ici, je joue énormément sur la triangulation. Si tu n'obtient pas la qualité souhaitée avec ton étude quanti, tu peux t'appuyer sur d'autres études, issue du qual, de la recherche de marché, de la voice of the customer, des analytics.... bref croise tes études et insights pour converger vers une plus grande sécurité. C'est du moins ainsi que j'ai du procéder, lorsque mon segment était trop limité.
Bonjour, c’est une problématique à laquelle je suis confronté tous les jours et je ne suis bien loin d’avoir fait le tour du sujet.
Il s’agit d’un sujet réellement important qui a un fort impact sur notre quotidien.
Selon moi, il est important de dissocier :
Même si les problématiques sont liées et que chacune ne peut se jauger qu’au regard des autres, chacune pourrait être adressée individuellement.
Maturité des équipes UX :
En terme de management d’équipe, Il me parait essentiel de porter une vision claire et une certaine exigence en terme de posture et de méthodologie des designers.
Tout commence par l’exemple et ce que nos équipes renvoient de leur travail.
Il est très important selon moi d’arriver à « Industrialiser » les méthodes de chacun et les livrables produits.
Bien sur, nous avons tous notre propre sensibilité et ne sommes pas des robots.
Cependant il est essentiel que ce qui est produit par l’un soit cohérent avec ce qu’aurait pu produire l’autre.
Il en va de notre crédibilité professionnelle.
Maturité des équipes autour desquelles nous gravitons (techniques, métiers…) :
On aura beau faire des présentations expliquant pourquoi « le design c’est chouette », ce n’est pas ainsi que nous ferons avancer les choses.
Il est surtout nécessaire de prouver à chacun qu’un travail de design permet d’éviter des coûts, de l’incompréhension et du retard dans les développements.
Ces preuves ne pourront être apportées qu’à travers la mise en place de métrique permettant la mesure de succès d’un projet.
Maturité de la direction :
Selon moi, l’enjeu est ici de prouver notre ROI.
J’aime présenter des chiffres sur 2 projets similaires :
Ce ne sont que quelques réflexions basées sur mon quotidien.
Je serais ravi de pouvoir confronter mon point de vue avec d’autres personnes qui tentent de trouver des réponses sur cette problématique..
Très bonne question, c'est délicat car c'est du cas par cas et dépend des objectifs de ton étude, de la décision à prendre et des risques impliqués derrière.
Ma première règle des tests quanti est de ne pas en faire lorsque les conditions ne sont pas réunies car au final cela fait plus de mal que de bien.
Tu mentionnes que tu es dans l'entreprise et industriel - on parle une entreprise de type hardware multinationale ?
Le besoin de ton échantillon est aussi basé sur le type d'organisation dans lequel tu évolues.
Généralement plus grosse boîte = plus gros investissement = plus gros risques = stakeholders plus stressés = Demande de fiabilité d'un quanti plus haute. Donc besoin d'avoir des échantillons plus significatifs car c'est généralement là où tu vas être challengé dessus, ou si ça semble faible ton étude perds en "crédibilité".
Donc ça nous amène au type de décision que tu dois prendre.
Imaginons que tu sois dans du B2B industriel avec très peu de chances d'avoir plus de 100 participants par groupes.
Dans un quanti "simple" je dirais le plus bas où tu peux descendre c'est 50 participants par groupes qui ont complétés l'étude. Ce n'est pas idéal mais cela peux suffire pour infirmer x confirmer certaines intuitions de l'équipe produit ou d'insights en recherche quali (sur l'usage etc..)
Pour la qualité - tellement de choses à dire mais les principales:
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 la vie de freelancer.
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 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'éthique dans le monde produit.
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'accessibilité numérique.
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur le product design.
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.
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, 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.