chargement des résultats
Product design
Expérience utilisateur (UX)

Product design

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

A propos
27 Abonnés
Responsables · Postuler
  • Posts Récents
  • Tendances
  • Plus populaire
  • ·
  • ·
  • Livre gratuit sur les design tokens écrit par des professionnels francophones.
    (depuis la page amazon) - Ismaïl Hamila & Adrien Gibrat démêlent avec précision l’écheveau complexe qui lie design et développement à travers le prisme des Design Tokens. Situé à l’intersection du Design d’interface et du développement front-end, ce livre élève les Design Tokens au-delà de simples variables pour en faire le cœur d’une démarche innovante et structurée au sein des Design Systems. Destiné autant aux Design System Leads qu’aux Product Designers, Développeurs Front-end, et Managers, cet ouvrage met en lumière comment les Design Tokens servent de vecteur pour l’intégration d’une vision et démarche Design Ops dans les entreprises. PDF gratuit : https://drive.google.com/file/d/1yjxxlejcZ3UAeZ3jycBEQHFvlXvnQhBn/view?usp=sharing Lien amazon pour l'achat:https://www.amazon.fr/Design-Tokens-Book-pratique-d%C3%A9veloppement/dp/2959313003/ 
    Evaluez le livre: https://forms.office.com/pages/responsepage.aspx?id=JoHvioE2zEy78FbwHeCBuRyUT6bbH7xEiFB0jtIhwzpUQkU4NjFDQk9SRVgwV05TNFhLNzg3TDlWVi4u
    • merci! Utile
    • Pas utile
    • Pas sûr
  • AI + Design Language Systems
    L'equipe de Coinbase a entraine une IA sur leur design system qui genere du code et des nouveaux design en meme temps. https://twitter.com/brian_armstrong/status/1779946210226577913?t=9kBtQIMOP6m7MSBoFhmz4A&s=31 Merci Maxime frere
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Idee du jour le Hype Doc - Journal de projet.
    Idée tres sympa deja parle par Marie-Anne sur le fait de documenter ses projets - ici c'est le fait de créer un journal de ses projets afin de pouvoir revenir dessus. Ce document, généralement tenu de manière informelle, est un lieu où l'on note nos réussites, nos idées dont on est fier, nos succès et même les défis rencontrés dans notre parcours professionnel. Contrairement à un portfolio, son but n'est pas de servir à la communication externe, mais plutôt de nous rappeler le chemin parcouru et les obstacles surmontés. C'est une manière simple mais efficace de cultiver la confiance en soi et de se remémorer nos accomplissements. wikihero-image-id: 1286 Vu sur linkedin via Robin Marzin
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Calculateur de taille de composants selon le contexte d'utilisation. (Mobile - Pupitre - Desktop)
    Belle idée de l'agence Use.design qui à créé un simulateur sur la taille optimale des champs, lignes de tableaux et des boutons selon la distance d'utilisation et la taille de l'écran. https://www.use.design/calculateur-taille-composant-design-ui wikihero-image-id: 1283
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Le design n'est pas juste de la résolution de problèmes
    Comprendre pourquoi il est important de dépasser la notion de design comme résolution de problèmes peut influencer la manière dont vous abordez les projets de design, la façon dont vous collaborez avec les autres, et même comment vous enseignez le design aux générations futures. Cet article propose une vision rafraîchissante et provocante sur la nature du design, remettant en question l'idée largement acceptée que le design se résume principalement à la résolution de problèmes. En explorant cette perspective, vous pourriez découvrir des dimensions du design qui dépassent les cadres traditionnels, enrichissant ainsi votre compréhension de ce que signifie être un designer aujourd'hui. https://www.dubberly.com/articles/why-we-should-stop-describing-design-as-problem-solving.html
    • merci! Utile
    • Pas utile
    • Pas sûr
  • 100 astuces sur Figma
    Figma community file avec plus de 100 astuces partagées. https://www.figma.com/community/file/1161621065197114331
    Plus bonus du post: Checklist de composants Figma, par Javier Cuello : https://lnkd.in/eNfcj6JQ Conseils Figma pour travailler plus efficacement, par Allie Paschal - https://lnkd.in/eBPbEEeW Ressources utiles pour le prototypage Figma à ajouter aux favoris, par Ana Boyer - https://lnkd.in/evQYTiXa Les seuls plugins Figma que j'utilise réellement, par 🟦 🟠 🔺Christine Vallaure - https://lnkd.in/eaUQXKJu Comment créer des tableaux de données dans Figma (+ fichier Figma), par Jordan Hughes - https://lnkd.in/eAVuzbfw Un guide pour la migration vers Figma, par Clara Ujiie - https://lnkd.in/eghzWeDC Comment optimiser votre système de design avec les variables de Figma, par Nana Chon 🧙🏻‍♀️- https://lnkd.in/euAAmNkZ  Conseils et astuces avancés pour Figma 2024, par 🟦 🟠 🔺Christine Vallaure - https://lnkd.in/eiCN7KPN
    Vu via Vitaly Friedman sur Linkedin
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Un superbe outil pour vos palettes de couleurs
    Pourquoi cet outil se distingue-t-il ? La réponse tient en sa conception unique. Radix Colors n'est pas un outil de coloration ordinaire, mais une solution méticuleusement élaborée pour répondre aux exigences spécifiques des éléments d'une interface utilisateur. Contrairement à d'autres outils de coloration qui se limitent à assombrir ou éclaircir une teinte en la mélangeant avec du noir ou du blanc, Radix Colors introduit une approche innovante. Il offre une palette de couleurs organisée de manière à attribuer à chaque nuance une fonction précise : une couleur est dédiée aux bordures, une autre au fond, une troisième aux textes principaux, et ainsi de suite. Cette méthodologie permet une personnalisation et une cohérence visuelle inégalées, facilitant la création d'interfaces utilisateur à la fois esthétiques et fonctionnelles. Outil https://www.radix-ui.com/colors wikihero-image-id: 1280 Merci à Julien Perrière pour le partage.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Etude sur l'état de l'architecture d'information
    Etude réalisée par l'association américaine d'architecture d'information auprès de ~900-1000 professionnels. Les grandes lignes Une variété d’outils et de méthodes ont été développés. Les progrès technologiques ont fait progresser l’architecture de l’information, ouvrant ainsi davantage d’opportunités. Les praticiens expérimentés ou ceux occupant des niveaux supérieurs dans le domaine ont tendance à consacrer plus de temps à l'architecture de l'information. Il est nécessaire de sensibiliser et d’éduquer continuellement les acteurs du domaine et ceux qui ne le sont pas. Cependant, existe-t-il un consensus ou des divergences parmi les praticiens sur la question de savoir s’il est de leur responsabilité de défendre la valeur de l’AI ? Pour ceux qui le défendent, quels défis se posent pour transmettre l’importance de l’AI ? Comment les communautés peuvent-elles contribuer à ce parcours pour les praticiens qui défendent l’AI dans le processus de conception ? Alors que la majorité exprime son optimisme quant à l’avenir de l’AI, il existe un segment de personnes interrogées qui ont un avis contrasté. Cette divergence d'opinions indique la présence de perspectives variées au sein de la communauté de l'AI, soulignant la nécessité de discussions et d'efforts continus pour répondre aux préoccupations et aux défis dans ce domaine. Article https://medium.com/worldiaday/2023-state-of-information-architecture-d3b289b86d95
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Le designer derrière Cron (racheté par Notion) explique son process de Sketching et de détails.
    Superbe vidéo sur le sketching par un designer incroyablement talentueux, sur le niveau de détails imaginé et travaillé. Masterclass: https://www.youtube.com/watch?v=2MrNSjJFBBI
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Un UX Designer doit-il maîtriser l'UI ?
    Éternel débat mais c'est un sujet qui me préoccupe en ce moment étant alerte aux opportunités qui pourraient se présenter à moi. Je regarde les offres d'emploi et 80% d'entres elles concernent des UX-UI designers et en tant que free j'ai déjà perdu des missions ne maitrisant pas les 2 aspects... L'UX je maitrise, désormais j'en suis fière, ça fait plus de 8 ans, je gère, je suis sénior. J'ai toujours travaillé avec des UI, d'excellents UI je dirais même. C'est un métier qui m'intéresse, que je trouve passionnant mais que je ne sais pas faire. Je ne sais pas définir une charte, je ne sais pas faire de kit UI encore moins de design system, je ne sais pas faire de maquettes haute fidélité que je peux confier à un développeur sans problème.  Ce que j'aime c'est travailler à deux cerveaux sur la partie UX UI, mais je me rends compte que ce n'est pas en accord avec les postes qui sont proposés... Et vous ? Que maitrisez-vous ? Vous considérez vous expert en UX et en UI ? Vous êtes vous formé sur le tard à l'UI ? Acceptez-vous de faire de l'UI "moyen" ?
    • Même problème
    • Déjà posée plusieurs fois
    • Pas sûr
  • Mes REXS de refonte E-commerce.
    La refonte, c'est un processus que nous abordons de temps en temps, bien que dans le passé, nous nous y sommes plus souvent consacrés.  L'une des choses essentielles à comprendre en premier lieu est la raison pour laquelle nous entreprenons une refonte.  J'ai observé avec le temps que dans la plupart des cas, les refontes sont déclenchées par un changement de la plateforme technique.  Cela signifie qu'une mise à jour technique entraîne souvent des modifications au niveau du design et d'autres aspects. Personnellement, j e trouve que ce n'est pas une raison suffisamment solide pour lancer une refonte complète. Lorsque nos clients viennent nous voir, ils ont souvent une vision très négative de leur site ou de leur application. Ils expriment des critiques sévères, qualifiant l'existant de médiocre, bourré d'erreurs et difficile à comprendre.  Cette tonalité humoristique peut sembler exagérée, mais elle reflète en partie leurs véritables préoccupations.  En tant que professionnels, notre première étape consiste à examiner de manière approfondie la situation. Notre domaine d'expertise réside dans l'expérience utilisateur. Nous testons leurs sites et applications pour identifier ce qui fonctionne et ce qui ne fonctionne pas réellement,mais d’un point de vue UX,bien sûr.  Il s'avère souvent que certaines choses qui semblaient dysfonctionnelles fonctionnent plutôt bien. D'autre part, il y a des éléments précieux qu'il ne faut pas jeter.  Par conséquent, il est essentiel d'aborder un projet de refonte avec prudence, en évitant une vision trop négative ou trop positive. Un autre problème fréquemment rencontré est l'impulsion de tout révolutionner.  Une refonte implique de tout casser et de tout reconstruire, ce qui est un processus complexe.  Il est donc essentiel de partir avec une compréhension claire de la situation existante, sans préjugés excessifs envers les aspects négatifs ou positifs.  J'ai même rencontré des personnes qui pensaient que leur site était parfait, alors qu'il était malheureusement médiocre, et ils refusaient de considérer des changements majeurs.  Cependant, ce genre d'attitude est de moins en moins courante. Dans les cas de sites web ou d'applications à fort trafic, il est impératif d'être prudent lors de la mise en œuvre de changements majeurs.  La modernisation de la charte graphique ou des éléments d'ergonomie peut présenter des risques, même lorsqu'elle est accompagnée par une agence expérimentée et des experts en expérience utilisateur.  Les réactions des utilisateurs sont imprévisibles, comme l'ont montré des exemples passés, notamment le cas de Snapchat ( https://www.marianne.net/economie/le-probleme-de-snapchat-derriere-kylie-jenner). En conséquence, il est essentiel de procéder de manière progressive, en testant et en communiquant clairement les changements apportés. Le comportement des utilisateurs a également évolué, avec une impatience croissante et une plus grande volatilité, notamment en raison de la pandémie de COVID-19.  Les utilisateurs sont de moins en moins tolérants envers les changements, et les marques doivent en être conscientes.  Pour éviter de se heurter à la résistance des utilisateurs, il est essentiel de procéder par étapes et de bien communiquer sur les modifications apportées.  Des exemples comme Airbnb montrent comment une approche progressive et pédagogique peut atténuer les effets négatifs des changements(avec un patron, ancien designer, qui prend souvent lui même la parole pour expliquer ces changements : https://twitter.com/bchesky/status/1524372742048718848?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1524372742048718848%7Ctwgr%5E37ea663cbed37a1bdb11ccdc1e6aefbaf32ca613%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwexperience.fr%2Fblog%2Fanalyse-ux-de-la-refonte-dairbnb%2F . (avec un bon PMM) En fin de compte, il est préférable de prendre des précautions pour éviter de dépenser de l'argent en réalisant des changements qui se révéleront contre-productifs.  La prudence est de mise, quel que soit le niveau de trafic, car le mécontentement des utilisateurs peut rapidement devenir un problème majeur et faire le bonheur de la compétition."
    • merci! Utile
    • Pas utile
    • Pas sûr
  • HTML to Figma. le plug-in qui transforme n'importe quelle page en un figma éditable.
    Petite découverte cette semaine incroyable de ce plug-in qui permet d'importer un site live dans figma. Gratuit mais avec une version pro. wikihero-image-id: 1225 https://www.figma.com/community/plugin/1159123024924461424
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment Spotify travaille sur Figma.
    Un deck qui reprend le process de spotify pour s'organiser sur Figma. Une très bonne source d'inspiration pour communiquer votre propre process. https://www.figma.com/community/file/832911648132248625/spotify-ways-of-working
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Dark Patterns : bientôt illégaux ?
    L'Inde vient de rendre illégal l'utilisation de certains dark patterns en eCommerce. Pour l'instant cela concerne 13 dark patterns. Jakob Nielsen les détaille dans un article de son blog (son article ne parle que de 12 dark patterns car le dernier, Rogue Malware, n'est pas réellement un dark pattern en tant que tel mais plus un acte criminel). Nielsen fournit aussi une petite infographie (avec illustrations Dall-E, sa drogue du moment) utile pour tous les designers : wikihero-image-id: 1216 Il y a évidemment bien plus de dark patterns qui mériteraient d'être interdits mais c'est un bon début et la liste pourra certainement être amendée au fil du temps. Cette loi est intéressante et il serait bien qu'elle dépasse les frontières de l'Inde mais j'ai peur que les lobbies ne laissent pas passer ça malheureusement... Qu'en pensez-vous ?
    • merci! Utile
    • Pas utile
    • Pas sûr
  • De l'inflation des termes utilisés en UX par Jakob Nielsen.
    Quelque chose qui revient souvent sur linkedin ou comme question ici porte au vocabulaire que nous utilisons.  On a eu le débat product design vs UX design Recherche utilisateur vs Discovery. Et bien d'autres débats dans l'industrie arrivé plus tôt IHM vs UX etc... Bref tout ça pour dire que voici un article rafraichissant de Nielsen sur le sujet, pour "endiguer" ou au moins tirer un trait sur le sujet. Cela résonne aussi avec la portée de Wikihero et du projet. En inventant à chaque fois de nouveaux termes, cela empêche la transmission et force chaque groupes à ré-inventer la roue alors que les solutions existent déjà. Un grand malaise de l'industrie où de nombreux vendeurs en profitent. wikihero-image-id: 1210 Pour conclure comme le dit si bien Nielsen: Ce qui compte c'est ce que vous faîtes. Pas le titre que vous portez. https://jakobnielsenphd.substack.com/p/ux-vocabulary-inflation
    • merci! Utile
    • Pas utile
    • Pas sûr
  • AI Pin de Humane : une révolution ?
    Cela fait depuis leur TED Talk de mai 2023 que je suis avec attention le projet AI Pin de Humane, co-créé par Imran Chaudhri (ex-designer chez Apple). La promesse de nouveaux modes d'interaction avec un nouveau device moins intrusif qu'un smartphone ou qu'un casque de VR/MR/AR était assez alléchante... Humane a présenté la première version du produit hier dans une vidéo de 10 min. Et malheureusement, même si la tech est plutôt impressionnante, on peut entrevoir pas mal de problèmes d'usage : Le device a l'air lourd : on voit bien la déformation du t-shirt lorsqu'Imran attache l'AI Pin donc je ne suis pas sûr que ça soit très confortable à porter toute la journée (et quid de la batterie ? elle doit certainement chauffer...) et encore moins en mouvement (ça sent le futur accessoire spécial pour faire du sport). Le système d'attache magnétique est top pour le côté discret et simple à utiliser mais on peut s'attendre à beaucoup de vols et probablement des chutes (dans un métro bondé par exemple) L'affichage par projection fait très futuriste mais ça n'a pas l'air très lisible et les mécanismes d'interaction n'ont pas l'air très pratiques ni efficaces. Même si on devrait être principalement sur des interactions très ponctuelles et courtes, ça n'a pas l'air confortable. Il faut vraiment pouvoir tester pour se rendre compte j'imagine et notamment voir si cela nécessite un apprentissage pour placer sa main au bon endroit ou si le système est super tolérant. Tous les modes d'interactions vocales avec feedback audio, ça rend toujours bien dans les démos mais en situation réelle, c'est tout de suite moins pratique (environnements bruyants, besoins de confidentialité) et il va falloir avoir des oreillettes la plupart du temps. Et pour interagir en vocal, il n'est pas précisé si on pourra chuchoter. Bref gros bémol La démo d'utilisation de l'IA pour améliorer un message à envoyer est assez risible (probablement car l'exemple choisi est trop simpliste) La traduction temps réel est top (même si il y a des apps sur smartphone qui font ça donc rien de révolutionnaire) mais la gestuelle semble un peu lourde. C'est bien sur un échange ultra court comme dans la présentation mais tapoter continuellement sur son device pendant une vraie conversation peut vite devenir lourd. Il aurait aussi été intéressant de voir le comportement sur une discussion entre 2 porteurs d'AI Pin. L'analyse visuelle des aliments présentés pour calculer la quantité de protéines, sucres, graisses, etc. est assez bluffante surtout pour le potentiel que ça pourrait apporter pour des personnes aveugles ou mal-voyantes (reconnaissance d'objets, détection d'obstacles, etc.). Mais il est dur en l'état de savoir à quel point il est facile de viser avec la caméra de l'AI Pin donc il y a un gros risque de frustration en usage réel. Je reste dubitatif également sur la prise de photos et de vidéos : la caméra n'étant pas au niveau des yeux, la promesse d'immortaliser exactement ce que l'on voit me semble fausse. Ils n'ont dit aucun mot sur la présence ou non d'un indicateur sur l'AI Pin pour alerter les personnes filmées qu'elles le sont mais visiblement ils ont bien prévu ça avec leur Trust Light. Et ça nous amène à une problématique présente dans tout système ultra-personnalisé comme ça : la gestion des données et leur sécurisation. Pour que l'AI Pin soit utile, il faut une confiance absolue en Humane et donner accès à un maximum de données personnelles. Et si le produit a l'air assez efficace dans les démos, qu'en sera-t-il avec des données réelles et surtout quel sera son comportement dans le temps quand les données vont commencer à s'accumuler ? Enfin, même si là on n'est plus sur une question d'usage, il y a le prix. Le device reste relativement cher mais surtout il nécessite un abonnement mensuel, donc ça va chiffrer assez vite. Bref, je vais rester sur la réserve et j'ai le sentiment qu'au final Humane est plus sur une fausse piste pour l'avenir du wearable... Et vous, qu'en pensez-vous ?
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Ideo ferme plusieurs de ses bureaux et licencie 1/3 de son staff
    Un signe de l'évolution du marché et de sa mauvaise santé pour tout ce qui est externalisation. Les agences passent toutes une mauvaise année, et ce signal ne risque pas d'améliorer les choses. https://www.fastcompany.com/90976682/design-giant-ideo-cuts-a-third-of-staff-and-closes-offices-as-the-era-of-design-thinking-ends Mais cela est aussi un signal pour construire une autre voie pour le modèle de consulting.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Une erreur de débutant que j'ai commise tôt dans ma carrière.
    À cette époque, j'étais encore relativement novice, avec moins de deux ans d'expérience, et par mon manque de séniorité, je ne suis pas allé secouer le contexte dans lequel je me suis retrouvé. À l'époque, je travaillais chez EDF, alors que le marché de l'énergie s'apprêtait à s'ouvrir à la concurrence. Notre mission était de créer des interfaces pour les auditeurs énergétiques, équipés de leurs ordinateurs portables, prêts à rencontrer nos clients industriels.  Leur rôle ? Simuler la consommation énergétique de l'entreprise, en prenant en compte chaque détail, des compresseurs aux tapis roulants, du chauffage aux réfrigérateurs.  En collectant ces données, nous pouvions proposer des solutions pour réduire les coûts, tandis que nos concurrents se contentaient d'offres standardisées, incapables de personnaliser leurs propositions. Nous nous sommes lancés, une équipe hétéroclite de designers et d'experts en énergie. Nous avons conçu des formulaires, imaginé des interfaces, puis nous sommes passés au stade des essais. Cependant, notre première erreur fut de ne pas placer l'utilisateur au centre de notre réflexion.  Nos experts en énergie, aussi compétents soient-ils, ont façonné un plan qui semblait parfait sur le papier, sans jamais consulter les auditeurs qui devaient utiliser notre solution sur le terrain.  Et...nous n’avons pas testé nos interfaces pour nous assurer de leur validité dans le contexte de l’audit. Notre passion pour le projet a pris le dessus, nous n'avons pas cherché les retours des clients sur leurs besoins spécifiques en matière de simulation.  Nous avons créé une interface esthétiquement séduisante, des icônes élégantes, des fonctionnalités de drag & drop, même des icônes custom élaborées avec soin lors de week-ends entiers.  Mais nous avons omis de nous poser les questions essentielles :  Le drag&drop est-il vraiment pratique ou utiliser le clavier aurait été plus simple ?  La hiérarchie visuelle est-elle adaptée au modèle mental des utilisateurs ? Aujourd'hui, je travaille dans le secteur du e-commerce de la mode.  Se mettre dans la peau d'un acheteur en ligne est plus simple comparé à comprendre les défis d'un auditeur énergétique. Pourtant, cette erreur persiste : négliger l'utilisateur et présumer que nous détenons toutes les réponses. Comment j'éviterai de reproduire cette erreur Avec le recul, j'aurais dû m'asseoir avec ces auditeurs énergétiques, ces pionniers qui redéfinissent leur profession.  Comprendre leur point de vue aurait été inestimable :  Comment percevaient-ils leurs visites clients ?  Quels étaient leurs besoins réels sur le terrain ?  À cette époque, il n'y avait pas de modèle établi. Néanmoins, un simple ordinateur portable ne suffisait peut-être pas.  Peut-être avaient-ils besoin d'autres outils ou de notes à portée de main ? J'aurais cherché à sonder ces experts pour extraire des informations vitales. En outre, j'aurais exploré le côté client. Trouver des entreprises intéressées par notre service aurait pu offrir une perspective précieuse.  Les clients pouvaient avoir une vision différente de ce que les auditeurs souhaitaient réellement. Peut-être préféraient-ils une version simplifiée ?  Ou au contraire, une version plus détaillée ? Peut-être étaient-ils plus intéressés par les rapports que par la visite en elle-même ?  L'objectif aurait été de dialoguer avec les deux parties pour concevoir une expérience répondant aux besoins de tous.
    De nombreuses entreprises qui n'ont pas les designers comme utilisateurs adoptent cette approche. Prenons Doctolib, par exemple. Ils encouragent leurs employés à consulter régulièrement des professionnels de la santé et à partager leurs expériences pour améliorer leurs services.  C'est, selon moi, la clé : rechercher activement des informations, se glisser dans la peau de l'utilisateur pour concevoir des solutions qui répondent véritablement à leurs besoins.
    Une autre dimension de cette erreur est la tentation de complexifier les choses. Nous avons tendance à pousser les limites de la complexité pour créer des solutions plus attrayantes, plus élégantes, supposant qu'elles fonctionneront mieux, sans garantie. C'est une erreur que je répète fréquemment, mais c'est aussi une erreur que je m'efforce de commettre sciemment.  Je sais que je tends à suivre les modèles établis avec mes équipes, mais chaque fois qu'une situation nouvelle ou inhabituelle se présente, je m'interroge sur une approche différente, une solution alternative. Dans mes débuts en tant que designer, dans le tumulte des années 2000, j'ai eu la chance de travailler sur des projets innovants, où nous créions à l’époque de nouveaux patterns.  Aujourd'hui, créer une application repose souvent sur des briques existantes. Pourtant, je continue de me demander : n'y a-t-il pas une voie non tracée ?  C'est un exercice risqué, source d'erreurs potentielles, car il peut nous conduire à ajouter des options complexes, exotiques, exigeant temps et réflexion, sans garantie de succès. Pourtant, je m'autorise souvent à prendre des patterns apparemment inapplicables et à les adapter à notre contexte.  Parfois, cela fonctionne de manière surprenante, ajoutant une touche d'originalité à l'ensemble.  Mais nous les testons systématiquement et ces solutions moins conventionnelles se distinguent parfois lors des tests, surpassant les schémas plus classiques.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Un article incroyable sur ce que la justification à outrance de notre valeur à comme impact.
    Cela faisait longtemps que je n'avais pas lu un article comme cela. Il vaut le détour et fait du bien dans cet océan d'auto-flagellation que l'on lit ces derniers temps sur notre profession. Et si on arrêtait de justifier notre valeur pour une fois ? Que se passerait-il si nous nous comportions comme étant important pour le business à ce moment ? (Au lieu de vouloir tout faire ?)  https://medium.com/nice-work-from-active-voice/hey-designers-theyre-gaslighting-you-e02e5a4d9cff Pour info, cela fait echo à deux REX hyper importants que Manue Marevery et Alexa Gueguen on partagées. Car cette justification à outrance crée des conséquences négatives. Cela habitue les équipes à une baisse du standard. On essaye de faire tenir la baraque tout seul alors que l'on devrait pousser à l'embauche de collègues.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Loom (petit outil / gros potentiel)
    Loom peut servir de moyen efficace pour communiquer visuellement, présenter des designs, obtenir des feedbacks et collaborer de manière plus efficace en tant que designer. : https://www.loom.com/
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Relume, l'outil IA pour vos wireframes
    https://www.youtube.com/watch?v=BTpx1bCkrUk&ab_channel=Digidop%7CAgenceWebflowFrance Comme tous les outils d'IA, l'efficacité de "Relume" dépend de la manière dont on l'utilise et à qui on le destine. Cependant, c'est assez bluffant de voir un wireframe s'exécuter aussi rapidement, qui peut être véritable gain de temps et une base d'inspiration.  Pour en savoir plus : https://www.relume.io/
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Curation de 1000+ sites pour vous inspirer
    Organisé par industrie et support (web apps, desktop, desktop app) https://www.curated.design/
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Livre gratuit sur l'architecture d'information: " A practical guide on Information architecture"
    Un livre gratuit de bonne qualité c'est assez rare pour être souligné! Je l'ai vu passer dans mon feed donc je repartage la bonne trouvaille! C'est écris par Donna spencer, experte dans le milieu. https://maadmob.com.au/wp-content/uploads/2021/03/PracticalGuideToInformationArchitecture.pdf Cela sera disponible gratuitement pour un temps donc n'attendez pas trop :)
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment les UX passionnés arrivent à garder un équilibre familial, social et mental ?
    Car garder un équilibre est difficile quand on est passionné. Je fais beaucoup de choses et ça s’additionne vite. J’ai vraiment du mal à avoir du temps où je ne fais plus rien
    • Même problème
    • Déjà posée plusieurs fois
    • Pas sûr
  • Obtenir des tâches plus stratégiques et aller au-delà de son rôle.

    Je pense que j'observe pas mal le niveau d'ouverture des gens avec qui je collabore. 

    Ça se voit immédiatement quand quelqu'un est très directif, du style "Je veux que tu fasses ABC et c'est tout. Je ne veux pas savoir ce que tu penses de D". 

    Ça se ressent très vite. Si tu peux estimer,peut-être sur un spectre, l'ouverture des gens avec qui tu travailles, c'est un très bon début. Il faut savoir où tu te trouves si tu veux bouger. 

    Puis par la suite, savoir ce qui est important pour ces gens-là. 

    Je pense que l'idée, c'est toujours d'apporter de la valeur dans un premier temps. 

    Si tu apportes de la valeur, les gens ont l'impression que tu peux transposer ce même exercice à un autre sujet. 

    C'est comme des stars qui deviennent connues en chantant et qui font une marque de vêtements. Pour une raison ou pour une autre, c'est crédible pour les gens qu’ils sont compétents aussi dans ce domaine. C'est un biais que l'on a mais dans un premier temps je pense qu'il faut déjà bien faire, peut être avec le peu que tu as et ensuite demander : "Est-ce que vous êtes satisfait avec ce que je fais là ? Je pense que je pourrais être encore plus utile sur tel ou tel sujet"

    Sincèrement, c'est ma façon d'approcher le truc. Vraiment, sans sournoiserie, sans manipulation. 

    J'essaye vraiment d'aider. Quand c'est sincère et quand c'est présenté comme ça, les gens te voient moins comme quelqu'un de louche ou qui cache des choses. 

    Je pense que je peux aider et que ce serait du gâchis de ne pas m'écouter, en tout cas même deux minutes sur telle ou telle chose. 

    D'expériences en expérience tu as ces parties que tu grappilles pour avancer. Mais je pense qu'il faut vouloir aider. Il faut être sincère et vouloir être utile. C'est un état d'esprit qui doit t’animer ! Et il ne faut pas se laisser être emporté dans la direction du vent.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Faire un bilan de connaissances du projet

    Il y a un exercice incontournable que je réalise à chaque projet et qui a une valeur inestimable. Je suis entrain d’écrire un article justement à ce sujet, donc j’essaierai d’être clair et concis, puis je joindrai un lien vers l’article complet si nécessaire. 

    Cet exercice est une version modifiée du KWHL Chart. 

    Un tableau utilisé en phase préparatoire de recherche pour mettre à plat ce qu’on sait ( Know), ce qu’on veut savoir ( Want), comment nous allons l’apprendre ( How), et pour finir ce que nous avons appris ( Learned).

    C’est plutôt simple, dans un premier temps, je vais collecter de la donnée secondaire (données existantes, effort de recherche précédents et leurs apprentissages, …) 

    Après avoir consommé cette donnée, je vais faire un bilan sur ce que l'on sait, ce que l'on ne sait pas, j e vais essayer de le faire avec toutes les personnes impliquées dans le projet.

    Le fait de dire à voix haute ce qu’on sait et ce qu’on ne sait pas, injecte une bonne dose d'humilité dans l’équipe. A partir de ce moment tout le monde part sur un même pied d'égalité, et on peut admettre les choses qu'on ne connaît pas, sans peur d’être jugé.

    Ce bilan de connaissances, je le considère comme étant ma responsabilité et ça rejoint le premier sujet dont on parlait, à savoir le fait de posséder un sujet ou de prendre la responsabilité de quelque chose. J'estime que c'est à moi de réunir et de guider. 

    Je le vois comme ça le rôle de product designer ou de designer en général. 

    Quand c'est possible, je le fais avec des personnes de l'analytics, du business, tout ceux qui font partie du product management ... Tous ceux qui détiennent une connaissance sont les bienvenus. 

    Par contre, quand ce n'est pas possible, je pars d'un document et puis après ça va partir en mail et en requête de données. 

    J'essaye de rédiger des questions et ensuite de les envoyer. 

    Pour les questions j'essaye de ne pas demander de données trop spécifiques.

    J'essaye de poser des questions en premier lieu afin de laisser les gens qui travaillent avec moi réfléchir. 

    Par exemple : "Je veux telle donnée précisément, je veux tels chiffres...". 

    En lisant la question "Est-ce que cette fonctionnalité est utilisée ?", chez quelqu’un ça peut déclencher encore d'autres questions que moi je ne me serais pas posées. 

    Une personne pourrait penser à d'autres metrics, d'autres choses intéressantes à relever ou d'autres questions à poser encore à quelqu'un d'autre.

    En recherche, rien ne vaut une question bien posée ! 

    La quantité et la qualité d’information qu'on peut tirer d'une bonne question est magique ! 

    Je pense que c'est très important de laisser l'intelligence des gens avec qui on travaille nous aider. 

    Au final je pense qu'ils détiennent une info qu'on n'a pas. C'est bien pour ça que l'on travaille ensemble et parfois on peut passer à côté de choses si on est trop spécifique dans nos demandes.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Le pouvoirs des Checklists

    J’ai pris conscience de l’importance des Checklists grâce à une erreur que j’ai fait sur un de mes premiers projets.

    J’étais entrain de présenter mon travail de façon plutôt confiante, quand un Développeur m’a posé une question anodine en apparence sur l’état d’un composant. Et là, j'ai eu le sentiment de me voir à la troisième personne et je me dis "Colbys comment tu as pu oublier ça ?" . C'était une claque galactique !

    J'ai essayé de rattraper le coup : " Ah oui, effectivement, c'est quelque chose que j'ai oublié, mais au début, j'avais noté ça quelque part, donc je ferai la modification sans que ça change vraiment tout". 

    Mais en réalité, c'était une grossière erreur de ma part. Aujourd'hui ce que je fais c'est que je fonctionne beaucoup par checklist dans tout ce que je fais. 

    Si je dois faire un redesign par exemple:

  • Je vais toujours faire une sorte de curation de l'existant
  • Faire une liste de la cible, des choses comme ça et je vais merger les deux en une checklist. 
  • J'essaye de toujours avoir une checklist, par exemple de tous les composants, de tous les états d'une page, de tous les états d'un service, de tous les statuts possibles, d'un système. 

    Ainsi je vais toujours me fier à cette checklist. Donc au fur et à mesure que j'avance, je vais l'ouvrir et je vais checker. Vient enfin le jour de la présentation et je sais que je suis prêt et que je couvre tous les uses case. 

    Je sais ainsi qu'il n'y aura pas de question qui va me mettre K.O. On n'abuse jamais assez des check-lists !

    Sur les produits denses en plus, il y a beaucoup de choses à prendre en compte et je pense qu'il n'y a pas de honte à connaître ses limites. C'est nécessaire pour bien faire.


    La création d’une Checklist

    Quand je dois partir de zéro sur un projet, je fais  de la recherche pour connaître les besoins, les contraintes, … les informations à afficher, dans quel ordre, par priorité. 

    Par contre, si c'est un projet existant, je découpe d’abord l'existant. J'essaye toujours de découper les choses et de les grouper avant d’attaquer la phase la recherche.

    Je vais prendre l'exemple d'une page car c'est à une échelle réduite et ça aide à visualiser ce que je veux dire . 

    Si je dois redesigner une page, je vais la découper en plusieurs morceaux. Il peut y avoir la navigation d'une part, un fil d’Ariane, la pagination ou un footer. 

    Je vais découper tout ça, leur donner des noms et les grouper.

    Dans ma checklist, je vais inclure chaque élément qui compose ces bouts de la page ainsi que leurs différents états à prévoir. 

    Par exemple, dans le footer, je vais avoir des liens vers telle ou telle page, peut-être des CGU, …

    À partir de là, normalement, l'exercice est relativement simple parce qu’au fil de la recherche, quand j’identifie les nouveaux composants à apporter, je les rentre dans cette checklist, il me suffit juste d'un petit tag pour différencier l’existant du nouveau, et voilà ma Checklist est complète et me donne une vue d’ensemble.

    Ça  m'aide à faire du zoning parce que si je dezoome, je sais tout ce qui doit être sur cette page-là. Puis à l’étape de wireframing, je vais zoomer et travailler sur chaque bout de la page individuellement.

  • merci! Utile
  • Pas utile
  • Pas sûr
  • Collaboration UX - PM, jusqu'à où aller avec l'évangélisme ?
    Comme vous l'avez pu expérimenter tous sans doute, la maturité UX n'est pas pareille dans toutes les organisations, ni parmi les product managers d'une même organisation. Faire de l'UX c'est aussi choisir ses batailles et parfois vivre avec un cadre assez restraint. Bien qu'on est là pour mettre en question le scope de ce qui nous est demandé, jusqu'à où méner la bataille ? Je parle des cas où toute la feature a été pensée et budgettée, "il faut juste un petit design" pour passer en dev. Comment faire si on est mené à faire de la pédogagie en permanence, et comment savoir que c'est le moment d'arrêter la lutte ? (Question un peu réthorique mais un partage d'expériences m'intéresserait !)
    • Même problème
    • Déjà posée plusieurs fois
    • Pas sûr
  • EUROIA en Septembre 2023: Conférence sur l'architecture d'information
    La conférence sur l'architecture d'information se passe à Amsterdam cette année, et je la co-organise ! https://euroia.eu/ 🎟 Plus que 2 jours pour acheter vos tickets en premières ventes. 🎟 ➡️ https://lnkd.in/ednM7hfg Liens des présentations disponibles: https://euroia.eu/all-presentations/
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX, comment je travaille avec les développeurs.
    Dans mon expérience professionnelle, j'ai remarqué un paradoxe intéressant : j'ai généralement trouvé plus facile de collaborer avec des développeurs back-end qu'avec des développeurs front-end. Les développeurs front-end sont très impliqués dans le flux de travail d'un projet, et ils ont souvent leur propre vision de l'UX, de l'accessibilité, etc. Ils possèdent une expertise que de nombreux UX designers n'ont pas, mais ils ont tendance à être très attachés à leurs propres idées concernant les interactions, le JavaScript et ce qui est ou n'est pas bénéfique pour l'utilisateur. En ce qui concerne les développeurs back-end, j'ai trouvé leur approche de travail très intéressante. Malheureusement, ils sont souvent considérés comme une priorité moindre dans un projet, et leurs contributions arrivent généralement en fin de processus.  Cependant, j'ai adopté une approche pour remédier à cela dans chaque nouveau projet : Établir un cahier des charges et des exigences très précis pour le front-end, accompagnés d'une documentation approfondie. Cela permet de fournir aux développeurs front-end un maximum d'informations dès le départ. Travailler en collaboration avec les développeurs back-end dès le début du projet. Les développeurs front-end ont souvent des idées bien définies sur l'UI et les interactions, tandis que les développeurs back-end sont avides de connaissances et ont un état d'esprit plus ouvert.  En travaillant ensemble dès le début, les développeurs back-end peuvent apporter des connaissances, des idées et des propositions qui sont plus ouvertes à la discussion que celles des développeurs front-end. Quoiqu’il arrive il est essentiel d'inclure les développeurs front-end et back-end dès le début du projet, lors de la phase de réflexion et de stratégie.  Trop souvent, cette phase stratégique néglige l'apport des développeurs back-end, alors qu'ils ont souvent des idées pertinentes à partager.  Par exemple, lors de la définition des objectifs du projet, des objectifs commerciaux et des objectifs des utilisateurs, il est crucial de prendre en compte les implications du back-end. Pour éviter les problèmes, il est important d'impliquer les développeurs back-end dès le début et de rapidement préciser aux développeurs front-end que les décisions relatives au front-end seront définies par la recherche, la stratégie et les objectifs commerciaux. En ce qui concerne la gestion de projets, j'ai utilisé différentes approches pour m'aligner avec les développeurs.  Par exemple, j'ai souvent utilisé un document Google Docs pour suivre les annotations, en organisant le contenu par chapitres et thématiques (stratégie, recherche, etc.). Cela fonctionne bien lorsque le budget est limité. Une autre approche que j'ai mise en place avec mon équipe il y a deux ans consistait à créer un document structuré de la même manière que le site web et ses pages.  Cela nous a permis de développer une refonte complète du site en ayant un document qui correspondait à chaque section du site. Ce document, qui était accessible aux équipes IT, front-end et UX, nous a permis de contribuer les résultats de nos recherches. L'idée était que lorsqu'une personne consultait le moteur de recherche interne, elle savait qu'il existait un document dans la structure qui était un Google Doc regroupant toutes les informations pertinentes. Ce document contenait des informations provenant à la fois du front-end et du back-end. Pour moi, les documents liés à l'UX doivent être vivants et évolutifs. Le cahier des charges, qui est la référence principale, renvoie à des documents externes tels que les personas, les prototypes, et d'autres éléments importants à détailler. En résumé, pour optimiser la collaboration avec les développeurs front-end et back-end, il est essentiel d 'inclure ces deux parties dès le début du projet et de clarifier rapidement les responsabilités et les décisions.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Thread sur comment designer pour la VR - par un ex Apple.
    Un ex-designer d'Apple à posté un super bon retour d'expérience sur le process de designer pour la VR. wikihero-image-id: 1093 Thread ici
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Appel d'offre : jusqu'où s'investir ?
    Une question assez récurrente quand on travaille en freelance ou en agence, est de savoir jusqu'où détailler sa proposition pour tenter de remporter un appel d'offre. Le client veut sentir qu'on a compris son besoin et être sécurisé avant de choisir l'équipe qui l'accompagnera, mais à quel moment ça devient excessif ? On se retrouve parfois face à des agences qui font des parcours entiers en UX et UI. Personnellement, je suis mal à l'aise avec cette approche car il me semble que ça dénature les enjeux de la phase de recherche et de cadrage qui, par définition, vont alimenter et structurer les propositions qu'on fera en phase de design. J'essaie de trouver le bon curseur entre trouver des leviers pour démontrer son expertise sans piétiner les raisons d'être de la phase de cadrage, de recherche et de co-construction. Avez-vous une approche/expérience différente ?
    • Même problème
    • Déjà posée plusieurs fois
    • Pas sûr
  • Mon REX sur l’implémentation et la restructuration de process UX avec SAFe

    Dans ce post, je vais vous parler de ma méthode de travail pour trouver un équilibre entre la méthodologie agile et UX. Je partagerai également les outils que nous utilisons pour gérer nos backlogs et prioriser nos tâches.

    En ce moment, je suis très impliqué dans la mise en place d'un nouveau modèle chez mon client pour établir la manière dont nous travaillons. Cela correspond à du “Dual-Track Agile” ou encore une méthodologie de “Product Discovery / Product Delivery”. On n’est pas très loin non plus d’une méthode Shape Up de Basecamp.

    En gros, nous avons deux axes de fonctionnement parallèles : 

  • La partie implémentation et développement qui fonctionne en mode scrum classique avec des sprints de développement, où nous intervenons pour ajuster les éléments de design et gérer les tests utilisateurs en cours de sprint. 
  • En parallèle, nous travaillons sur la recherche et la découverte, qui ne fonctionne pas en sprint car cela peut prendre du temps variable en fonction des besoins et des activités, parfois une semaine, parfois un mois. 

    Nous utilisons une approche plus classique pour la recherche, en gérant un backlog de découverte et en traitant les priorités à l’aide d’un Kanban. Une fois traités, les sujets de recherche testés et validés sont finalisés sous forme de story et quittent le backlog de découverte pour aller nourrir le backlog de développement.

    Nous intervenons ensuite assez peu dans le flux de développement, uniquement pour les petits ajustements nécessaires en cours de route. 

    Une fois que les éléments sont ancrés, nous gérons les tests et les retours pour nourrir le backlog de découverte. Cela nous permet de travailler sur ces deux modèles en parallèle, avec deux "lignes de production" distinctes sur lesquelles nous travaillons.

    Ce mode de fonctionnement fonctionne plutôt bien pour nous, mais le plus important à retenir c’est qu’aucun framework n’est parfait.

    Il faut souvent adapter un modèle au contexte de l’entreprise et du projet / produit sur lequel on travaille car chaque sujet est différent et les équipes ont une culture et une expérience différentes. Si on ne prend pas en compte ce contexte et qu’on cherche à appliquer une méthode, quelle qu’elle soit, au pied de la lettre, c’est le meilleur moyen de se prendre le mur.

    Auparavant, j'avais tendance à aligner la recherche sur la même cadence que les sprints de développement, mais cela ne faisait que créer une pression inutile. Nous nous retrouvions parfois à la fin des sprints avec des recherches partielles, ce qui n'était pas efficace. 

    Passer à une approche plus classique pour la recherche nous a simplifié la vie et nous a donné une meilleure visibilité sur nos activités. 

    L'équipe de développement a également bien accueilli ce changement, car cela ne perturbe pas trop leurs habitudes de travail, et cela fonctionne donc plutôt bien pour eux. 

    La seule difficulté que nous rencontrons, c'est que nous avons deux backlogs distincts : le backlog de découverte et le backlog de développement. 

    Étant donné que nous travaillons en mode kanban d'un côté et en mode sprint de l'autre, il n'est pas toujours facile de les gérer dans le même outil. 

  • En terme d’outils nous utilisons principalement Google Sheet pour gérer le backlog de découverte, car c'est plus pratique que des outils traditionnels pour établir les priorités avec différents axes de travail. 
  • Pour les ateliers et la priorisation des différents types d'utilisateurs, nous utilisons Miro, car c'est l'outil déployé chez mon client. 
  • Ensuite, nous résumons les résultats dans Google Sheet pour suivre les étapes, déplacer les éléments dans nos backlogs, et réaliser le design. Pour le design, nous utilisons différentes méthodes en fonction des besoins, comme Figma pour les designs plus complexes, ou des Google Sheets ou Google Docs pour les éléments plus structurés, comme les formulaires. Parfois, nous créons également des prototypes pour les faire tester, mais dans le projet actuel sur lequel je travaille, ce n'est pas nécessaire.

    Pour vendre cette nouvelle approche, cela a été plutôt complexe et tendu.

    Le client est en pleine transformation et a mis en place un modèle hybride entre SAFe et le pseudo-modèle Spotify (“pseudo-” car ce modèle n’est pas réellement utilisé chez Spotify), avec des personnes ayant peu d'expérience en agilité, pensant peut-être que certifier les équipes à tout va suffisait à réaliser une transformation Agile... 

    Cependant, ce modèle n'a pas été bien évalué, car ils n'ont même pas encore établi de retour d'expérience sur le MVP avant de le généraliser à d'autres équipes, ce qui est une première erreur. 

    Pour donner un exemple concret de ce qui ne fonctionnait pas, sur un projet en particulier, le coach Agile qui nous accompagnait cherchait à nous imposer ce modèle, car c'était la consigne qu'il avait reçue, même si ce n'était pas du tout pertinent pour le produit sur lequel nous travaillions.

    Heureusement, avec l'aide de la Product Manager (PM) avec qui je travaille depuis presque un an, nous avons pu proposer une orientation différente pour les squads et la structure du projet : Étant donné que notre produit a des sous-produits avec des équipes techniques et métiers différentes, il était important d'avoir des Product Owners (PO) dédiés à chaque sous-produit, ainsi qu'un PO global pour la vision globale du produit

    Nous avons donc dû sortir du modèle officiel qui nous était imposé, ce qui a généré quelques discussions sur le choix des termes, mais pour moi, le wording n'était pas un point crucial.

    De plus, étant donné que notre charge de travail allait évoluer au fil du temps, avec des petites et potentiellement grandes évolutions à gérer, nous avons mis en place un système évolutif avec une capacité à scaler facilement. 

  • Nous avons convenu qu'au début, nous aurions un Scrum Master commun pour gérer plusieurs squads
  • À terme, si nous devions multiplier les squads, nous aurions besoin d'un Scrum Master dédié à chaque sous-produit, qui pourrait gérer plusieurs squads, dans une limite de trois maximum. Cela s'explique aussi par le constat que le rôle de Scrum Master n'est pas à temps plein, et qu'il peut être partagé entre plusieurs produits et squads.
  • Cependant, gérer un écart important entre trois squads avec des équipes potentiellement différentes serait difficile à gérer en raison des différences de rythme, de fuseaux horaires et de rituels (notamment pour les daily.)  D’où l’objectif de maintenir une cohérence au sein d'un même produit ou groupe de produits en impliquant les mêmes acteurs dédiés.  Nous avons ainsi synchronisé les moments clés, tels que :  La planification des sprints, en commençant par une planification globale avec le Product Owner (PO) global, puis en se divisant en planifications spécifiques à chaque sous-produit.  De même, pour les rétrospectives, nous commençons par celles de chaque sous-produit avant de remonter au niveau global, afin de toujours garantir une vision transversale.  Les daily stand-ups sont également synchronisées pour maintenir un rythme cohérent.  De plus, si nous avons besoin de lancer des sous-projets, nous appliquons le même principe en adaptant l'échelle de manière appropriée et intelligente, en avançant avec un backlog commun qui se divise ensuite en sous-backlogs par sous-produit, avec une partie dédiée à la découverte et au développement.  Nous avons imposé cette approche, en laissant les équipes discuter des détails de formulation. Au départ, elles étaient réticentes, mais nous avons expliqué que c'était ainsi que nous allions procéder en raison du contexte spécifique du produit.  Pour résumer : Étant donné que les équipes n'étaient pas en mesure de nous proposer une organisation répondant à nos besoins, nous avons pris l'initiative de la créer. Cette organisation correspond à nos besoins actuels, mais nous sommes conscients qu'elle peut nécessiter des ajustements, que nous effectuerons en temps voulu. Nous avons déjà mis en place un modèle adaptable en fonction des KPI’s. Pour plus de rigueur, j'ai également effectué une recherche pour vérifier que cette approche n'était pas uniquement de mon invention, et j'ai trouvé des frameworks similaires, tels que LeSS et LeSS Huge qui correspondent à 95% à ce que nous avons proposé.  Nous avons ainsi pu légitimer notre approche en nous appuyant sur ces références externes.  En appliquant ces principes, nous avons un PO global et des area PO pour chaque zone et sous-produit, avec des domaines de besoins spécifiques.  Cette approche a permis de faciliter l'adhésion des équipes à la stratégie. En effet, nous avions constaté que l es équipes partaient souvent trop rapidement dans la définition du produit sans prendre en compte la stratégie produit et la roadmap.  Même si cela ne correspond pas entièrement à notre modèle actuel, nous estimons que c'est la meilleure approche pour notre équipe et cela nous permet de mieux remonter les besoins des utilisateurs.  Il est également important de noter que les recherches que nous effectuons ne se limitent pas uniquement aux aspects digitaux. En effet, dans notre entreprise, nous ne demandons pas aux équipes de remonter les problèmes liés uniquement au digital. Même si certains aspects ne sont pas digitaux, il est important de les reconnaître, car ils peuvent être transmis aux équipes responsables des processus, des ressources humaines, des infrastructures, de la communication, etc. De ce fait, la phase de recherche, bien qu’officiellement liée à un produit, a une portée plus transverse et nous remontons régulièrement des sujets à d’autres équipes produits (ou même des équipes ne fonctionnant pas sur ce type de modèles). Notre objectif est de travailler de manière globale, holistique et systémique avec toutes les entités, sans se limiter à notre domaine digital. En effet, cette approche va à l'encontre des objectifs mêmes de la transformation.
  • Thierry Raguin · Design Strategist / ResearchOps / DesignOps / UXR / UXD · il y a 11 mois
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Mes leviers pour améliorer la maturité Design Ops en interne.

    Ce que je fais pour améliorer la maturité DesignOps en interne est principalement de la pédagogie basée sur des mesures de maturité (j’utilise en général le modèle de Sauro) et une cartographie DesignOps. 

    J'adopte une approche pédagogique via les ateliers pour: 

  • Expliquer les composants d'une stratégie
  • Et comment les mettre en œuvre. 

    (Lors de ces ateliers je ne fais pas toujours de distinction nette entre la recherche et la conception, car dans le contexte dans lequel je travaille, ces deux aspects sont souvent étroitement liés, bien que nous mettions davantage l'accent sur la recherche.)

    Je m'appuie sur un modèle de cartographie matricielle que j’ai mise en place sur la base des définitions du Nielsen Norman Group et que nous suivons tous les mois.

    Nous faisons un constat initial sur:

  • Des axes définis tels que le processus, la capitalisation, le recrutement, le développement des compétences, le leadership, etc.
  • Nous identifions les axes sur lesquels nous voulons nous concentrer pendant le mois.
  • Ensuite, chaque mois, nous travaillons sur ces sujets et nous mettons à jour, faisons évoluer et faisons avancer nos pratiques pour gagner en maturité. 

    En amont, nous avons également travaillé en équipe sur la culture et les valeurs communes de l’équipe.

    Cependant, la partie la plus délicate reste souvent la mesure du retour sur investissement (ROI) de notre travail. 

    Les discussions sont souvent compliquées car certaines personnes considèrent le ROI uniquement en termes d'argent, alors que nous devons parfois mesurer des éléments plus intangibles, tels que le temps économisé, ce qui peut être difficile à quantifier étant donné que nous intervenons souvent en amont du processus. 

    Nous ne pouvons pas toujours calculer de manière précise l'impact de notre travail sur le retour sur investissement, à l'exception d'exemples concrets tels que celui du bouton à 300 millions de dollars mentionné par Jared Spool

    Il est donc difficile de trouver des exemples clairs et immédiats. 

    Cependant, nous continuons à progresser en mettant en place des indicateurs clés de performance (KPI) pertinents pour notre équipe, notamment via la mise en place systématique, pour chaque produit, d’enquêtes de satisfaction qui permettent de mesurer l’impact des changements apportés à chaque release. J’ai pour cela mis en place un modèle d’enquête complet basé sur l’UMUX-Lite (avec calcul du score System Usability Scale (SUS) équivalent) avec un workflow d’analyse en grande partie automatisé. Cela nous fait gagner énormément de temps car il est extrêmement simple et rapide à mettre en place.

    Mais cela ne peut fonctionner qu’après avoir passé du temps à démontrer l’importance et la valeur de ces indicateurs aux parties prenantes internes et externes de l'entreprise, ainsi qu’à nos clients, car souvent ils souhaitent conserver leur “NPS” (Net Promoter Score) qui est souvent mal utilisé, mal compris et surtout très peu pertinent… Bref, c'est souvent la partie la plus difficile et la moins consensuelle, mais nous progressons petit à petit sur cet aspect, avec notamment la mise en place d'un portfolio percutant pour notre équipe, à la fois en interne et en externe.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Une erreur : Foncer tête baissée dans les projets sans penser à la politique.

    Une erreur que j’ai commise dans ma carrière était de ne pas identifier les sujets politiques, (internes ou externes), et les motivations de chaque personne liée à ces projets. 

    Je pense qu'il est essentiel de bien comprendre les personnes avec lesquelles je vais interagir au cours d’un projet et de toujours prendre du recul avant de démarrer. 

    Aujourd’hui je suis attentif à : 

  • Leurs positionnements
  • Leurs objectifs 
  • et leurs motivations. 

    Parfois, il peut arriver de travailler avec des personnes difficiles, voire manipulatrices, qui cherchent à exercer un contrôle excessif sur les projets. Il est donc important de les identifier dès que possible et d'apprendre à naviguer autour d'elles.

    Pour moi, une approche efficace consiste à écouter mon intuition et à comprendre les objectifs de ces personnes. 

  • Qu'est-ce qui les motive ?
  • Qu'est-ce qui les pousse à agir ? 

    En comprenant leurs perspectives, je peux mieux travailler avec elles et les amener à contribuer dans la direction attendue, tout en les laissant croire qu'elles mènent la prise de décision.

    Il est également crucial de bien connaître l'écosystème dans lequel j'évolue. 

    Cela signifie comprendre les autres acteurs impliqués, leurs objectifs et leur niveau de maturité par rapport à mes domaines d'expertise, tels que l'agilité, la recherche et le design. 

    Il peut être judicieux de concentrer ses efforts sur les personnes ou les sponsors les plus favorables à l’approche proposée, plutôt que de perdre du temps avec ceux qui sont fermés au changement.

    Cependant, je conviens que ce n'est pas toujours facile et que cela demande du temps et des efforts. 

    En tant que freelance, il peut être encore plus compliqué de comprendre les dynamiques internes d'une entreprise. Il peut être utile de collaborer avec des collègues ou des experts qui ont de l'expérience dans ce domaine pour obtenir des conseils et des orientations. Pour résumer, voici comment je m’y prends pour éviter de foncer tête baissée dans les obstacles politiques.  Qu'est-ce qui fera avancer cette personne ?  Qu'est-ce qu'elle cherche réellement ?  Comment est-ce que je peux agir sur ses déclencheurs, ses objectifs ? Afin de remettre les choses de son point de vue, de sa perspective, et essayer de partir de là pour avancer. Ensuite, je cherche aussi à identifier les autres acteurs dans l'écosystème, à comprendre ce qui les motive, quels sont leurs objectifs, et ainsi savoir dans quelle direction je peux tirer pour atteindre les objectifs fixés.  Ce n'est pas toujours évident, car je ne suis pas spécialiste dans ce domaine, mais j’ai eu la chance de travailler en étroite collaboration avec un spécialiste avec qui j'ai pu échanger régulièrement et cela nous a permis d’obtenir de très bons résultats. Nous avons travaillé sur une cartographie des parties prenantes pour essayer de visualiser tous les acteurs importants autour de nous, comprendre ce qui les motive, comment ils fonctionnent, s'ils sont en accord avec nos objectifs, s'ils sont matures dans nos domaines d'expertise, tels que l'agilité, la recherche et le design. Pour cela, nous avons notamment utilisé le modèle de saillance des parties prenantes (“Stakeholder Saliency Model”)wikihero-image-id: 1066 Stakeholder Saliency Model ( source) Cela nous permet de mieux collaborer avec eux, de savoir avec qui concentrer nos efforts, qui ciblerSi nous constatons que certaines personnes sont totalement réfractaires au changement ou fermées à toute idée, nous ne perdons pas de temps avec elles. Nous cherchons plutôt à obtenir le soutien des sponsors pour faire avancer les choses dans la bonne direction.  En ce qui concerne les sponsors, les réactions des gens sont différentes, et nous cherchons à identifier les personnes les mieux placées pour nous aider à progresser dans la direction souhaitée.  C'est un travail de fond important, parfois réalisé en coulisses, car ce n'est pas toujours notre mission principale. Cependant, nous le faisons dans l'intérêt de notre mission globale, afin de nous assurer que nous avançons dans la bonne direction.  Ainsi, nous avons des objectifs clairs qui nous motivent à accomplir ce travail, même si ce n'est pas toujours facile pour moi, car ce n'est pas ma spécialité.  Mon collègue, quant à lui, est davantage spécialisé dans l'organisation de l'écosystème. Cependant, je m'implique de plus en plus dans ces tâches pour répondre aux besoins de notre équipe et c’est un sujet très intéressant et bénéfique pour notre métier. En tant que DesignOps / ResearchOps, c'est ce que nous faisons également au sein de notre équipe : Créer une culture et des valeurs communes, et nous insérer au mieux dans l'organisation. Il est courant de partir d’un modèle de maturité pour évaluer notre niveau actuel, faire un constat et un audit, puis planifier la progression vers des niveaux supérieurs. Pour ma part, j’ai une préférence pour le modèle de maturité de Jeff Sauro. Dans ce cadre, et encore plus lorsqu’une transformation globale de l’entreprise est en cours comme c’était le cas pour l’entreprise pour laquelle j’ai récemment travaillé, ce travail de cartographie des parties prenantes est particulièrement crucial pour identifier les obstacles qui peuvent entraver le développement de l’UX et qui peuvent nous ramener en arrière et qui, au contraire, va pouvoir être moteur dans ce développement et permettre de gagner en maturité. C'est là que la politique entre en jeu. Il est donc essentiel de trouver les bons sponsors et les bons leviers pour nous aider à avancer.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • L’illusion des raccourcis

    Il fut un temps où j'avais tendance à adopter un comportement qui finissait par me décevoir. J'avoue être parfois un peu flemmard. Bien que j'aime fournir les efforts nécessaires, il m'arrive parfois de chercher des raccourcis.

    Quand j'étais plus jeune, j'espérais trouver des astuces pour simplifier certaines choses. Je pensais qu'il y avait des raccourcis pour atteindre mes objectifs. Cela était étroitement lié à l'idée de patience. Mais j'ai rapidement appris à mes dépens qu'il n'y a pas de raccourcis.

    Parfois, il en existe, mais généralement, ils ont un coût caché. Ce coût n'est pas immédiatement perceptible.

    Au final, ce que tu penses économiser en termes d'efforts se transforme souvent en leçons que tu apprends plus tard. Tu réalises que ces efforts étaient nécessaires pour réellement avancer. Je ne veux pas être dogmatique, mais je pense qu'il y a une vertu dans les efforts que nécessitent certaines choses.

    Au début de ma carrière, je souhaitais avoir plus de responsabilités que ce qui m'était confié, car je pensais que c'était le seul moyen de faire ce que je voulais réellement faire.

    J'avais cette idée idéale selon laquelle si j'avais le pouvoir de décision, qui était lié à la responsabilité, je pourrais réaliser mes aspirations. Cependant, il est biaisé de penser que la responsabilité entraîne automatiquement le pouvoir de décision.

    Ce n'est pas toujours le cas. J'étais en quête de ce pouvoir de décision à travers la responsabilité. Cette impatience m'a poussé à parfois aller trop vite. À cette époque, je n'étais pas encore orienté vers la conception d'interfaces ou de solutions numériques, mais plutôt vers la conception de produits physiques et l'architecture. J'espérais pouvoir travailler rapidement sur des projets qui m'intéressaient, alors j'ai accepté de collaborer avec des personnes dans l'espoir d'acquérir cette capacité de prendre des décisions qui m'intéressaient.

    Finalement, cette volonté d'aller trop vite m'a mis en relation avec des personnes qui, rétrospectivement, n'étaient pas les plus fiables. Ce n'étaient pas des individus recommandables avec qui travailler.

    Ils avaient l'expérience de lancer de nombreux projets et initiatives pour collecter des fonds, mais ils ne parvenaient jamais à les concrétiser. Cela m'a placé dans des situations problématiques. Lorsque tu es jeune et étudiant, tu peux t'en sortir. Mais lorsque tu commences à te poser, à être en couple et à réfléchir à l'avenir, tu ne veux plus vivre ce genre de situations. Cela change ta perspective.

    Pendant de nombreuses années, j'ai également dirigé une agence de communication où j'acceptais des clients car leurs projets semblaient faciles à réaliser. Cependant, ces clients ne savaient pas toujours ce qu'ils voulaient, ce qui aboutissait à de nombreux allers-retours et à une course après les paiements.

    À ce moment-là, tu te demandes si tout cela en vaut réellement la peine. Qu'est-ce que cela t'a apporté ? Plus de problèmes que d'avantages, malheureusement.

    Finalement, tu apprends. Tu te rends compte que ce genre de situation n'est pas une bonne stratégie. Je vois maintenant que cette recherche de facilité, parfois associée à l'idée de prendre des décisions, s'est retournée contre moi.

    J'observe également cette erreur chez d'autres personnes plus jeunes dans la profession avec qui je discute. Je ressens l'impression qu'ils doivent faire ces erreurs eux-mêmes pour en tirer des enseignements réels. On peut dire ce que l'on veut, mais j'ai également reçu les mêmes avertissements et conseils. Malgré cela, j'ai agi selon ma propre vision. J'ai subi les conséquences nécessaires pour apprendre.

    Est-ce si grave que ça ? Parfois, cela peut être grave lorsque cela te met réellement dans une mauvaise situation. Je dirais que c'est dommage. Si c'est évitable, c'est vraiment regrettable. D'une certaine manière, tu apprends. Parfois, tu dois faire tes propres expériences pour comprendre ce qu'il faut faire et ne pas faire.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Curiosité et patience comme vertu en tant que professionnel

    J'ai réalisé que l'un des conseils qu'on m'a déjà donné, mais qui est difficile à entendre quand on débute, c'est d'être patient.

    C'est une qualité qui s'acquiert avec le temps, celle de savoir prendre son temps et comprendre que les choses arrivent à leur moment, pas nécessairement quand on les attend.

    Je sais que cela peut sembler vague et générique, mais je n'ai pas de conseil spécifique à donner, car j'ai toujours été curieux et je pense que c'est essentiel. Il est important en tant que designer de s'intéresser à d'autres domaines que le design, d'explorer ce qui se passe ailleurs et de voir comment cela peut enrichir notre propre travail.

    Personnellement, je suis un idéaliste qui a appris à être pragmatique. J'ai toujours eu cette volonté de faire les choses d'une certaine manière, en cherchant une certaine perfection ou du moins quelque chose qui s'en rapproche.

    Il y a une beauté dans cette tentative d'atteindre un idéal, et c'est ce qui me motive depuis le début. Cependant, j'ai aussi appris à être pragmatique et à comprendre ce que nous pouvons réellement accomplir en travaillant avec les autres. Cette compréhension pragmatique est le fruit de mon expérience sur le terrain, car j'ai réalisé que les choses prennent du temps et que chaque personne réagit différemment à ce que nous apportons.

    Au fil du temps, j'ai appris à semer des graines ici et là, et à voir ce qui en ressort vraiment. Cela me rapproche de l'idéal que je souhaite atteindre. J'ai appris à être patient, à comprendre qu'il n'y a pas de solution optimale ou de moyen parfait pour parvenir à quelque chose.

    L'essentiel est de s'engager dans le processus d'essayer, car c'est là que réside l'intérêt. Au début, j'avais du mal à comprendre pourquoi il était si difficile de concrétiser mes idées, malgré ma compréhension du travail d'équipe. Mais au fil du temps, ma patience et ma perception de la capacité des autres à assimiler l'information et à l'appliquer dans leur quotidien ont évolué.

    Ces qualités ne sont pas innées, mais elles se développent avec la pratique. On apprend à connaître les réactions des gens, leur façon d'absorber l'information, et cela varie énormément d'une entreprise à une autre, d'une équipe à une autre.

    Il n'y a pas de méthode universelle.

    Parfois, tout se passe naturellement avec une équipe. Les choses se mettent en place facilement et tout le monde est sur la même longueur d'onde. Dans certaines entreprises, des changements peuvent sembler évidents une fois qu'ils sont mis en place, et on n'a pas besoin d'en faire davantage. Cependant, il y a aussi des moments où des blocages surviennent, pour diverses raisons, justifiables ou non.

    Dans ces cas-là, semer des graines peut être une stratégie utile. On ne sait pas quand elles vont germer ni à quoi elles vont aboutir. Il est important de se rappeler que nous avons peu de contrôle sur le résultat final.

    Ce qui compte le plus, c'est de tendre vers une direction intéressante, de rester pragmatique.

    L'un des défis de la culture actuelle du design est que nous sommes si immergés dans nos processus et nos outils que nous oublions souvent de les contextualiser. Sur le papier, tout semble évident. Les processus et les outils du design nous semblent évidents.

    Mais la réalité du terrain et des autres personnes avec lesquelles nous travaillons est différente. Chacun a ses propres objectifs, impératifs et méthodes. C'est là que la curiosité joue un rôle important. En s'intéressant à d'autres domaines que le design, en sortant de notre bulle, nous prenons du recul et nous comprenons mieux les autres. Nous sommes conscients de leurs impératifs et de leurs processus, et de l'importance que cela revêt pour eux.

    Ce n'est pas seulement une question d'humilité, mais aussi de chercher à partager quelque chose de commun. Lorsque nous parvenons à créer du sens ensemble, nous sommes tous gagnants, car nous avons tous appris des choses que nous ne connaissions pas auparavant.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Diagram , le plug-in d'IA pour vos design sur figma.
    Des makers de automator, ils ont maintenant rajouté la puissance de modèle IA et de prompting directement dans figma. https://diagram.com ps: Racheté par Figma. Ca a été annoncé à la conférence.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Les meilleurs articles que j'ai lu sur le process de design, devenir senior et la priorisation
    De toutes les lectures que j'ai pu avoir, voici mon top 10 d'articles qui ont changé ma perspective sur le mindset à avoir en tant que senior et comment améliorer mon process de design. J'espère que cela vous sera utile ! curieuse de découvrir les vôtres ! Senior Product Designer A guide to becoming a senior product designer by Aaron James Becoming a Senior Product Designer by Shay What is the role of a Senior Product Designer? by Sannan Malik Design Process What is the Design Process? by Andrew Aquino Fostering focus for small screens by Ed Chao Understanding the Kano Model — A Tool for Sophisticated Designers by Jared M. Spool Product Management Why The Impact Effort Prioritization Matrix Doesn’t Work by Itamar Gilad Ruthless Prioritization by Brandon Chu
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Le designer à l'âge de l'AI. Opinion
    https://ridd.substack.com/p/ai-and-the-designer-of-the-future En gros l'IA va permettre: D'explorer plus de terrains qu'avant (le champ des possibles est ouvert) De se spécialiser dans la production de code (sans devoir apprendre ou "coder le code mais comprendre comment il fonctionne") De monter la chaîne de valeur vers le business. (si moins de temps est en production, peut être plus vers les équipes internes.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Libraire de 30+ composants avec des liens aux design systems
    Super petit projet qui répertorie des composants avec par ex: Badge Avatar Accordeon Le plus ? Ces composants sont liés à des design systems existants. https://component.gallery/components/
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX sur le pair design.
    Le moment est propice pour pratiquer le pair design avec Figma, à l'instar des développeurs, ce qui favorise une collaboration plus étroite. À l'époque, je connaissais des designers qui le pratiquaient, même en 2014-2015, mais cela se limitait généralement à deux personnes travaillant sur un seul ordinateur, l'un guidant et l'autre exécutant. Version en duo : Aujourd'hui, c'est devenu une pratique internalisée pour moi, que je réalise sur Figma avec un autre designer, voire plusieurs, mais en limitant le groupe à un maximum de cinq personnes dans mon équipe. Lorsque je fais du pair design avec un autre designer, nous nous mettons sur Figma, examinons le travail existant et le designer qui a des questions ou des suggestions peut dire : "Je souhaite retravailler ce point spécifique dans le design". Nous commençons ensuite à travailler ensemble pour proposer des solutions. Version en groupe : Lorsque le groupe est plus grand, il est important de mettre en place un processus. Nous limitons généralement le nombre de participants à cinq pour faciliter la collaboration. Nous choisissons un sujet spécifique, que nous abordons collectivement en préparant les composants ou les éléments à travailler dans le fichier Figma. Nous expliquons les problèmes à résoudre, puis chaque personne dispose de 20 à 25 minutes pour travailler individuellement. Environ 30 à 35 idées peuvent ainsi être générées en 20 à 25 minutes, ce qui est bien plus productif que si un designer travaillait seul pendant une heure. Après ces sessions, nous ressentons souvent de la gratitude envers le collectif pour la stimulation créative qu'elles procurent. Certains designers peuvent ne pas être à l'aise avec le pair design, car cela nécessite une certaine ouverture et confiance mutuelle. Il peut y avoir des inquiétudes quant à sa rapidité dans l'utilisation de Figma par rapport à d'autres designers. Cependant, dans mon équipe, nous sommes tous alignés sur l'objectif des sessions de pair design, ce qui facilite leur déroulement. Les commentaires sont basés sur le design et nous évitons les jugements personnels du type "j'aime" ou "je n'aime pas". En tant que manager si un designer exprime une réticence à participer au pair design, je prends le temps d'avoir une discussion ouverte pour mieux comprendre ses préoccupations. Je n'impose pas cette approche sans en discuter et expliquer les avantages et la démarche, et généralement, après avoir compris les bénéfices potentiels, les designers de mon équipe ont été enthousiastes à l'idée d'essayer par eux-mêmes.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment savoir si j’ai assez bossé un design ? Le processus que j'ai suivie.
    Le processus de design est à la fois passionnant et exigeant, car la quête de perfection est constante.  Toutefois, au fil du temps, j'ai appris à privilégier la manière dont j'arrive à la solution finale plutôt que le temps que j'y consacre.  Pour moi, un bon design doit être complet, cohérent, utilisable, de haute qualité et efficace, c’est ce qui me donne confiance dans mon processus de design.  Lorsque je suis confrontée à un blocage, j'utilise une checklist. En dernier recours, je m'engage dans des sessions de pair design avec mes collègues de chez Datadog, car nous sommes une grande équipe de plus de 100 designers, et il y a toujours quelqu'un avec qui échanger.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment définir le niveau de gamification où vous voulez aller ?
    Pour définir le niveau “juste” de gamification, on essaye de mixer différentes approches.  Soit on va faire des entretiens avec les utilisateurs et on pose quand même des questions sur tout ce qui est motivation, afin de le connecter avec une grille de lecture des leviers d’engagement. Même si ce n'est pas parfait, ça permet d'avoir une première lecture quand on fait les persona, puisque du coup, on les refait en général pendant le sprint (souvent, c’est un peu hors sol même si, nos clients ne sont pas les plus éloignés par rapport aux utilisateurs.)  Puis, on a effectivement la possibilité de faire des questionnaires. Notamment notre questionnaire sur les 9 leviers d’engagements. On a travaillé avec un doctorant en gamification pour affiner le questionnaire, voir un peu des tendances, etc. Normalement, on aura une publication scientifique sur le questionnaire. C’est une publication qui présentera un peu comment on l'a conçu et quels sont les résultats qu'on en tire.
    Ensuite, on mixe un peu ces différents résultats et on essaye de les confronter aux utilisateurs (que ce soit dans le sprint via des tests de prototypes, que ce soit via de la recherche utilisateur, avec des entretiens ou des questionnaires, ou que ce soit avec des tests plus poussés avec un prototype plus qualitatif, tout dépend du projet et de ses enjeux). Quelque chose que je rappelle souvent c’est que :  Le niveau de gamification qui est optimal, ce n'est pas mettre le plus de gamification possibleMême sur des leviers d'engagement, ce n’est pas mettre le plus de tels leviers d'engagement possible, mais il faut trouver justement l'équilibre qui va par rapport à tes utilisateurs.  Je regarde souvent ce qui se passe dans le monde des jeux qui fonctionnent sur le marché. Il y en a beaucoup qui fonctionnent avec des lootBox (quand tu obtiens une récompense, tu ne sais pas laquelle tu vas avoir.) C’est plutôt une boîte surprise. Et c'est assez utile pour générer de l'engagement.  C'est-à-dire qu'au lieu d'avoir les joueurs qui disent :  “Il faut trois boîtes pour avoir la récompense que je veux, là potentiellement, ce sera une, ce sera dix, ce sera cent.”  On ne sait pas.  C’est un truc qui génère quand même de l’engagement dans la durée pour les jeux et ça reste assez efficace. En tant qu’observateur tu pourrais dire que ça fonctionne bien. Et si on pousse plus loin le concept? Si les gens aiment bien cet effet de surprise aléatoire, il n’y a plus qu'à y aller à fond. C'est ce qu'a fait un jeu qui s'appelle Magic Legend.  En termes de gameplay, c'est un peu comme Diablo, et ça se passe dans l'univers des cartes Magic avec un mix de licence assez sympa du jeu, sauf qu’en fait les concepteurs se disent : Comment on fait pour gagner le maximum d'argent? “ Ils vont y mettre toutes les techniques un peu sales pour gagner de l'argent, notamment dans des LootBox. Ils ont poussé le truc tellement loin, avec tellement d’éléments aléatoires et peu de chances de gagner ce que tu voulais, qu’au final, je crois que 2 ou 3 mois plus tard, ils ont annoncé qu’ils arrêtaient le jeu et qu’ils allaient devoir rembourser les achats, parce qu’en fait ça sentait trop l’arnaque pour les joueurs et donc personne ne jouait. Les utilisateurs se disent : Ce n’est pas ça qu'on veut.”  Je pense souvent que c'est un peu ça la question : “Un peu d’aléatoire, c'est cool. Trop, ce n’est pas cool.”  Du coup, la question, c'est à quel niveau c'est OK ? Eh ben ça dépend de l’utilisateur pour chacun de ces éléments de gamification, il faut choisir le bon niveau.  – Et c’est là que la base de connaissance méthodologique est clé. (comme notre méthode Fidbak où on s’intéresse aux utilisateurs, qu’on prévoit des tests, etc.) Je donne un exemple:. Hier, je faisais une formation pour des formateurs sur comment travailler la gamification.  Parmi les gens qui sont venus, il y en a plein qui s’attendaient du coup à ce qu’ils découvrent une boîte à outils de jeu: Avoir tel levier d’engagement pour telle situation Mais non, ce n’est pas comme ça que ça fonctionne. Lors de la formation je leur ai expliqué que justement que l’on ne va pas parler de jeu. On va parler de gamification, mais pas directement de jeu. C'est typiquement le genre de personnes qui, généralement, va avoir beaucoup de mal à se poser sur ces questions d'objectifs, de persona, etc.  Dans ce que j’observe c’est le genre de personnes qui veulent juste vouloir avoir son jeu.  Par exemple, je les choque lorsque je dois leur dire “Il y a des gens qui aiment bien jouer en ayant de la compétition, et d'autres qui n’aiment pas.”  Parce que jusqu'à maintenant ce qu’ils connaissaient dans les jeux, c’était la compétition.  Mais si dans certains jeux il y a de la compétition, il y a plein d’autres qui n’en n’ont pas.  Pour nous, c'est important de recadrer un peu ces éléments de méthode et de problèmes. Ensuite, on fait assez souvent bouger la méthode qu'on travaille pour les clients parce que justement, il y a besoin de l’adapter à différents types de contraintes.  On a l'impression que c'est linéaire, mais en réalité c’est complètement itératif, on passe notre temps à évoluer sur plein de points différents, à faire des tests, etc.  Ce sont des choses que les gens ont un peu plus de mal à appréhender.  Pour l'instant, on est plutôt contents de notre méthodo « sprint », mais on continue d'affiner un peu ce que ça ne fait pas si longtemps que ça qu’on fait des sprints sur la gamification et qu’on rencontre toujours des cas particuliers. C’est aussi ça qui rend le sujet aussi passionnant.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Poussez à l’embauche de collègue dans vos équipes. N’essayez pas de tenir la baraque seul.e
    Une erreur que j’ai faite c'est de ne pas pousser à l'embauche. Que ce soit en tant que manager ou en tant que designer. En début de carrière il m’est souvent arrivé de ne pas pousser à l'embauche de plus de designers. Spécialement lorsque j'étais la première designer d'une startup.   Je pensais que proposer cela était une marque de faiblesse. En réalité, c’est tout l’inverse !  Je pensais que c’était l'opportunité de montrer que j'étais capable de prendre sous ma responsabilité plus de projets, de faire encore plus. Et c’était surtout, il faut l’admettre, une manière de rester dans le contrôle.  Je m’explique : Lorsque l’on est tout seul, on arrive à gérer son rythme, son emploi du temps jusqu’à être sous l’eau. Et ce n’est qu’à ce moment-là que l’entreprise prend la décision d’embaucher.  Entre le temps de l’annonce et l’embauche (il faut en moyenne 3-6 mois) c’est déjà trop tard en terme de charge de travail. Tu prends la surcharge entre temps, tu grinces des dents en espérant que cela s’améliore.  Le conseil que je donnerai, (et que dorénavant je m'applique à moi-même)... c'est d'embaucher avant d'en avoir besoin.  Pour cela, je track le temps passé sur les différents projets que j’entreprends et lorsque je commence à me rapprocher de 100% de mon temps sur des sujets sans avoir la possibilité de dégager plus de temps pour d’autres activités comme la recherche exploratoire, je me dis  "Il faut que tu embauches ! " .  Ou il faut que je pousse à l'embauche, en disant qu'il nous faut un collaborateur de plus sur tel ou tel sujet et surtout d'expliquer pourquoi ! Il faut bien expliquer pourquoi tu as besoin de quelqu'un, et non pas juste signifier un besoin.  Sinon, on peut se demander : Pourquoi tu n'as plus le temps ? Comment tu rationalises ce temps ?  Quel est ton ratio sur chaque projet ? Quel impact positif cela peut-il avoir sur la boite ?  C'est la meilleure manière de s'aider soi-même et d'aider la boite. Pour “comptabiliser” le temps, ce que je fais, c 'est que je me donne des ratios de temps que je devrais passer sur certaines activités afin d’assurer une qualité de projet finale.  Par exemple, la research est un élément hyper important pour moi, mais que je vais avoir tendance à déprioriser parce qu'il faut livrer tel ou tel projet...  Je me suis toujours dit:   " Il me faut 20% de mon temps, en research” (et c'est beaucoup 20%...) Quand je n'arrivais pas à atteindre ce quota, j'en constatais les impacts en interne. On n'arrivait pas à comprendre cette problématique On n'arrivait pas à valider cette hypothèse On pourrait aller plus vite sur cette fonctionnalité-là etc.  Lorsque tu décortiques tes activités en % de ton temps et tu lie ça aux résultats que cela produites personnes comprennent naturellement pourquoi tu as besoin de plus de gens et sur quels sujets.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Mon astuce: Développer son sens de l’imaginaire
    Moi, à la base, je suis pur introspectif Donc si on me fiche la paix, si je suis tout seul, ça me va. J’ai dû apprendre à aller vers les autres.  Le principal conseil que je donnerais à un designer, c'est d’imaginer, le design comme une conversation. Avant toute chose, c’est les mots avant les visuels.

    Il faut être capable pour collaborer avec les autres, qu'ils designers soient ou non, mais de pouvoir parler. 

    Ca veut dire quoi? 

    Ça veut dire observer un metteur en scène qui donne un feedback à un acteur. C’est dans cette capacité créatrice de pouvoir utiliser du langage pour parler de design. Par exemple, Loris Olivier, le typographe qui a créé les typographies de Whispers & Giants, c’est la personne dans ma carrière avec qui les échanges de ce type sont les plus riches et les plus imagés.

    Il est fabuleux. Comme disait notre ami Romain, il n’aime pas que les lettres mais il aime aussi les mots.

    « Tu vois le coude, il est trop haut on dirait qu’il penche », parce qu’ on a des corps, on est des corps. 

    On ne peut pas faire sans, nous sommes des créatures qui sommes incarnées. 

    Moi, je conseille à tous les designers que je coache de regarder des making of de films et particulièrement ceux de Ridley Scott. 

    Parce que c'est une machine de travail qui s'entoure de gens extrêmement compétents, parce que lui, il torche des films à une vitesse incroyable. Par exemple, Prometheus.

    Les making of de films de science-fiction, où il y a des monstres, où il y a un monde imaginaire où il y a des monstres, Mate painting, où il y a des créatifs qui viennent fabriquer les cuillères, il y a tout à fabriquer.

  • Entre eux, ils doivent se mettre d'accord.
  • Pour qui ils designent
  • Dans quel monde
  • Quelle culture. 

    En fait, c'est un très bon terrain d’entrainement, parce que tu n’es pas en train de parler d'une application pour réserver un avion.

    Ça va beaucoup plus mobiliser des capacités d'imagination, de visualisation intérieure, et c'est ça qui est très, très important dans le design, c’est de pouvoir dire :

    «Écoutes, c'est pas un barba papa qu’on est en train de faire, c’est plus un Pokémon. “

    Si tu as les deux références, tu comprends qu’il y en a un qui est polymorphe, et l'autre qui peut être permutable, et tu as besoin d’aller chercher ces métaphores, ces analogies. 

    Parce que le cerveau humain fonctionne comme ça.

    Après, c’est la capacité à comprendre que plus tu vas te confronter au terrain et découvrir les autres, plus tu vas t’aider à te connaître toi-même.

    Cette connaissance de toi-même va t’aider déjà à comprendre tes biais, il y a des trucs qui t’énervent, il y a des constructions à toi qui viennent de ta famille, donc c’est un bon terrain pour pratiquer cette position.

    Être capable de comprendre que les gens ils sont là où ils sont parce que généralement, c’est le contexte autour d’eux qui font qui ils sont. 

    Le plus grand biais humain aujourd’hui, c’est l’erreur d’attribution fondamentale. Biais cognitifs sur lesquels sont construit le libéralisme, le capitalisme et la bourgeoisie. 

    La méritocratie, c'est l'idéologie qui va naître de ce biais.

    “C’est un biais où on va avoir tendance à suramplifier des raisons qui sont internes aux personnes, leur personnalité, c’est une espèce d’essence qui émanent d’eux, leur caractère, qui ils sont, on fait ce qu’on est. Et puis de complètement réduire l'impact du contexte extérieur.”

    Et à ce biais-là, il faut aller chercher Spinoza qui dit 

    « La liberté, c'est l'ignorance des causes qui nous déterminent. »

    Donc, c'est important d'apprendre à lire les rapports entre les gens comme aujourd'hui. Il y a une grande critique dans le HR de la fétichisation des skills, des compétences, comme s’ils étaient à l'intérieur des gens, comme des essences. 

    Alors que toute forme de compétence est toujours née d’une réalité de relation. 

    On est des créatures sociales. Ça veut dire que si tu parles, si toi et moi on parle le français, c’est que gamins, on nous a parlés Français et que plus tard, on a appris une langue, et ça nous a permis d’en apprendre une autre. 

    Donc si tu n’es pas socialisé au sens humain, c’est que tu es un Mowgli avec des loups.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Conseil – mieux collaborer avec les équipes

    Mieux collaborer avec les équipes c’est d'abord commencer par le cadrage:

  • Tu as tout le cadrage de façon collaborative dans l’ensemble où chacun vient poser ses objectifs, ses limites, et avoir tout un process de product design qui passe chaque étape du process avec l’étape de validation par l’ensemble des dev, l’équipe marketing, etc
  • Savoir à quel point tu peux justement déranger l’équipe marketing, les dev. Mais se mettre d’accord sur ça. Se mettre d’accord sur un process établi, qui est répétable sur l’ensemble des projets, et pas en termes de :
  • Il faut qu’on mette en place telle méthode, telle méthode, parce que parfois un projet, ces méthodes-là n’ont aucun sens. 

    Juste que chaque phase ait un état d’esprit et des objectifs, et que ce soient ces objectifs et ces états d’esprit qui se découlent ensuite en méthodes à l’intérieur. 

    Surtout de dire : "Là, il faut que untel soit au courant de ça, pour telle chose, il faut absolument qu’on collabore avec untel et untel. "

    Donc faire participer les gens sur tout le process de design et faire des livrables systématiquement actionnables. 

  • Arrêter les livrables très Powerpoint simplement, mais des livrables où tu as les PO, PM,Dev qui en prennent connaissance et qui puissent construire avec cette connaissance au fur et à mesure du workshop. 

    Par exemple:

  • “Donc, on est allés voir les utilisateurs, voilà, je vais distribuer à chacun des phrases-clés, des verbatims, On se les partage, on les distribue.” 
  • “Voilà les fiches utilisateurs, on construit ensemble leur journey. “

    Même si toi, en tant que user researcher tu connais le vrai journey, mais le faire co-construire par les personnes pour qu’elles se mettent à la place et qu'à la fin, ce n’est pas toi qui sois venu dire : 

    “Voilà le journey qu’il y a eu. "

    Mais plutôt :

    "En fonction de ce qu’on a entendu, de ce que je vous rapporte maintenant comme verbatim, co-construisons ensemble le journey / le persona”

    Moi en tant que researcher, je vais modifier ça ou ça pour vous mettre un peu sur la bonne piste, mais que chacun vienne co-construire le truc au fur et à mesure. “

    Et ça, il faut le faire à toutes les étapes. Que ce soit par exemple sur la restitution de research, que ce soit sur le how might we ou que ce soit sur l’idéation. 

    De prendre du temps aux gens, et ne pas avoir peur de leur prendre du temps.

    En fait, ne pas avoir peur d’être chiant avec les gens. 

    Ne pas avoir peur et se dire : 

    “Attends, le dev ils ont des trucs à faire, et je ne peux pas trop aller l’embêter, je ne vais pas mettre un workshop à ce moment-là. “

    Non, je pense qu’il faut vraiment en mettre. Il faut faire venir les gens et il faut qu’on arrête en tant que designer de présenter de façon très : 

  • “Voilà les résultats.” (Bon ça, il va falloir le faire de temps en temps.) 

    Mais éviter le trop descendant systématiquement, et impliquer les gens, leur poser des questions, les faire poser des questions, les faire réagir, les faire travailler. 

    Comme je disais, il faut que ce design collaboratif, soit 40% de notre taff, il soit porté par les autres. 

    C’est une espèce de co-design qu’on met en place, donc maintenant il y a aussi 6 to 1 et ce genre de méthodes. 

    Mais ça, il ne faut pas avoir peur de le faire, même si à la fin, on ne prend pas en compte ce que les gens ont communiqué. Le simple fait de les avoir intégrés, que les gens soient venus tirer des traits avec nous, ils savent qu’ils ont participé au design, que leurs contraintes et besoins ont été prises en compte.

    Si à la fin on voit ce qui en sorte qu’on se dit : 

    “Ça, c’est de la merde, je ne le prends pas en considération, “

    Hé bien c’est tout à fait OK, on peut le jeter. C’est notre travail.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Erreur: Dire que le design c’est la chasse gardée du designer.

    Une grosse erreur que j’ai aussi faîte, c’était il y a 6 ans chez Ooreka où il y avait un beau projet et j'avais encore ce truc de :

    “C’est moi qui suis en lead design, je sais ce qui doit être fait point de vue design.”

    On a vachement parlé sur le projet avec les PO, les PM, on était chauds. 

    Il y avait des personnes qui étaient essentielles dans le projet. Les rédacteurs, parce que Ooreka c’était majoritairement de la rédaction. (Le site maintenant il est mort. Il est encore là, mais en fait, il n’y a plus l’équipe qui bosse dessus, il n’y a quasiment plus personne. Ils laissent vivre le contenu. Mais c’était un très beau projet à l’époque.)

    Mon erreur ça a été de penser que le design n’était que l’affaire du designer et ne pas voir cet aspect, d’idéation et de collaboration. 

    C’était de dire : “Je suis designer, c’est mon affaire à moi. (le PO à la limite.) Vous vous êtes rédacteurs et votre tâche c’est de faire de la rédaction. “

    Je n’ai jamais mis en place cet aspect de :

    “On co-construit ensemble, les rédacteurs sont des designers, eux aussi ils ont leurs trucs à donner.” 

    On a trop poussé une version, dont nous étions super contents et il y a eu des clashs avec les rédacteurs. 

    On conservait un peu notre position un peu hautaine, dédaigneuse, tout le temps :

    “Rédigez quoi, vous êtes rédacteurs.” 

    En retour ils me disaient :

    “C’est pas comme ça que ça doit être fait.” 

    Et on a fait la sourde oreille. 

    Finalement, tout cela m’a ouvert les yeux et cet aspect de collaboration, de co-conception maintenant c’est essentiel. 

    Il faut vraiment mettre tout le monde à fond. Notre taff, c’est de demander toutes les idées et de prendre celles qui sont bonnes, d’un point de vue ergonomie, d’un point de vue design, et pas faire du consensus, mais arriver à amplifier la richesse de toutes les propositions et des besoins de chacun en un design qui surpasse les attentes.  Ne pas se dire que le designer c’est notre affaire à nous le design.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Se protéger et rester factuel avec les parties prenantes qui n'ont pas le temps !

    Une fois lors d’un projet j’ai eu la mauvaise expérience d’être avec des stakeholders qui ne prenaient pas le temps de suivre le projet et d’intéragir.

    La feature team devait avancer, les designers devaient avancer, et il y avait d'autres personnes qui mettaient la pression pour que ça avance.

    Si l’on disait à quelqu’un : non je n’avance pas. Politiquement parlant, ça n’allait pas passer. 

    Évidemment à la fin, on a eu le fameux : 

  • “Ah, mais c’est pas comme ça que je voyais le truc.” 

    Donc au dernier moment :

  • “Ça il faut changer, comme ci, ça il faut changer comme ça.”

    Si je devais éviter cette erreur de nouveau je ferais pro-activement ces actions pour me protéger:

  • Communiquer ce qu’on a compris du brief, s’assurer que notre compréhension est bien en phase avec le brief initial, s’assurer que ce brief a du sens point de vue du design et qu’il est en phase avec notre stratégie design.
  • Parler surtout aux autres qui ont aussi des communications avec ces stakeholders, soit les dev qui ont probablement aussi eu une redescente de besoins, les PO, les PM et les autres designers. 
  • Se construire ainsi aussi une représentation de: Qu’est-ce qui est attendu des personnes qui sont dans l’équipe. ?
  • Puis avancer, tenir la personne au courant régulièrement : 
  • Voilà où on en est
  • voilà où je suis
  • voilà ce que je fais
  • voilà où je vais
  • voilà le next step. 
  • Et toujours poser la question, j’ai besoin qu’on se voit. 

    Comme ça, Si la personne au bout de 3 mois elle réapparaît alors qu’elle zappé tous les workshops et dit :

    “Ben c’est pas comme ça que je voyais les choses,” 

    Tu peux répondre:

    “ Ben oui, mais nous on a avancé, tu peux voir sur tous les e-mails que je t’ai envoyés que je demande des créneaux donc maintenant le truc va sortir comme ça. S’il faut tout changer au dernier moment parce que tu es chief machin truc et que tu nous mets la pression, on va un petit peu changer la marge. “

    Mais aussi ne pas avoir peur de dire : 

    “C’est comme ça que ça va sortir ou alors ça ne sort pas, on annule le truc. Mais nous, nos horaires c’est 9-18h30, on ne travaille pas le week-end.”

    Bon là ce sont des conseils pour se protéger, mais il faut éviter d’en arriver là.

    Si une partie prenante n’a pas le temps il faut :

  • La tenir informée de l’avancée
  • Lui rappeler ses engagements, ses responsabilités, l’inviter aux workshops,
  • S’assurer avec des communications concises qu’elle a tout ce qui lui faut pour savoir où on en est.

    Moi il y a aussi un truc qui, en même temps, qui va dans les conseils que j’aurai bien aimé recevoir, qui est totalement lié à ça, c’est qu’on n’a pas dans la majorité des écoles de design ou formations qu’on a eues, c’est la négociation et la communication. 

    Comment tu fais pour communiquer, tout ce qui est assertivité, communication non violente, négociation. 

    Je trouve que tout ça, c’est essentiel et dans ce genre de cas, tu sais comment être factuel et dire que : 

    “Je comprends que tu ne sois pas satisfait, parce que ce n’étais pas ce que tu attendais, en revanche, comme tu peux le voir, il y a eu 8 mails de ma part et 4 Slack pour te demander des points que je n’ai pas eus, ou on avait besoin de ça pour avancer donc voilà maintenant l’état des choses. Comment peut-on faire toi et moi pour éviter que cela ne se reproduise la prochaine fois ?” 

    Puis surtout, ne pas prendre les choses personnellement.

    Un conseil également que j’ai eu d’un pote qui m’a dit : 

    “Le boulot, ce n’est que le boulot 

    Tu vois quand la personne en face elle a envie de continuer à monter les échelons, elle se met la pression, les meetings back to back, à travailler jusqu’à 23h, week-end machin et tout, c’est son truc. 

    À un moment, si elle s’énerve cette personne là parce qu’un truc s’est mal passé, je pense qu’il y a cette histoire de cadrage encore. Bien se protéger au fur et à mesure. 

    Donc si la personne fait du silence, nous on ne veut pas faire du silence, mais au contraire on continuer à faire du feed-back genre : 

    “Tiens, voilà en fait sur tel projet, voilà où j’en suis.” 

    La personne le sait et toi tu es protégé. Factuellement tu dis : 

    “Moi, ça fait trois mois que je te parle, toi tu ne me réponds pas, donc voilà où on en est. “ 

    Si la personne s’énerve ben tu vas le laisser s’énerver comme un spectacle finalement. Il faut être factuel et honnête et le truc avance tout seul.

    Je pense qu'il y a des solutions meilleures que celle là et je pense que des head of auraient des tricks très particuliers. (commentez si vous avez des REX)

    Je veux montrer qu’au bout d’un moment, il faut faire du bon boulot priorisé sur l’essentiel, prendre un peu de recul et se protéger avant tout.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Pour bien prioriser, il faut comprendre qui veut quoi

    Un deuxième conseil que j’aurais aimé que l’on me donne c’est de bien comprendre qui veut quoi autour de moi dans les personnes avec qui je bosse. 

    Par exemple, les autres leads , la boîte, mes designers: qui a besoin de quoi ? 

    Là où je priorise et là où je vois les pourcentages d’efforts à mettre, c’est en fonction de qu’est-ce que ces personnes veulent, et de quoi ils ont besoin. 

    Ainsi que de mon côté, ma team, moi personnellement, et le design: 

  • Quelles sont nos priorités ? 
  • Quelles est notre vision et nos ambitions ?
  • Je ne me focalise que là-dessus. 

    Si c'est un livrable sur un benchmark stratégique ou sur un atelier d’idéation qui va nous ouvrir la stratégie d’un produit, on peut sortir avec énormément d’idées et énormément d’insights. 

    Au lieu d’être exhaustif, je vais me dire : 

  • Les personnes avec qui on a mis en place ce job, eux, de quoi ils avaient besoin ? 
  • Quel était leur objectif ? 
  • Quelles étaient les objectifs de ce workshop ? 
  • Moi en tant que designer et lead, qu’est-ce que je veux communiquer comme image ? 

    Et en fait je ne me focalise que là-dessus, et je me rends compte qu’il y a énormément de petites choses où j’aurai pu me dire : 

    “Ça peut éventuellement être super intéressant, et ben je le zappe. Si ça peut juste être “éventuellement” intéressant, c’est que ce n'est pas dans un des objectifs de ces personnes, donc je ne vais pas perdre de temps là-dessus.” 

    Finalement, ça permet de passer un gros coup de râteau sur pas mal de choses. 

    Donc je fais un peu aussi de mapping interne: 

  • Qui est impliqué ?
  • Qu’est-ce qui est important pour eux ?
  • Qu’est-ce qui est important pour moi ? et je me focalise vraiment là-dessus. 

    Surtout, là où avant j’aurai pu me dire : Je vais présenter un truc bien abouti, je me rends compte que ça me desservait énormément de le faire.  Car présenter quelque chose de final à quelqu’un qui attend du collaboratif ça n’encourage pas la discussion. La personne n’a plus rien à dire, on passe à côté des échanges et de l’intelligence collective.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • A propos
    27 Abonnés
    Responsables · Postuler