Le designer UI/UX fait-il partie de l'équipe ? Design System - Scrum Life 57

[@ScrumLife]

Découvrez toute la communauté Scrum Life ! 👉 sl.run/IWS0d8

[@anne-lisegallon6546]

Très intéressant Jean-Pierre, comme toujours. Je suis confrontée idéologiquement par une Designer qui est accessoirement également ma soeur, sur la division du poste UX/UI. Elle considère qu'un designer doit faire les deux. En plus, j'ajouterai dans la video la particularité des features teams au sein d'organisation qui doivent aussi s'assurer de la cohérence des parcours en terme d'UX et de charte graphique. Ca dépasse tellement plus la vision "team". J'ajouterai enfin le rôle important dans les tests des Designers :)

[@ScrumLife]

Bonjour à votre soeur ! 😊 Concernant la différence entre UX et UI, si elle est capable de (bien) faire les deux, c'est tout à son honneur et bravo à elle ! Cela fait d'elle une "licorne" : des profils très difficiles à trouver tellement il y a de domaines et de compétences à maîtriser. Sur ce sujet, voici un article (parmi tant d'autres) qui propose une taxonomie des différents rôles UX/UI : uxdesign.cc/the-spectrum-of-digital-design-roles-in-2018-3286390a9966 Concernant la nécessité d'assurer une cohérence entre les équipes, c'est évidemment une des difficultés majeures mais à mon sens elle n'est absolument pas spécifique aux designers. Qu'il s'agisse des Product Owners, des testeurs ou des développeurs, chacun a un besoin d'assurer une dimension transverse du rôle pour le bien de l'entreprise. - Côté UX : assurer une cohérence des parcours - Côté UI : assurer une cohérence de la charte graphique - Côté développeur : assurer une cohérence sur comment le produit est construit et permettre sa maintenabilité à long terme - Coté testeur : assurer une cohérence sur le test des sujets qui dépassent une seule équipe, et pour maintenir sur le long test le patrimoine de test (type Gherkin) - Côté Product Owner : assurer une cohérence dans la stratégie produit au global Tout le monde y passe... Avec cependant pas toujours la même temporalité pour les conséquences de ne pas faire le nécessaire. Par exemple, une perte de cohérence niveau UX ou UI se verra immédiatement, alors qu'au niveau test cela se verra au moment de livrer et enfin au niveau développeur cela se verra lors de la maintenance du code. Tout cela pour dire que les Communauté de Pratiques sont essentielles, surtout si on a fait ce choix d'autonomiser les équipes : kzbin.info/www/bejne/iF6Wo4x_qKp-j9k Evidemment, tout cela c'est dans la situation où on a fait le choix de déléguer la construction du produit aux Feature Teams. À l'inverse on peut décider d'extraire toute cette dimension produit (ce qui inclut une bonne partie du travail d'UX) en dehors des équipes. Cela rejoint le débat sur le positionnement des rôles Product Owner/Product Manager : kzbin.info/www/bejne/poSsipqMbcSdb6c Vaut-il mieux extraite cette construction du produit et la garder en transverse ou au contraire l'intégrer dans les équipes ? Pour moi, cela ne fait aucun doute que de l'intégrer au sein des équipes est une meilleure option, pour prendre de meilleurs décisions tout en donnant plus de sens au travail des équipes. Mais je reconnais également que réussir à le faire a un coût, un coût qui peut être très important, aussi je comprend tout à fait qu'on puisse choisir de centraliser cette responsabilité. En ce sens cela rejoint un épisode récent qui mène cette réflexion à l'aide du modèle Agile Fluency : kzbin.info/www/bejne/oJW9cnp_pNqslZY Pour conclure sur le test, voici un article de Jean-Pierre Lambert qui fait le pont dans l'autre sens, qui rapproche le métier de testeur fonctionnel à celui d'UX designer : jp-lambert.me/is-the-ux-designer-the-future-of-functional-tester-c66961bc5935

[@lutaseb]

"on considère que c est le peintre du projet".... arrive le peintre avec son rouleau ;). Excellent!

[@okinawaokinawaokinawaokinawa]

Merci encore pour ces vidéos ! :)

[@yasserdloo3998]

Très intéressant

[@OlivierFarlotti]

J'ai proposé il y a quelques temps le terme DEVUX (analogie au DEVOPS) car les devs (notamment front) doivent s'accorder/discuter avec les Designer. Il y a plusieurs raisons à ça : 1) Le travail de design n'est pas seulement une série d'assets graphiques, mais bien une vraie conception basée sur une expertise qui s'appuie sur des connaissances liées au "look and feel" et a donc sa propre valeur ajoutée. Les devs sont donc aussi là pour transmettre cette valeur ajoutée via le code. 2) Le dev a des contraintes que le designer ne connait pas d'emblée et vice versa. Quand j'étais dev, j'ai déjà réceptionné des assets très compliqués à intégrer voire inexploitables. Nous avons fini par nous mettre d'accord sur comment les nous voulions produire les assets pour que l'intégration soit plus fluide et d'un autre côté le designer continue de faire de la conception mais avec un cadre orienté delivery. La discussion doit aussi arrivé tôt en amont quand il s'agit de construire l'interface via la librairie graphique d'un framework (par ex. Material UI pour REACT), car le coût d'adaptation de la librairie peut être exorbitant pour le peu de valeur que vont apporter certaines customisations. (Et dans ce cas, l'effort du designer à ne PAS produire de design doit être valoriser !) 3) Dans l'optique du feedback rapide, à l'intégration, quand l'interface commence à être utilisable, le point de vue du designer est super important pour adapter les changements nécessaires qui peuvent être opérés quand le dev s'aperçoit que qq chose ne fonctionne pas comme prévu (un problème de responsive par exemple). Ca peut être alors une discussion rapide à 3 avec le PO, le designer apportant alors son expertise UI/UX (il est référent sur l'expérience utilisateur) 4) Aimeriez vous en tant que dev, être vu comme un simple pisseur de code ? Pour les UI c'est pareil ! Tout comme les SCRUM Master sont aussi coach, les UI sont aussi UX, sauf que, du fait de leur rôle, leur focus UX est sur les interfaces, donc ils font un peu plus que de la peinture ;) - Cela dit, j'en ai connu, qui ne font et ne veulent faire que de la peinture... Comme tu l'as évoqué, le design system est un peu le Saint Graal de l'intégration continue ou alors juste une lubie... un peu comme l'AGILE quand on l'aborde uniquement comme outil. Idéalement, le design système fait parti intégrante de la transformation de l'entreprise car au delà du seul aspect graphique, il véhicule les valeurs de cette entreprise. Notamment via la tonalité adoptée il va influencer le choix des mots, le style de relation avec les clients etc... medium.com/@alanweibel/the-most-misunderstood-part-of-a-design-system-fba520c1d292 Tout ça pour dire que la mise en place d'un design system c'est compliqué si ça se construit ex nihilo sans l'abordé comme un projet à part entière et surtout comme une solution magique. Il vaut mieux donc avoir des designer/dev/PO avec un très bon niveau de collaboration qu'un pseudo design system bancale qu'on va subir et abandonné rapidement. Par ailleurs, pour rester dans le thème de l'article, il y a Atomic Design (atomicdesign.bradfrost.com/chapter-2/) qui peut aider à concilier découpage micro des US et UI (et du coup découpage des composants UI dans le code)

[@alexandrewattiez4318]

Hello Chez nous UI/UI c’était historiquement une collaboration des concepteurs fonctionnels et du développement au sein de l'équipe projet. Nous avons mis en place une bibliothèque de composants (charte graphique et ergonomique) en AngularJS et les dev du projet l'utilisait (ça ressemble au Design System dont tu parles). Cependant une absence de partage de ces bibliothèques fait que nous avons des produits aux looks et surtout aux socles techniques différents (VCL, PHP, AngularJs, Angular, ...) Pas de communauté de pratique donc, ce qui nous laisse un gros axe d'amélioration dans notre orga. Pour revenir au sujet, depuis un an, nous avons un vrai UI/UX qui a pour fonction de rénover et d'uniformiser nos applications mais la liste d'attente est longue avant de pouvoir bénéficier de ses conseils. Il est clairement hors de l'équipe car il participe au design de plusieurs applis mais l'idée directrice est qu'il fasse évoluer et qu'il standardise nos fameuses bibliothèques. Par contre on commence à assister aux premiers "frottements" entre lui et les concepteurs qui faisaient son boulot avant et les développeurs qui avaient pris l'habitude de dire que "non c'est pas possible, notre framework ne le permet pas !" et ben ça ne passe plus maintenant... Merci encore pour ton travail.

[@ScrumLife]

Un grand merci pour ce partage ! 👍

[@yvannllubet4203]

Salut, Peux tu m'expliquer quels sont les objectifs et rôles du poste de OPS et celui de Exploration (6:45)

[@ScrumLife]

Oui, je reconnais que ce n'est pas forcément très clair... L'exploration c'est typiquement le travail du testeur, le vrai travail de testeur, pas de la recette ou validation mais bel et bien explorer le produit voire le challenger. L'ops s'occupe des opérations, c'est à dire le serveur sur lequel tourne le logiciel. Selon la boîte on parle aussi d'exploitant.

[@davidrochelet8610]

On ne dit pas librairie mais bibliothèque, ou alors library 😋 Retour très intéressant sinon. Mais comment gérer un UI transverse à plusieurs équipes ? Cela fait beaucoup de daily, retro et autres ateliers pour lui

[@lorenzodelpais6962]

Pas mal, cette video. Je le reconnais.

[@ScrumLife]

Avez-vous des designers dans vos équipes ? Ou forment-ils une entité à part ? UI ? UX ?

[@nicolasgallotte3070]

Bonjour, j'ai bien aimé cette vidéo, une fois de plus. Chez nous le designer (UI principalement) est dans l'équipe. On est d'accord qu'il n'est pas en mesure d'estimer l'effort puisqu'il ne code pas ?

[@ScrumLife]

On n'est pas d'accord, cela dépend du niveau de maturité de l'équipe. Cf. l'épisode #52 sur les "T-shaped skills".

[@Jfmou]

Entité à part depuis quasiment 3 ans, et qui veut le rester. J'ai beaucoup de mal à leur donner envie d'essayer autre chose ! Voilà où nous en sommes : kzbin.info/www/bejne/oHuomJuZf7R6erM

[@ScrumLife]

Merci du partage !

[@jonhndoe8615]

Hello, bien enfin un agiliste qui parle d'Ux designer ! :) Lors de mes formations Agile même en demandant au formateur j'avais le droit à une espèce de mou de dédain sur la place de l'Ux dans l'équipe... Sinon nous travaillons comme vous l'indiquez, finalement une vision assez proche de celle d'un Jeff Patton qui place l'Ux avec l'équipe d'exploration. Et effectivment l'UI qui réalise de manière itérative. Par contre comme l'Ui réalise les interfaces sur la base des US ou items du PB il vote évidemment ! Il a les même contrainte qu'un front. Sinon cela n'a pas de sens. Il doit savoir évaluer ce qu'il va pouvoir faire pour atteindre les objectifs du sprint.