UX designer, QA

Tim (c’est un pseudo, je prends celui de l’enchanteur dans Sacré Graal), Tim m’écrit : “Ça se fait de merger le rôle de UI designers et de QA ?”. Soit UI pour User Interface et moi j’ai mis UX dans mon titre, pour User experience, enfin QA pour Quality Assurance. Donc la question est : est-ce que quelqu’un qui a la responsabilité de l’interface utilisateur, toute l’apparence, (voire au-delà quand je reformule en parlant d’UX et donc de l’expérience), est-ce que cette personne peut aussi intervenir en aval pour valider que tout est OK (cela sous-entend notamment l’apparence).

Pourquoi je lie UI et UX ? C’est différent d’accord d’accord (faut pas les vexer), mais bon disons que pour ma proposition de réponse c’est pareil.

Tim complète :

  1. “J’aime bien la forme de responsabilisation que ça engage de la part de l’UI designer
  2. En termes de charge ça marche bien d’un point de vue projet car la charge d’UI design est surtout au début et de QA/testeur à la fin du projet
  3. Tout en transférant une (grosse) part de la responsabilité des tests unitaires aux devs (#TDD)

Par contre ça veut dire ne pas pouvoir partager les UI designers entre projets (et vu que c’est a priori une compétence rare…)”

Et oui, il est sérieux ce Tim, ils font du TDD (Test Driven Development).

Comment lui répondre ? Ce n’est jamais simple de répondre dans un environnement dit agile, car, par définition, c’est un environnement qui n’a pas de réponse toute faite. C’est bien ce qu’on lui reproche : de ne pas pouvoir appliquer des recettes à la lettre. Il faut se baser sur des principes et bien les adapter au contexte. À quels principes je ferais appel ici ?

Plusieurs choses me viennent. D’abord les UX ou les UI sont très proches à mes yeux des architectes (on parle de numérique, d’informatique ici). Ils ont les mêmes défauts et les mêmes qualités. Les qualités ? Ils ont besoin d’une vision d’ensemble, de voir le tout, pour imaginer un système cohérent. D’où le terme Design System qui n’est que l’expression de cela, ou les plans d’architectures informatiques. Ils ont donc une appétence à comprendre les enjeux, à avoir de la perspective. Ils ont le défaut de cette qualité : ils veulent tout prévoir trop tôt, trop précisément, et même si ce n’est pas le cas quand ils ont défini quelque chose difficile pour eux de lâcher prise et d’accepter de changer.

En début de produit (ou de projet) l’UI (je vais garder celui-ci pour Tim) envisage sa vision globale, et à travers une démarche que j’apprécierais il bâtit les détails de sa vision au fil de l’eau. Ou, mais j’apprécie beaucoup moins : il définit tout avant la moindre ligne de code, ce qui se révèlera une vraie perte de temps et un frein à la réflexion. L’UI que j’aime est aussi capable de pouvoir changer des éléments, de pouvoir basculer des parties de sa vision globale vers autre chose, pour cela il a fabriqué ses éléments avec cette possibilité en tête. Comme une architecture qui est assez souple pour pouvoir enlever un élément et le remplacer dans sa chaine.

Je reviens à la question de Tim. Je tique ou je note plusieurs éléments :

Où est la personne qui porte le produit (ce que l’on appelle product owner) dans sa description j’ai l’impression qu’il est manquant ? On peut décider que c’est la personne UI, mais alors elle devient avant toute chose “responsable du produit”, avant d’être UI. Et c’est ce que j’entends quand Tim parle de responsabilisation.

QA ? (faire les tests, généralement métiers, mais vraiment pas uniquement) : il y a plusieurs écoles qui s’affrontent sur le sujet. L’école à laquelle j’appartiens pense que c’est mieux de tester au fil de l’eau de façon robuste (donc de façon automatisée) beaucoup plus qu’à la fin (c’est plus coûteux). Mais on peut imaginer un moment de test en fin de cycle (et espérons que le cycle ne soit pas trop long): se pose alors une autre question, est-ce une équipe dédiée ou celle qui a fabriquée juste avant ? Idéalement on préfère celle qui a fabriqué juste avant, elle code mieux en sachant qu’elle devra corriger si elle laisse passer des choses.

Équilibrage de charge au début et en fin de projet, entre UI et QA. Justement ce n’est pas mon avis. Oui l’UI devra prendre un peu d’avance (mais vraiment pas beaucoup, et j’espère de façon itérative), et oui on finira par les tests quand tout sera développé. Mais dans ma façon de voir les choses, le mieux serait que l’UI fabrique au fil de l’eau les éléments et donc au même rythme que l’équipe, et que les tests soient réalisés soit au fil de l’eau aussi, et pour des tests de plus grandes envergures (couvertures fonctionnelles plus vastes), par série, au cours du projet. Donc cette histoire d’équilibrage pourrait cacher un piège.

Du TDD : c’est vraiment une bonne pratique de développement.

Je résume : Si la personne UI (responsable des interfaces utilisateurs) devient aussi celle qui valide en sortie, en fait elle devient effectivement probablement le responsable du produit, le product owner. Product owner dont le rôle est de définir ce que l’on veut et pourquoi et de valider si ce que l’on fabrique est bien ce qu’il voulait, ou qu’il y trouve assez de valeur pour dire “OK je prends”.

Un piège se cache dans cette bascule si Tim l’opère. La force des bonnes équipes nait du bon équilibre entre celui qui dit quoi et pourquoi, et ceux qui fabriquent (qui disent comment). Si celui qui dit “quoi” et “pourquoi” impose aussi le “comment” à ceux qui fabrique, il annihile leur engagement, leur responsabilisation, et donc vraiment la qualité de leur travail. Il y a plein de façons de cadrer ce comment car on ne fait pas n’importe comment bien sûr, mais si c’est au fil du projet par le responsable produit cela peut entrainer bien des inconvénients. Le piège est donc que l’UI s’il devient PO (product owner), va avoir un pied dedans (il fabrique les interfaces, le comment), et un pied dehors (il décide du quoi et pourquoi). Il faut juste le garder à l’esprit et à mon avis cela suffit pour que les conversations se déroulent bien.

Deuxième piège : de quels tests parle-t-on ? J’ai l’impression que Tim parle de tests du genre : l’apparence, et la fonctionnalité sont OK. Si on distingue deux grands ensembles : “ça marche bien” (cela fonctionne, il n’y a pas d’anomalie, quand on appuie sur un bouton quelque chose se déclenche), et “cela fait ce que je voulais” (quand j’appuie sur le bouton, c’est le bon calcul qui est réalisé de la bonne façon), on pourrait dire que les tests “ça marche” sont à la charge des développeurs, d’où le TDD, et les tests “j’ai bien ce que j’attendais” sont à la charge du PO. Dans ce cas sa stratégie (UI -> PO) fonctionne. Il ne faudra pas oublier probablement un travail plus accru des développeurs sur des tests automatisés au-delà de leur code. Charge ? Temps de réponse ? Tests fonctionnels automatisés bout en bout ? Mais tout dépend de l’amplitude du projet, ou du produit.

En tous cas deux clarifications : droits et devoirs du PO (aussi UI), et de l’équipe (dont l’UI fait partie). Et une clarification des tests et des différents responsables.

Et j’arrive à la même conclusion que lui. Habituellement les défauts des UI, UX peuvent être accentués parce que justement ils sont moins nombreux et moins disponibles que les développeurs. On trouve cela normal, car a) l’habitude de ne pas travailler de façon itérative et incrémentale est vraiment très ancrée b) on aime bien avoir de grands plans et de grands designs rationnels et faux pour se rassurer maladroitement au début. C’est une erreur à mes yeux, mais bon. Et ainsi oui si l’UI devient PO, il doit se focaliser sur un projet, un produit, car il aura une conversation constante avec tous les membres de l’équipe sur tout ce qui avance (ou pas) tous les jours. Ça va probablement le rendre bien meilleur UI/UX car, les pieds dans le cambouis, il trouvera beaucoup plus de raisons d’aménager, de ne pas anticiper, son travail de designer.

Quand je partage cela à Tim, il me répond :

“Donc en résumé :

Je lui précise que :

merci Tim.