Bonjour,
dans la théorie, je place l’UX Designer après avoir découpé un besoin de manière itérative et il intervient à chaque fois.
dans la réalité, mon UX Designer veut faire des maquettes qui sont une vue réaliste de ce qui doit être produit, elles sont testées au près des utilisateurs, validé par le métier, utilisé pour les US (genre un écran, une US…) et tout le monde y a accès.
du coup, quand le besoin arrive dans la Squad, c’est trop tard, on veut faire un atelier agile, Story Map, Event Storming / Event Modeling pour sortir des MMFs et un MVP.
Le métier ne comprend pas, il a vu des maquettes, il veut la maquette.
et l’UX Designer ne comprend pas pourquoi ça ne devrait pas fonctionner comme ça. qu’il faut changer d’état d’esprit et maquetter ce qui va être produit à court terme (la MMF)
dans l’image des itérations agiles, je vois bien l’UX designer le skate, puis la trottinette, puis le vélo, puis la voiture
si il design une Rolls, et qu’on lui propose un skate pour dans 15j, il ne peut pas comprendre, juste parce que le mode de fonctionnement de l’UX est tel et ce depuis toujours
on itère jusqu’à ce que le client est content de ce qu’on a produit et qu’on a encore du budget
en gros, on s’arrête souvent à la voiture ou la moto, pas la Rolls
Je trouve ça bien qu’il y ait des maquettes qui vise la solution idéale, ça donne une direction.
Votre difficulté réside dans le fait de faire adhérer les métiers à des livraisons partielles. Comme ils sont intimement persuadés que la solution imaginée répond à tous les besoins et que les contraintes de delivery des développeurs ne les concernent pas : en tant que métier, qu’est ce que j’ai à gagner d’être livré de la feature petit bout par petit bout ?
Du coup qu’est ce que tu peux leur apporter comme valeur à faire de livraisons partielles ?
oui, mais pas une maquette détaillée
c’est comme des plans d’une maison ou immeuble, t’as pas besoin de connaitre l’emplacement de toutes tes prises, la couleur de chaque mur avant même de te lancer itérativement, si ?
en tous cas, ce n’est pas ce que j’ai fait chez moi, et ça marche très bien
Est-ce que les maquettes présentées ressemblent plus à des wireframes ou est-ce qu’on est déjà à l’état de maquettes low-fidelity ?
Ce qui se cache derrière ma question, c’est de savoir quel niveau de feedback on cherche à prendre à l’instant T. Si le but est de prendre un retour sur une idée générale ou une intention, un wireframe peut suffire à se « projeter » sans expliciter au point que ce soit compris par les parties prenantes comme un engagement. Le bonus, c’est que le travail demandé est bien moindre que du lo-fi.
C’est une première piste qui permettrait de fluidifier un peu tout ça.
A côté de ça, je suis curieux de la posture qu’à la personne responsable de l’UX vis à vis de l’équipe de développement. Tu peux nous en dire plus à ce sujet ?
Exactement, je veux bien qu’on maquette rapidement pour avoir une idée
Là, les maquette sont de la haute fidélité, validé par le métier.
Le scrum master dit en 3 Amigos que la maquette n’est qune intention là ou l’UX dit de manière très directive que c’est ce qui DOIT etre implémenté.
Tu vois où cela me questionne dans la place de l’UX dans l’agile.
Je ne retrouve pas de manifeste UX officiel, l’UX serait selon lui, hors de l’agilité.
Mais du coup, tout est truqué, on ne pourra en mieux faire du cycle en V avec un delivery agile.
Du coup, le story map arrive après les maquettes HD, l’Event Storming /Event Modeling arriveraient après les maquettes HD, le 3Amigos sur une US qui n’est du coup qu’une description de l’écran (la solution) et pas le besoin. On perds le besoin.
L’agile meurt à petits feux
C’est assez paradoxal et malheureux parce que, pour le coup, on a un·e UX qui a une vision très pauvre des « utilisateurs » que sont l’équipe de développement.
Est-ce que cette personne préposée à l’UX aurait une très forte expertise en UI par hasard ? Si oui, il est possible que l’égo joue pour beaucoup: si la personne n’intervient que dans le champ du visuel, lui couper son « autorité » dans le domaine peut être perçu comme une atteinte à son expertise.
Si par contre son champs est plus large, elle peut alors se focaliser sur la partie observation, design de workflow, architecture de l’information, etc…
effectivement, il est responsable du Design System, ce que je ne déplore pas, ça normalise les choses, ça part pas dans tous les sens
ce qui m’embête, c’est que tout est déjà décrit en détail, et le projet ne fait que commencer, l’équipe se forme, veut faire un premier atelier agile, et là le métier ne comprends pas, ils ont déjà parlé de tout ça en détail, c’est même déjà validé et ils ont vu l’application, pourquoi on discute.
ça pipe les ateliers, ça pipe l’agilité, aucune possibilité de faire de l’itératif et incrémental autrement que de faire écran par écran, et on ne livre qu’une fois que tout est fait… cycle en V quoi
après, il y a clairement une question d’égo aussi, pourquoi un coach agile, donc des DEVs vient dire à un UX comment travailler, c’est fou
pourquoi le Scrum Master qui chez nous est soit DEV soit Testeur, devrait dire à l’UX comment ils travaillent depuis 10 ans, c’est dingue
J’avais fait tout un message mais au final hors sujet.
Dans scrum, quelque part on pourrait presque dire que l’increment tient lieu de maquette. Idéalement on livre même plusieurs incréments par sprint, donc effectivement, l’UX a raison de ne pas comprendre pourquoi maquetter ce qui va être produit à court terme. Autant développer directement et laisser les utilisateurs faire des retours de véritable tests d’utilisation.
En tout cas, son rôle semble actuellement plus tourné vers l’UI voir pire, un BA option UI (la maquette-as-a-spec), qu’un vrai rôle d’UX, plus tourné sur l’émotion utilisateur. D’où l’approche scrumfall et la réaction des interlocuteurs métier. Cette personne se demande certainement à quoi il va servir dans l’équipe s’il ne fait plus de maquette. D’un autre côté est-ce qu’on lui a communiqué des attentes claires sur le rôle attendu d’un UX ?
En parallèle on paye le discours « le SM n’est pas un chef de projet ». Mais un SM n’est pas un dev, c’est un expert en organisation. Il est donc légitime pour dire à un UX dans quel cadre son travail doit s’inscrire (Scrum) et pourquoi c’est cette méthode qui a été retenue (en espérant que ça soit une bonne raison). Idéalement, le SM doit avoir un vrai mandat, car pour être responsable du cadre méthodologique, il faut avoir le pouvoir de défendre ce cadre.
Quand bien même, un scrum est une équipe auto organisée, donc le deal de base c’est que tout le monde peut dire ce qu’il en pense, y compris les devs, et on décide ensuite collectivement en fonction des constats et non des idées préconçues. Si ce cadre ne convient pas à cette personne alors sa présence n’est tout simplement pas compatible avec la méthode.
La question est donc managériale, tant sur le cadre que sur la fonction de cette personne.
Pour le métier, d’expérience ça va être difficile à rattraper. Si vous arrivez à identifier une fonctionnalité qui a plus de risque que les autres, vous pourriez commencer par là. En donnant une version intermédiaire au métier, vous pourriez leur demander de faire des retours d’utilisation pour valider que ça leur semble pratique d’usage. S’ils ont des points d’achoppements qui nécessitent de revoir des éléments de la maquette, vous pourriez la décrédibiliser pour lui faire perdre son statut de spec aux yeux du métier.
c’est ce que j’essaie de pousser
mais la vision de l’UX, et ce n’est pas une personne isolée, c’est tout une équipe à convaincre, ils sont beaucoup dans la boite, est qu’il faut designer et itérer avec le métier jusqu’à ce que la maquette correspond entièrement à ce qu’il veut, donc en gros, c’est une conception très détaillée en HD, pixel perfect.
ce qui me gêne est qu’il n’y a plus d’innovation, plus le côté Négociable du besoin, et ça, je vais le challenger, ça commence à faire du bruit, les chefs s’en mêlent, donc une décision risque d’arriver
j’ai cherché un peu dans la littérature, et je trouve des choses autour de Lean UX et Agile UX, je ne connais pas, je sas si quelqu’un.e aurait une expérience dans le domaine à nous faire partager
je pense que tu touches la zone sensible, oui, j’ai remonté mes attentes sur le rôle, mais qui sommes nous pour dire à un UX, qui sait comment faire, expert dans son domaine, ce qu’on attends de lui
c’est un sujet compliqué et politique pour le coup chez nous
je n’ai jamais eu ce sujet ailleurs, car l’UX faisait partie de l’équipe de DEV et designer avec nous, ce sur quoi on code, et seulement quand on en avait besoin, car le Design System permet de faire pleins de choses juste en tant que Dev front
Un scrum master, un manager, un leader, un chef … appelle ça comme tu veux.
Attention, le sujet ce n’est pas de l’ingérence technique (« faire de l’UX de la manière A ou B ») mais bien un problème de positionnement métier. Plus haut, je disais que « la question est donc managériale ». Je veux dire par là qu’il faut donc demander en premier lieu à ces personnes si elles veulent faire du graphisme (technique) ou faire de l’UX (marketing). Car si on a des attentes d’un rôle d’UX à des gens qui veulent faire du graphisme ou inversement, on a un gros problème organisationnel. Un peu comme si on demandait à un expert en tests de faire de l’administration de base de données.
Le graphisme, c’est un domaine d’expertise technique, qui est certainement très utile au projet, mais qui comme toute expertise technique va dans l’équipe de dev au même titre que les codeurs, les testeurs, les exploitants, etc …
Un UX designer c’est un métier à 80% marketing, plus proche d’un PO que d’un dev. C’est quelqu’un qui est centré sur l’expérience utilisateur. La majeure partie de la démarche c’est observer les utilisateurs, se mettre à leur place dans leur utilisation de l’application pour identifier quand le produit devient un obstacle, proposer des solutions pour fluidifier l’usage, et mesurer l’impact des propositions. Un véritable UX designer se jette sur Scrum, car voilà enfin une méthode qui permet d’avoir des retours d’expérience en utilisation réelle, sur un vrai produit, avec des vrais morceaux d’utilisateurs dedans ! Quand tu as gouté à ça, impossible de revenir à de la négociation insipide avec des BA pleins de préjugés, qui discutaillent du sexe des anges pendant des heures tout en ratant le sujet qui tient vraiment à cœur aux utilisateurs.
Un UX designer peut se positionner en équipe de dev ou en partie-prenante, c’est selon. Mais il est soit l’un soit l’autre. Si c’est une partie prenante, alors il aide le PO dans la rédaction des PBI et vous n’avez pas à le gérer. Le risque c’est que, vu le profil, vous basculiez progressivement d’une approche produit à une logique software à la demande (que je surnomme affectueusement « SALADE »). Ou alors il faut un PO très solide pour canaliser la personne. S’il est dans l’équipe de dev (que ça soit en UX ou en UI d’ailleurs), alors ses activités sont dans le sprint au même titre que le codage ou les tests.
Et là le reste de l’équipe est légitime à critiquer puisqu’on est auto-organisé.
Et en particulier le SM est légitime à critiquer puisque responsable de garantir le cadre Scrum.
Car qui dit équipe dit règles de fonctionnement, certaines négociables et d’autres non.
Les personnes n’acceptant pas les règles du jeu n’ont pas leur place dans l’équipe : dura lex, sed lex.