chargement des résultats
Wikihero Bêta
Inscription Connexion
Inscription Connexion
Trois lettres minimum pour effectuer une recherche
29 résultats
Selection
  • #priorisation 9
EN LIEN AVEC VOTRE SÉLECTION
  • 9
  • 2
  • 2
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1

Postes

  • ·
  • ·
  • merci! Utile
  • Pas utile
  • Pas sûr
  • Un conseil que j'aurais aimé: Ne pas se mettre le stress de faire un truc excellent

    Une erreur pendant les premières années de ma carrière était le stress de faire un truc excellent. Ma première boîte m’a poussé à faire ça, et viser vraiment le top du livrable pour les clients. Je pense que c’est à la fois une bonne école et une très mauvaise habitude.

    C’est une bonne école parce que tu es forcé à en baver, à pousser le niveau, mais ensuite dès que tu arrives à des endroits où il faut produire et que tu ailles assez vite, tu stresses, c’est le syndrome de l’imposteur alors qu’en fait, dès le début, la règle des 80-20, est au fond très importante.

    En vrai, depuis pas si longtemps que ça, 4 ou 5 ans, je me dis : 

  • “Ne mets que 20% de temps sur le truc” au début j’ai eu l’impression que finalement, 20% ce n’est pas grand-chose. 
  • Mais avec ces 20% je ne mets vraiment que l’essentiel.

    Ensuite la finalisation se fait au travers des discussions avec les gens pour remettre un peu d’effort et corriger les choses.

    Mon grand learning c’est qu’il faut être content de ce que l’on fait et ne pas se mettre une pression de dingue. Dès que l’on vise ce dernier quart (en production) ça devient le burnout, la désillusion, et vite un piège.

    • David Jeanne · Senior Lead Designer · il y a 1 an
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment prioriser plusieurs projets en même temps en tant que UX Writer ?

    Chez Getaround et Doctolib, j’ai mis en place un framework de collaboration où l’UX Writer adopte un rôle owner, partner ou consultant. Ce framework a été inspiré par un article de Bronwyn Berkery et j’ai également écrit mon propre article sur ce sujet.

    C’est quelque chose que j'avais fait aussi au sein de Getaround en tant que contributeur individuel parce que j'étais le seul UX writer et du coup, je devais gérer toutes les demandes. 

    Lorsque tu es la seule personne, ce n’est pas possible de suivre tous les projets à la même vitesse et avec la même implication. 

    J’ai trouvé un framework de collaboration de owner/partner/consultant. C’est-à-dire :

  • Est-ce que je vais vraiment prendre le l’ownership de A à Z sur l’UX writing de ce projet ? Dès le début jusqu’à la fin. 
  • Ou est-ce que je vais m’impliquer un peu plus tard en tant que partenaire, mais quand même assez tôt dans la phase define (du double diamond) ? 
  • Est-ce que ça va être plutôt un travail de collaboration entre les product designers et les PM où ils vont mettre leur cerveaux ensemble et je suis là en support en tant que consultant ? 

    Au début, en arrivant chez Doctolib, je me disais ce qui marchait pour moi chez Getaround, en tant qu’une personne qui bossait avec 6 squads différentes et trois product designers, ça ne va pas fonctionner dans une boîte comme Doctolib où on a presque cinquante, peut-être soixante-dix squads. 

    Les gens au sein de mon équipe avaient un peu ce même problème où il y avait trop de projets en même temps, où ils avaient du mal à les différencier et à prioriser quels étaient les projets sur lesquels ils devaient passer plus de temps que les autres. 

    Du coup, je me suis dit que ce framework n’était peut-être pas mal. 

    J’ai parlé avec mon ancienne manager de Getaround qui m’a m’a dit :

    “Franchement, ce framework, ça marchait trop bien. J’ai exactement la même chose avec cette nouvelle user researcher parce que c’est le même genre de situation où on peut avoir énormément de demandes.” 

    Le fait qu’elle me fait ce retour, je me suis dit que c'était peut-être assez solide comme framework. Du coup, j’ai expérimenté jusqu’à quel point ça marche sur une échelle un peu plus grande. (et c’est encore en cours)

    En tant que manager, je joue un peu le rôle de consultant où on a des créneaux dans nos agendas que les membres de l’équipe peuvent réserver pour faire une content critique, pour faire un pair review, et d’autres moments pour présenter le travail en cours. En réalité, je joue un peu le rôle de consultant avec le travail.

    Pour prioriser, entre owner/partner/consultant lorsque j’étais chez Getaround on observait dans un premier temps ce qui était dans la roadmap et je notais les projets selon des critères d’exclusions ou non: 

  • Est-ce que ce sont des problématiques qui sont déjà connues au sein de la boîte ou pas ? 
  • Si on est en train d’aborder de nouveaux problèmes, je pense que je devrais être là
  • Si ce sont des problèmes reconnus, peut-être plus apprises sur des connaissances existantes, je considérais que les product designers et PM devraient être un peu plus à l’aise. Ces deux-là sont assez liés, ils connaissent bien ces utilisateurs ou pas. 
  • Si c’était un nouveau type d’utilisateur, je pense que je devrais être là, Si c’est le type de base qu’on met dès le début et qu’on connaît bien, à ce moment-là, je pense que les product designers et les PM peuvent être un peu plus autonomes. 
  • Du coup, c’est aussi lié sur est-ce que c’est un sujet sensible ou pas ? 
  • Si les risques étaient plutôt élevés, je bascule plutôt vers owner 
  • Si les risques étaient plutôt négligeables, je peux accepter d’avoir un peu moins la main dessus. 

    C’est hyper dur d’accepter de ne pas avoir le contrôle, néanmoins il faut garder en tête que l’on est en train de créer des logiciels.  

    On peut modifier les libellés après si besoin. Si tu es en train d’imprimer des magazines c’est plus dur à rattraper à ce moment-là, donc tu as de la marge de manœuvre (selon le projet).

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Calculer votre Dette UX avec ce template gratuit
    Très bon article sur le sujet qui explique le processus d'une équipe UX pour définir le volume de leur dette UX et comment la prioriser. https://uxpamagazine.org/ux-debt-in-the-enterprise/ Vous trouverez aussi un calculateur de dette UX gratuit: https://uxpamagazine.org/wp-content/uploads/sites/8/2015/02/15-1-Rector-Dunwoody-UXDebt-Calculator-Excel.xlsx
    • merci! Utile
    • Pas utile
    • Pas sûr
  • De l'idée à la validation (ou non) de core features de l'app de dating Haystack
    Une étude de cas pas à pas sur le processus d'évaluation du potentiel d'une app de dating et la détermination de l'existence d'un marché ou non pour l'équipe. https://uxdesign.cc/idea-to-validation-43d0284608cc
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Qu'est-ce que l'on priorise en premier sur l'accessibilité une fois le contraste résolu ?
    Dans mon équipe B2B nous avons résolu les bases (couche visuelle), et maintenant nous aimerions nous attaquer à de plus gros enjeux d'accessibilité, mais je ne sais pas trop comment approcher ce qui me parait une montagne. Avez-vous des astuces ou REX de vos propres projets ?
    • Même problème
    • Déjà posée plusieurs fois
    • Pas sûr

    • Commentaires

    Groupes

    Hashtags

    Groupes