chargement des résultats

Postes

  • ·
  • ·

Commentaires

  • ·
  • ·
  • Prioriser des opportunités

    @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.

  • Prioriser des opportunités

    @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 :)

  • Prioriser des opportunités

    @Mathieu Baudonnat, voilà ce que j'ai l'habitude de faire dans ce genre de situation :

    1. Evaluer auprès des utilisateurs la valeur utilisateur (VU) des insights (de 0 à 5). Si les utilisateurs ne sont pas dispo ou difficilement, ça peut être le travail des researchers qui ont sorti ces insights d'évaluer la valeur utilisateur. Si il y a plusieurs utilisateurs / researchers par insight, c'est bien qu'elles évaluent individuellement pour ensuite confronter les évaluations, idéalement avec elles, et faire une moyenne à la fin ou convenir ensemble d'une valeur finale.
    2. Evaluer auprès des stakeholders la valeur business (VB) de ces insights (de 0 à 5) : est-ce que l'insight va dans le sens de la stratégie produit / de l'entreprise ? y a-t-il un ROI envisagé ? à quelle échéance ? quel est le time to value ? etc. Potentiellement ça fait intervenir différents stakeholders pour différents insights et si il y a plusieurs personnes pour un même insight, c'est bien qu'elles évaluent individuellement pour ensuite confronter les évaluations, idéalement avec elles, et faire une moyenne à la fin ou convenir ensemble d'une valeur finale.
    3. Déterminer des poids pour la valeur utilisateur et la valeur business (par défaut 50% / 50%) et calculer la valeur de chaque insight V = VU*PU + VB*PB
    4. Evaluer la faisabilité technique et organisationnelle (F) de ces insights (de 0 à 5) auprès de différents stakeholders. C'est évident le plus tricky puisqu'on n'a pas de solution précise comme tu le dis mais on a en général une idée de la complexité qu'il pourrait y avoir derrière, est-ce que les équipes techniques ont les compétences / la capacité à implémenter une solution potentielle ? est-ce qu'il faut faire appel à des tiers ? est-ce qu'il faut investir dans une solution ? est-ce que la solution potentielle serait rapide à mettre en place ? quelle est la maturité de la technologie nécessaire / du marché / de l'entreprise ? etc. 
    5. On se retrouve alors avec une valeur V (qui représente la synthèse de la valeur utilisateur et de la valeur business) et une faisabilité technique et organisationnelle F, les deux compris entre 0 et 5. Il ne reste alors plus qu'à les placer sur une matrice à 4 cadrans :
    6. V > 3 et F > 3 : GO GO GO ! Sujets à lancer rapidement
    7. V > 3 et F ≤ 3 : Gros sujets qui valent le coup d'être lancés
    8. ≤ 3 et F > 3 : A garder en tête pour plus tard éventuellement
    9. V ≤ 3 et F ≤ 3 : On peut laisser tomber
  • Prioriser des opportunités

    @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..

  • Prioriser des opportunités

    @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é :)

  • Prioriser des opportunités

    @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.)

    • Taille du marché
    • Structure de pricing
    • Forces compétitives et ressources nécessaires pour compete
    • Alignement avec la stratégie à long terme - est-ce que ca renforce le positionnement etc..
    • Réfléchir à une gestion de portfolio (si agrandissement etc..)

    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.

  • Prioriser des opportunités

    @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...

  • Prioriser des opportunités

    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.

  • Guide d'ateliers pour un design universel et inclusif

    Génial merci !

  • Quelle place donner aux "Anecdotal Evidences" en phase UX ?

    Super question Inès. C'est intéressant car au final c'est un des objectifs de Wikihero. Collecter et centraliser nos expériences terrains et te permettre de prioriser lesquelles sont valides et reproduisibles. Au final l'UX est une profession empirique, et dans bien des cas on est loin de pouvoir se reposer sur de la science dure car il y a beaucoup de sciences humaines et les comportements changent.

    Ensuite, comme pour tout, c'est très sain d'être sceptique des résultats. Que cela soit des anecdotes ou même de la littérature scientifique.

    • En psychologie surtout, il y a une crise de la "reproductibilité" ou pas mal d'études ont eu des résultats différents, car la méthode était biaisée à la base.
    • Ensuite, la pop psychologie à fait son business, et des lois comme celle de Miller ont été incomprises et mal interprétées. (en gros c'est plus il y a de choix, plus la charge mentale augmente. Pas de nombre magique)

    Donc je pense qu'il y a trois choses à faire avec ce genre de retours.

    • Essayer de savoir la méthode suivie pour arriver à la conclusion. (Feeling, intuition, des "on-dit", observation terrains avec des utilisateurs)
    • Evaluer si d'autres retours vont dans le même sens, ou au contraire cette anecdote va à l'encontre de la "littérature" existante.
    • Quantifier la notion de risque de cette anecdote pour ton contexte et l'impact que cela aurait si c'était vrai.

    Par exemple l'année dernière avec un client on a un fait un projet d'innovation sur une nouvelle proposition de valeur. J'ai testé avec des clients existants et des nouveaux clients il s'est avéré que les clients existants n'étaient pas du tout intéressés (ce n'était pas la cible, donc tu me diras génial). Par contre ils étaient en colère, et se sentaient trahi par la marque d'évoluer de cette manière.

    L'organisation étant aveugle, ils ont lancé en mai cette feature, et le backlash a été ultra violent. les client ont posté des vidéos d'eux en train de détruire les devices etc.. résultat ? Pause de la feature, retour en arrière, mais marque détruite.

    Pour conclure en cherchant le contexte, la quote de Bezos va un peu à l'encontre de ton point, et amène plus vers le bénéfice du ressenti et de la recherche quali.

    Le contexte dans laquelle elle a été prononcée est apparement sur la customer obsession d'amazon et le fait que Jeff à encore un email où les clients le contact sur des problèmes existants. D'où le fait que ça aille au delà de la data.

  • Quelle place donner aux "Anecdotal Evidences" en phase UX ?

    Super intéressant et je te rejoins là-dessus. Je note les preuves anecdotiques et dans la mesure où elles me semblent intéressantes, je les ajoutent à mon rapport en soulignant leur caractère anecdotique mais justifie leur intérêt (elles peuvent être révélatrices de besoins non explorés, ou venir d'un segment jusqu'ici ignoré,...) et j'encourage l'équipe à vérifier si elles sont repliquées à l'avenir (nous avons un board sur Asana dans lequel nous les sauvegardons et les taggons de sorte à vérifier si elles sont vraiment si "anecdotal"). En soit, elles peuvent faire l'objet d'une analyse rigoureuse dans le futur ou montrer que la data était biaisée. Parfois, elles sont révélatrices de"edge-cases" et sont tout aussi intéressantes à considérer.

Groupes

  • Recherche utilisateur
    Recherche utilisateur

    Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, jobs etc sur la recherche utilisateur!

    31 membres
  • Product design
    Product design

    Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur le product design.

    16 membres
  • Accessibilité
    Accessibilité

    Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur l'accessibilité numérique.

    17 membres
  • Sciences cognitives
    Sciences cognitives

    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.

    20 membres
  • Ethique
    Ethique

    Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur l'éthique dans le monde produit.

    16 membres
  • Green UX
    Green UX

    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.

    18 membres
  • UX writing
    UX writing

    Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur l'UX writing.

    8 membres
  • Freelance
    Freelance

    Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur la vie de freelancer.

    13 membres
  • Wikihero
    Wikihero

    Posez vos questions à l'équipe et suivez directement l'actualité de Wikihero.

    9 membres
  • Emploi&Carrière
    Emploi&Carrière

    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.

    15 membres
  • Facilitation
    Facilitation

    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.

    6 membres
  • Stratégie UX
    Stratégie UX

    Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, jobs et plus encore sur le sujet de la stratégie UX.

    15 membres
  • Enseigner l'UX
    Enseigner l'UX

    Un groupe pour fédérer tous ceux qui enseignent l'UX afin de partager vos questions ressources et astuces.

    11 membres
  • Management UX
    Management UX

    Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, jobs et plus encore sur le sujet du management d'équipes UX.

    13 membres

Hashtags

  • #methode
    Pour parler de sujets qui touchent à des méthodes UX spécifiques.