Passé dans mon feed linkedin, ça peut être utile à certains. https://www.thequietachievr.com/courses#leadership
- merci! Utile
- Pas utile
- Pas sûr
Opthalmologie et vision
Management UX
Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, jobs et plus encore sur le sujet du management d'équipes UX.
- Posts Récents
- Tendances
- Plus populaire
- Filtrer ·
- Comment trouver le juste milieu entre guider et laisser de l'autonomie ? Comment donner du sens et intégrer un profil en reconversion qui ne comprends pas les enjeux, secteur et métier encore ? Motiver et valoriser ses compétences quand la personne n'a aucune ou peu et se forme toujours, souvent mal (ah, savoir filtrer entre bon et mauvais sur internet et divers boot camps). Tu es manager, comment parles tu a ton équipe de jeunes, accro aux notifications, qui souffre du syndrome de la déconcentration et a du mal avec l'endurance même pour un projet d'une semaine ? Deadline et cadre les étouffent, mais veulent des gros projets et titres encore plus longues? En reconversion ou début de carrière, des fois on choisit un métier qui nous épuise sans autant être bon. Manager, comment expliques tu a ton/ta nouvelle recrue qu'elle n'est pas au bon endroit ?
- Même problème
- Déjà posée plusieurs fois
- Pas sûr
Il est important d'éviter l'erreur de prendre trop de temps pour se séparer des personnes non performantes. Les échecs les plus importants que j'ai observés sont souvent liés à un manque de courage de la part des manager de se séparer des personnes qui ne sont pas à la hauteur de leur travail. En effet, ce sont toujours les erreurs humaines qui peuvent nuire à une entreprise. Parfois, je constate que des clients recrutent la mauvaise personne, même dans des domaines différents du mien, et cela me fait réaliser l'impact financier et énergétique que cela peut avoir sur l'entreprise.- merci! Utile
- Pas utile
- Pas sûr
J'ai commencé à diriger des équipes à la fin des années 90, et si je devais donner un conseil à un nouveau manager, ce serait de lire le livre intitulé "First 90 Days". Ce livre vous aidera à établir le cadre nécessaire pour gérer une équipe, car il existe une différence entre le leadership et la gestion.Un leader est celui qui dit :
"J'ai une échelle, nous allons grimper un mur et nous devons placer l'échelle à cet endroit précis car c'est le meilleur endroit."
Le gestionnaire, quant à lui, veillera à ce que tout le monde monte dans l'échelle au bon moment et dans le bon ordre.
Une expérience marquante que j'ai vécue à l'IMD m'a pris deux mois pour mettre en place une équipe qui a ensuite progressé, mais c'était un travail nécessaire.
Pour donner un peu de contexte, quand je suis arrivée, l'équipe était quelque peu délaissée. C'était une équipe de sept personnes qui faisait un peu de tout et n'importe quoi : un peu de design, un peu d'UI, un peu d'UX, alors qu'elle était supposé être d'une équipe de designers UX.
Ils avaient une manager qui n'était présente que de temps en temps (problèmes de santé), mais à mon avis, elle manquait également d'expérience en matière de gestion d'équipe.
Ce que j'ai appris sur le terrain, c'est que le rôle du manager ou du leader est de protéger son équipe des influences extérieures et de sensibiliser à l'impact de son équipe à l'externe.
Lorsque j'ai pris mes fonctions, j'ai cherché à comprendre le macrosystème dans lequel je m'insérais.
- L'une des premières choses à faire lorsque vous prenez les rênes d'une équipe, c'est de comprendre sa réputation au sein de l'écosystème.
- Ensuite, il y a un travail à faire en interne de l'équipe. C'est un travail qui prend du temps et qui va au-delà des problématiques professionnelles.
Vous devez d'abord évaluer rapidement les flux de travail et la dynamique de l'équipe :
- Est-ce que les membres de l'équipe s'entendent bien entre eux ?
- Qu'est-ce qu'ils font ensemble ?
Ensuite, vous prenez chaque personne individuellement et vous les laissez s'exprimer.
Vous leur dites : "Je suis là, je ne connais rien. Expliquez-moi comment les choses fonctionnent."
Il est important de se mettre dans une position de méconnaissance, ce qui est souvent le cas lorsque l'on arrive dans une entreprise, où l'on ne connaît pas la culture ni la manière dont les choses fonctionnent.
L'objectif est d'évaluer deux choses : comment les gens travaillent dans l'écosystème global et comment ils travaillent ensemble.
La dernière dimension qui est extrêmement importante, selon moi, est de comprendre ce que les gens attendent de leur travail. Sont-ils motivés par la passion, par l'argent ou par une absence d'alternative ?
Une fois que vous avez compris tout cela, la prochaine étape est de communiquer.
La communication est extrêmement importante. Vous ne devez jamais cacher à votre équipe ce que vous faites pour eux et ce que vous prévoyez de faire pour eux. Les considérations politiques au sein de l'écosystème ne sont pas leur préoccupation.
Cependant, vous devez constamment communiquer avec eux sur les impacts et les changements à venir. Si nécessaire, replacez les membres de l'équipe là où ils seront heureux et épanouis.
Je reviens souvent à l'idée des organigrammes, bien qu'ils aient leurs limites. En politique, les gens ont besoin d'organigrammes.
Mais dans la réalité, lorsque vous travaillez au sein d'une entreprise ou d'une agence, vous ne devriez pas dire : "Voici ce que nous devons faire, je vais trouver quelqu'un pour le faire."
Au contraire, vous devriez dire : "Qui dans mon équipe est capable de réaliser cela ?" Vous partez de l'intérieur et vous évaluez les compétences et les forces de votre équipe.
Ensuite, vous pouvez positionner votre équipe en interne en disant : "Voici ce que mon équipe est capable de faire pour vous, et voici comment nous allons le faire."
En adoptant cette approche, j'ai réussi à passer d'une équipe de sept personnes à une équipe de quatorze personnes en l'espace d'une année. J'ai réorganisé mon équipe UX en trois sections distinctes :
- une section dédiée à l'UX
- une équipe UI avec un product manager travaillant avec l'équipe IT
- un pôle de design visuel
Nous avons dû embaucher de nouvelles personnes car notre équipe était devenue très efficace dans la livraison de projets et nous avons commencé à recevoir de nombreuses demandes. Nous avons réalisé que nous avions d'excellents designers et que nous étions devenus très compétents, ce qui nous a permis de développer nos compétences. Beaucoup de managers et de leaders se concentrent souvent principalement sur la livraison des projets, mais il est essentiel de penser d'abord à l'équipe. Il vaut mieux travailler en priorité sur les personnes qui réaliseront la livraison plutôt que sur la livraison elle-même.
- merci! Utile
- Pas utile
- Pas sûr
- L'une des premières choses à faire lorsque vous prenez les rênes d'une équipe, c'est de comprendre sa réputation au sein de l'écosystème.
L'une des plus grandes erreurs que j'ai commises en tant que responsable d'équipe et experte UX a été de supposer que mes clients connaissaient déjà ce qu'était l'UX, sans rien préparer pour leur expliquer.
Nous pensions qu'ils étaient déjà familiers avec le concept, alors qu'en réalité, nous aurions dû partir du principe qu'ils ne le savaient pas et leur montrer comment nous pouvions les aider.
Ma vie aurait été bien plus facile si j'avais eu une brève présentation résumant :
- Ce que nous faisons,
- Comment nous le faisons, et
- Comment nous pouvons les accompagner sur ces sujets.
C'est toute la notion d'advocacy, et cela a des répercussions sur votre carrière :
- Les gens refusent de payer pour votre expertise
- Ils vous confondent avec d'autres professions
- Ils ne savent pas exactement où vous intervenez.
Au sein de l'IMD (Institut de Management et de Design), j'ai lancé une vaste campagne de sensibilisation, car j'ai réalisé que lorsque nous vendions l'UX à nos clients, ils le percevaient simplement comme du design. Depuis lors, l'une des choses les plus importantes que j'ai faites est de sensibiliser les gens à ce qu'est réellement le métier de l'UX, quelles sont les valeurs ajoutées, comment cela fonctionne et comment nous pouvons les impliquer.
Je me souviens avoir organisé une série de trois présentations de trente à quarante minutes chacune, où nous avons invité l'ensemble de l'IMD pour leur expliquer. Nous devions dissiper cette confusion persistante :
"Ah, vous faites du design ; ah, vous travaillez dans l'informatique ?"
Pour bien expliquer l'UX, il n'est pas nécessaire d'avoir des éléments concrets à montrer, mais plutôt de raconter une bonne histoire, en établissant des analogies avec leur travail quotidien.
Par exemple, l'un de nos clients internes qui rencontrait le plus de problèmes avec l'outil que nous utilisons actuellement était le secteur de la médiation (travaillant avec le public, notamment les enfants).
Ils étaient confrontés depuis plus de dix ans à un problème majeur : la mise à jour de leur CMS interne. À l'époque, il était largement utilisé et considéré comme la référence, mais aujourd'hui, il est devenu obsolète, lourd et extrêmement difficile à optimiser, ce qui freinait toute l'équipe.
Lorsque vous sensibilisez les gens, il est important de vous référer à ces problèmes spécifiques qui les affectent au quotidien, et de construire votre histoire autour de cela. Par exemple :
"En résolvant ce problème de cette manière, vous n'aurez plus à passer trois heures à recréer des données et à vous épuiser avec votre CMS."
L'objectif est de susciter leur intérêt en replaçant ces problèmes dans leur contexte quotidien. Il n'est pas nécessaire de se concentrer sur de grands enjeux, même de petites améliorations peuvent faire toute la différence.
- merci! Utile
- Pas utile
- Pas sûr
- Ce que nous faisons,
- Très bon rex derrière les dessous du titre de VP. https://www.media.thiga.co/le-jour-ou-jai-quitte-mon-poste-de-vp-pour-redevenir-designer Qui est-ce que ça encore rêvé ?
- merci! Utile
- Pas utile
- Pas sûr
- Très bon papier de Catalyst sur le leadership inclusif, et le pourquoi de la diversité dans vos équipes. https://www.catalyst.org/wp-content/uploads/2020/03/Getting-Real-About-Inclusive-Leadership-Report-2020update.pdf
- merci! Utile
- Pas utile
- Pas sûr
- Voici les principaux éléments que j'utilise au quotidien pour gérer mes équipes : Tout d'abord, je limite les sujets personnels dans mes échanges avec nos collaborateurs, en me concentrant principalement sur les aspects professionnels. Je m'efforce de rendre clair ce que nous sommes en train de faire actuellement, et comment cela peut bénéficier aux membres de mon équipe à l'avenir. Peu importe si l'équipe change demain, ou si certains membres ne sont plus présents, cela ne pose pas de problème. J'aide également nos collaborateurs à se projeter en leur expliquant, par exemple, comment ce qu'ils apprennent actuellement peut-être une étape vers une trajectoire de carrière fructueuse dans le domaine "produit". Je leur donne des conseils sur les formations disponibles en interne auxquelles ils pourraient participer. Je suis toujours convaincu q ue si j'aide nss collaborateurs à s'améliorer, nous ferons un plus long chemin ensemble. Après tout, il est inévitable que les individus aspirent au changement et à l'évolution. À un certain moment, lorsqu'une envie de changement se manifeste au sein de l'organisation pour une raison quelconque, on ne peut retenir personne. Il est simplement impossible d'aller contre le vent, tout comme on ne peut lutter contre l'eau. L'air circule.
- merci! Utile
- Pas utile
- Pas sûr
“L’UX et SAFe” est un sujet intéressant à maitriser. Lorsqu’on travaille avec les grandes entreprises, il y a de fortes chances qu'elles fonctionnent sur ce modèle.
Je ne pense pas avoir la solution parfaite, mais à force d’avoir travaillé dans ce mode et avec les retours de mon équipe chez Whitespace, je commence à trouver des astuces qui nous permettent de mieux fonctionner ensemble.
SAFe (Scaled Agile Framework), pour la parenthèse, est un cadre de travail qui permet de mettre en place une méthode de développement Agile à grande échelle dans une entreprise. Il fournit une structure pour coordonner et synchroniser les équipes travaillant sur des projets complexes et de grande envergure en utilisant des pratiques agiles telles que Scrum et Kanban.
C’est toute une orchestration de cadences, avec de grands rassemblements (PI planning), différents “streams”, un “release train” pour faire du “continuous delivery”, etc.
Ça part sur de bonnes bases. Le souci, comme d'habitude, et comme avec la méthode Agile en général, c'est que le rôle de l'UX n'est pas prévu à la base comme élément intégré.
Donc à chaque fois, c'est la même question:
- Comment est-ce qu'on vous intègre dans tout ça?
- Et vous faites quoi au juste?
Donc nous sommes obligés de définir notre rôle : on explique qu'o n va faire de la recherche, créer des wireframes et prototypes, les tester avec les utilisateurs, et collaborer étroitement avec les équipes durant le développement..
Cela demande beaucoup de travail d'éducation de notre côté pour obtenir l'acceptation, voir le respect, des autres membres du projet (ou programme).
Quels sont les défis et comment peut-on les gérer?
1.UN STREAM TRANSVERSE POUR LE DESIGN
Dans un projet récent, il nous a fallu beaucoup de discussions pour faire comprendre qu’il faut définir les éléments transverses avant de se lancer dans la conception et le développement des diffèrents produits (qui font partie d’une même famille). Donc :
- un concept de navigation globale,
- un Design System avec les éléments de base, les composants et templates, et
- des règles de contenu et d’interaction
sont essentiels pour ne pas se retrouver dans un chaos total.
Typiquement dans SAFe, cette idée existe pour l’architecture technique mais pas pour le design. Une solution est donc de se rapprocher du Solution Architect et s’intégrer dans le “Architectural Runway”.
2.LA MAITRISE DU VOCABULAIRE
Pour se faire comprendre, il est important d’utiliser le “language” SAFe et Agile, qui sont par ailleurs bien documentés.
Dans le contexte d’un large programme, nous avons pu rajouter le “usability testing” pour la “DoR” (Definition of Ready) d’une feature, et d’avoir un “UX QA” comme “DoD” (Definition of Done) pour une story - donc, en d’autres termes, injecter une approche UX dans un monde Agile.
3.TRAVAILLER 2-3 SPRINTS EN AMONT
Préparer les features et stories en amont nous permet de faire des mini tests agiles si nécessaire avec les utilisateurs et de faciliter la vie des développeurs, en leur donnant un cadre bien structuré. Cet argument est en général assez convaincant, il faut juste utiliser des mots clés comme “efficacité” et “qualité.”
- merci! Utile
- Pas utile
- Pas sûr
- merci! Utile
- Pas utile
- Pas sûr
Je ne suis pas vraiment fan des cas de design envoyés à domicile. Pourquoi ? Parce que tu les fais tout seul Je ne sais pas si quelqu'un t'a aidé Si tu as utilisé des ressources, etc. Le candidat peut prendre beaucoup plus de temps passé que demandé Personnellement, je préfère les cas de conception en direct, où on peut te regarder résoudre un défi. Ça peut sembler difficile, mais en réalité, c'est de plus en plus courant et beaucoup plus simple qu'on ne le pense. Chez Datadog, nous avons de nombreux entretiens et cette phase de défi de conception est réalisée deux fois dans le processus d'embauche. Ainsi, nous devrions être accrédité pour pouvoir mener des entretiens. Il y a un défi très spécifique, très technique, et il y a aussi un défi de création d'un prototype sur un tableau blanc pour un produit où tu dois proposer des améliorations. Nous leur demandons de ne rien préparer, juste de se présenter avec des questions. Ils peuvent travailler dans n'importe quel outil avec le designer qui va guider l'entretien côte à côte. Pour cet entretien, nous n'avons pas trop de questions spécifiques. Il faut juste s'assurer qu'à la fin, le candidat a un tableau blanc avec un premier sketch, même ci c’est très moche. En revanche, c'est très instructif, car on peut vraiment voir comment la personne réfléchit, comment elle trouve des solutions et relève le défi. Nous pouvons poser des questions et demander au candidat "pourquoi cette décision ?" ou “Je vois cela comme une contrainte - qu'est-ce que tu en penses ?” Observer comment le candidat travaille dans son fichier Observer les questions qu’il/elle pose Observer le processus design Il y a des candidats qui ont beaucoup d'idées, qui parlent beaucoup, mais qui ont du mal à les mettre en pratique dans l'outil. Cela permet également de détecter de belles surprises. Récemment, nous avons été surpris parce que le portfolio d'un candidat était magnifique. Cependant, lors d'un de ces exercices, il n'arrivait pas à mettre ses idées sur papier et il nous a avoué qu'il ne pourrait pas créer un produit de zéro à un sans la collaboration et l'aide d'autres designers.- merci! Utile
- Pas utile
- Pas sûr
- En tant que manager d'équipe, j'ai trouvé une astuce qui m'aide à rester organisé : j'utilise un document Google Docs où je prends régulièrement des notes, et je les partage également avec les membres de mon équipe. Cela nous permet d'écrire des notes sur des sujets passés ou des sujets à discuter dans la semaine. J'ai instauré des réunions individuelles hebdomadaires obligatoires avec chaque membre de mon équipe, ce qui est différent de ma précédente entreprise où ces réunions étaient irrégulières. Je prends ces réunions très au sérieux, en particulier avec mes collaborateurs directs. Pour moi, c'est essentiel de leur demander comment ils se sentent, comprendre leur blockages et comprendre leurs wins pour les célébrer L'idée du document Google Docs m'est venue l ors de mes visites chez le médecin. C'est un peu comme aller chez le médecin et avoir un suivi régulier. Parfois, je rentre chez le médecin et il me dit : "OK, mais la dernière fois que vous êtes venue, il y avait cela, etc." C'est assez détaillé. On oublie tous les détails, et il est important de prendre des notes pour ne pas oublier à long terme. Faire un check-in hebdomadaire avec chaque membre de mon équipe permet de mieux se souvenir de ce qui a été discuté précédemment. Par exemple, si un designer me dit : "La dernière fois, j'ai eu des problèmes sur ce projet", je sais que la semaine suivante, je pourrai demander : "Est-ce que ça va mieux pour XYZ ?"
- merci! Utile
- Pas utile
- Pas sûr
Changer de rôle et de changer de boîte en même temps est un double challenge mais cela me forçait à compter sur mon équipe et passer du temps à observer
Hier, j'ai fêté mes six mois en tant que manager.
Je pense que j’ai eu le double challenge de changer de rôle et de changer de boîte en même temps.
Dans ma tête, j’étais tellement convaincu qu’une réussite professionnelle ne veut pas dire devenir manager. Et quand j’ai eu l’opportunité, ça m’a troublé un peu parce que c’était un peu l’inverse de ce que je m’étais toujours dit.
Donc, lorsque je passais les entretiens, je me suis concentré à fond sur le changement de rôle et pas assez sur le changement de boite.
J’ai pris tellement de temps à réfléchir sur « Est-ce que c’est pour moi ou pas ? » que j’ai oublié que je changeais de boîte.
- Du coup, ce qui m’a pris un peu de temps au début, c’est l’adaptation à une nouvelle boîte. Chez Doctolib on est dans les 2000.
- Chez Getaround, même s’il y avait le rachat de Drivy en Europe, on n’avait pas fusionné des équipes, du coup, à Getaround Europe, on était autour de 100.
Juste la différence entre la taille des boîtes me prenait du temps à m’adapter et aussi, il faut commencer à créer des relations avec des collègues, ça peut être mon équipe mais aussi des gens d’une autre équipe et tout un nouveau produit à comprendre.
L’avantage de ce processus de découverte c’est que ça m’a obligé à ne pas micro-manager car tout était nouveau pour moi. (les nouveaux managers peuvent avoir une tendance de micro-manager certaines choses parce qu’ils ont du mal à lâcher le travail en tant que IC.)
Vu que c’était un nouveau produit avec de nouveaux utilisateurs dans un nouveau domaine ; j’ai dû poser des questions aux gens au sein de mon équipe parce que je ne captais rien par rapport à plein de trucs.
Avec un peu de recul, c’est peut être même une bonne chose de changer à la fois de rôle et de boîte en même temps.
Comme ça je dois vraiment compter sur les gens de mon équipe, et j’ai beaucoup de confiance en eux grâce à ça parce qu’ils connaissent mieux le produit que moi. Ils connaissent mieux certains types d’outils que moi, et ça aide beaucoup.
Au fond, je pense que le plus important pendant les premiers mois c’est de prendre le temps d’observer et de ne pas te lancer dedans trop vite.
Dès qu’on est vraiment onboardé et que l’on passe le cap de “En onboarding” à “ je suis opérationnel”, c’est hyper dur de revenir en arrière, voir impossible.
Après ce temps en observation, il faut avoir un impact, il faut montrer que je suis capable. Basé sur mon temps à observer, j’ai remarqué qu’on pourrait mieux structurer l’équipe, et comment on s’occupait des projets, sur quelles fonctionnalités travailler.
J’ai remarqué que l’équipe devrait être un peu plus structurée comme les product designers ou les PM. Eux, ils ont des domaines de produits qui sont assez réduits. En UX writing on est moins nombreux, du coup nous étions 100% transversaux. Mais en fait trop. Nous n’avions pas besoin d’être 100% transversaux non plus.
Le fait de prendre du temps à observer, j’ai pu identifier comment:
- Je pouvais avoir un impact, par rapport aux gens au sein de mon équipe pour mieux gérer le travail,
- Mais c’est aussi l’impact vis-à-vis des stakeholders parce que j’ai pu montrer que je ne s uis pas forcément là pour juste continuer à faire comme on a fait avant.
- Ça implique de proposer d’autres moyens pour que notre équipe puisse collaborer avec d’autres personnes dans la boîte.
Pour finir, je m’en rends compte aujourd’hui, mais en fait assez naturellement je réalise des cycles d’observations de ⅔ mois où à la fin je vais présenter quelque chose un peu structurel autour de la collaboration entre notre équipe et le reste du produit.
- merci! Utile
- Pas utile
- Pas sûr
- Du coup, ce qui m’a pris un peu de temps au début, c’est l’adaptation à une nouvelle boîte. Chez Doctolib on est dans les 2000.
- merci! Utile
- Pas utile
- Pas sûr
- merci! Utile
- Pas utile
- Pas sûr
- merci! Utile
- Pas utile
- Pas sûr
- merci! Utile
- Pas utile
- Pas sûr
- merci! Utile
- Pas utile
- Pas sûr
- merci! Utile
- Pas utile
- Pas sûr
- t might sound strange but the concept of Tachibana Shinsatsushitsu, a bar in Shinjuku-ku (1-1-8 Kabukicho), is a hospital waiting room. The staff wear nurse uniforms and the cocktails have hospital-related names. If you don’t understand Japanese, ask the nurse. But be warned, some of the names are rather racy! Also in the area is Bar Uramen (1-1-7 Kabukicho), a themed otaku bar (a Japanese term for people with obsessive interests, often in anime and manga). Here you’ll find a collection of electrical appliances and digital gadgets as well as retro games. Enjoy drinks with a game – they have roughly 600 FamiCom cassettes – while listening to some weirdly cool music.
- merci! Utile
- Pas utile
- Pas sûr
- Lien de l'épisode Morgane est Directrice de l’Experience Design chez Société Générale Corporate and Investment Banking (SGCIB). Alors qu’elle est en école de commerce, Morgane crée des jeux Flash et des sites web. En sortant d’école, elle rejoint la banque de financement et d’investissement de la Société Générale. D’abord en contact direct avec les clients, elle change de rôle pour travailler sur une plateforme de trading. Connaissant son appétence pour le design, les responsables de Morgane lui confient l’audit UX de la plateforme de la SGCIB. Une fois l’audit finalisé, Morgane se retrouve en charge d’améliorer l’expérience utilisateur de la plateforme et commence sa carrière dans le design.
Au cours du podcast, Morgane revient sur la croissance de son équipe et de son rôle. Elle nous explique comment tout a commencé grâce à la confiance de son responsable. Puis comment, en travaillant sur ses premiers projets elle a acquis la confiance d’autres personnes dans l’entreprise, jusqu’à devenir un point de passage obligé dans la création produit.
On aborde également la création de son équipe. Les profils qu’elle a dû recruter et les raisons de ces recrutements. Les profils qu’elle recherche désormais pour agrandir son équipe. Les méthodes qu’elle a mis en place pour attirer des potentiels, surtout en France où le secteur bancaire n’attire pas particulièrement. Morgane revient aussi la forte implication de son équipe dans le recrutement des nouveaux designers : ce sont eux qui font passer les premiers entretiens pour s’assurer que les candidats correspondent bien à l’esprit de l’équipe.
Aujourd’hui composée d’une vingtaine de designers répartie entre Londres et Paris, Morgane a dû mettre en place de nombreux rituels pour faciliter la communication et les interactions entre designers : Peer-design Design Critique Rédaction de notes sur chaque choix pris au cours d’un projet Meetup d’équipe annuel pour revoir l’ensemble des projets réalisés par l’équipe Dans cet épisode, Morgane nous parle également de ses missions en tant que Directrice de l’Experience Design : Pour chaque projet, trouver la bonne personne pour le designer sans impacter sur ses autres projets Faire adhérer à la vision Design les autres équipes Continuer de travailler sur ses projets. Car oui, Morgane continue de designer malgré son rôle ! Enfin on prend le temps de parler de la mise en place du Design System de la SGCIB et de la façon dont il est utilisé à travers les différentes entités de la Société Générale. Les ressources de l'épisodes Les liens Medium de Morgane Medium de la SGCIB Le site de Stéphanie Walter et sa sélection de livres Le Vortex
Les livres Org Design for Design Orgs de Kristin Skinner & Peter Merholz
Les autres épisodes de Design Journeys L’épisode #15 avec Audrey Hacq, Product Design Director @ OpenClassrooms
Pour contacter Morgane : LinkedIn Twitter
Pour soutenir le podcast : Inscris-toi à Design Journeys pour ne louper aucun épisode Mets 5 étoiles sur Apple Podcasts pour aider les autres designers à découvrir le podcast Rejoins-nous sur la page Tipeee du podcast- merci! Utile
- Pas utile
- Pas sûr
- Lien de l'épisode Mickaël est Design Director chez Doctolib. Passé par les Arts et Métiers, Mickaël se rend rapidement compte qu’il n’est pas fait pour le métier d’ingénieur. Après des expériences comme Consultant et chef de projet SIRH, il rejoint l’agence de communication comme chef de projet. Au cours de cette expérience, il découvre Axure - un logiciel de création de prototype - avec lequel il commence à faire des wireframes. Au cours de ses différentes expériences, Mickaël continue de découvrir et d’apprendre les compétence pour devenir Designer : la créativité chez BETC, l’UX Design chez Digitas, la présentation et l’argumentation en freelance ou encore le branding chez CBA Design. Il revient également sur la création de son réseau social pour rassembler tous les professionnels du digital : Digikaa. Il nous explique les erreurs qu’il a commises et quels en sont les apprentissages qu’il en retire et qui l’ont, une nouvelle fois, aider dans son parcours de Designer. Après un passage chez GE Digital, Mickaël rejoint Doctolib pour gérer l’équipe Product Design. Il revient sur la croissance rapide de son équipe : d’une personne en janvier 2018 à 22 (!!) personnes en juillet 2020. Il nous explique comment il a constitué son équipe entre les Users Researchers, les Product Designers et les Brand Designers. Il expose également les raisons pour lesquelles il les a recrutés. Un telle équipe implique également de l’organisation, c’est pour cela que Mickaël nous détaille les rituels de son équipe afin de garder une cohésion forte. Il revient également sur la façon dont son équipe interagit avec les équipes produits et techniques au sein de feature teams et la place des User Researchers et UX Writers dans cette organisation. Doctolib est un produit à destination des patients et des praticiens présents dans 2 pays : la France et l’Allemagne. Nous avons donc parlé de user research pour savoir comment Doctolib s’adapte à chacune de ses cibles et comment le produit se conforme aux spécifications culturelles de chacun des pays. On discute également de la démocratisation du design chez Doctolib qui est, pour Mickaël, un marathon. Deux éléments sont primordiaux : prouver qu’une modification design améliore le business et, surtout, communiquer sur ces améliorations auprès de tous. Enfin, Mickaël aborde toutes les étapes par lesquelles ils sont passés pour développer la nouvelle version de leur Design System : de la création des composants et des guidelines UX Writing à leur utilisation par l’équipe tech. -------------------------------------------------- 🔗 Les liens de l'épisode 🔗 Le site de Doctolib Le meme “How to create a MVP” Mickaël recrute : Product Designer (Paris) | User Researcher (Berlin) | UX Writer (Berlin)
📖Les livres dont on a parlé📖 La collection A Book Apart La liste de livres que Mickaël recommandent
🎥La vidéo dont on a parlé🎥 La vidéo de Steve Jobs
🎨Les épisodes de DESIGN SYSTEM que l’on a abordé🎨 L’épisode #6 avec Jeremy Barre de Getaround Europe (ex-Drivy) L’épisode #7 avec Marie Dehayes de Alan
Pour contacter Mickaël : LinkedIn -------------------------------------------------- ⭐️ Vous avez aimé cet épisode ⭐️ Abonnez-vous à DESIGN SYSTEM sur votre application de podcast préférée N'oubliez pas de mettre ⭐️⭐️⭐️⭐️⭐️ avec un petit commentaire sur Apple Podcasts Partagez ce podcast à toutes les personnes qui travaillent dans le Design et le Produit -------------------------------------------------- 💡Vous voulez m'aider à améliorer le podcast ? N'hésitez pas à me donner votre feedback 💡- merci! Utile
- Pas utile
- Pas sûr
- Lien de l'épisode Jeremy est Head of Product Design chez Getaround Europe (ex-Drivy). Après des études d’interaction designer, Jeremy devient Product Designer chez Youtube puis chez Facebook/Messenger dans la Silicon Valley. Il nous explique comment il a pu rejoindre ces entreprises juste à la sortie de ses études et la différence notable entre le Product Design aux Etats-Unis et en Europe, et plus particulièrement en France. Jeremy revient sur ces 3 années chez Drivy : de l’évangélisation du Design à la construction d’une équipe de 7 personnes. Il nous explique comment, dès son arrivée, il a mis en place des rituels pour démocratiser le design et expliquer sa valeur pour l’entreprise. Il détaille la mise en place de la cérémonie qu’il juge la plus importante : la design critique — cérémonie hebdomadaire au cours de laquelle une squad se retrouve pour discuter des maquettes afin de faire avancer un projet. On parle également de la démocratisation de la user research au sein de l’équipe produit pour identifier les difficultés rencontrées par les utilisateurs et pour tester les features mises en place. Jeremy revient aussi sur sujet dont il parle beaucoup : la relation Product Manager / Product Designer. On revient sur sa façon de voir les deux rôles, leurs interaction et façons de travailler ensemble ainsi que leur complémentarité de la découverte d’un problème à sa résolution. Jeremy aborde, avec beaucoup de recul, ses débuts en tant que manager avec la constitution d’une équipe de 7 designers. Il nous explique, étape par étape, les raisons pour lesquelles il a recruté chaque profil de son équipe. Il nous montre comment chacun membre de l’équipe permet aux autres de monter en compétence pour être toujours meilleur dans leur travail. On discute également de l’internationalisation de la recherche et de l’UX Writing ou encore de la création et l’implémentation d’un Design System. Enfin, on parle de la suite pour Jeremy. Après l’annonce de son départ de Getaround, il a décidé de rejoindre The Design Crew… -------------------------------------------------- 🔗 Les liens de l’épisode 🔗 Le site de Getaround Europe La conférence de Jeremy : Apprendre et évoluer en grandes entreprises, perspective d’un designer à Facebook Le retour d’expérience de Jeremy sur l’implémentation des réactions dans Messenger La conférence de Jeremy : Product Manager ou Product Designer Le double diamant L’épisode #5 de DESIGN SYSTEM avec Romain Briaux L’épisode #3 de DESIGN SYSTEM avec Alexandre Pidault
Pour contacter Jeremy : LinkedIn
-------------------------------------------------- ⭐️ Vous avez aimé cet épisode ⭐️ Abonnez-vous à DESIGN SYSTEM sur votre application de podcast préférée N’oubliez pas de mettre ⭐️⭐️⭐️⭐️⭐️ avec un petit commentaire sur Apple Podcasts Partagez ce podcast à toutes les personnes qui travaillent dans le Design et le Produit -------------------------------------------------- 💡Vous voulez m’aider à améliorer le podcast ? N’hésitez pas à me donner votre feedback 💡- merci! Utile
- Pas utile
- Pas sûr
- Lien de l'épisode Julien est Head of Design chez Ornikar, l'auto-école en ligne qui révolutionne le permis. Après être passé par Science Po Strasbourg, Julien décide de changer de voix et de se lancer dans le design. Après plusieurs stages en Product et Brand Design, en France et aux Etats-Unis, Julien devient Creative Director pour Digimind, puis Head of Design chez Ornikar où il manage 5 personnes. Ensemble nous revenons sur ce qui l'a poussé à faire du Design et ce qu'il a appris au cours de ses différents stages. Il nous explique comment il a été le premier designer d'une entreprise de plus de 20 ans qui compte plus de 200 personnes à travers le monde. Et enfin, il nous explique comme il est passé de premier Designer à Head of Design chez Ornikar, quels sont les défis quand on passe d'une équipe d'une seule personne à une équipe de 6, comment il challenge chaque jour son organisation pour être le meilleur et comment son équipe travaille pour sortir les meilleurs features pour ses utilisateurs. Merci à Julien de m'avoir fait confiance pour ce tout premier épisode et d'avoir jouer le jeu de l'interview. -------------------------------------------------- 🔗 Les liens de l'épisode 🔗 Découvrez le site d'Ornikar Julien recrute un Brand Designer On a aussi parlé de Populate Pour contacter Julien, suivez l'oiseau bleu -------------------------------------------------- ⭐️ Vous avez aimé cet épisode ⭐️ Abonnez-vous à DESIGN SYSTEM sur votre application de podcast préférée N'oubliez pas de mettre ⭐️⭐️⭐️⭐️⭐️ avec un petit commentaire sur Apple Podcasts Partagez ce podcast à toutes les personnes qui travaillent dans le Design et le Produit -------------------------------------------------- 💡Vous voulez m'aider à améliorer le podcast ? N'hésitez pas à me donner votre feedback 💡
- merci! Utile
- Pas utile
- Pas sûr
