La démarche de conception centrée utilisateur s'appuie sur l'implication de celui-ci dans l'ensemble du projet informatique. Mais de quel utilisateur parle-ton ? Dans la mesure où l'application est destinée à des centaines voir des milliers d'utilisateurs, comment inclure cette multitude et incarner cette diversité ?
Bien que l'ergonomie logicielle et sa dénomination actualisée (UX design) aient actuellement le vent en poupe, je constate encore trop souvent une sous représentation des utilisateurs finaux dans les projets. Quand je cherche à rencontrer l'utilisateur final, la plupart du temps on me fait rencontrer ce que j'appelle un user proxy.
Qu'est-ce qu'un user proxy ?
<!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } -->
Commençons par définir ce qu'est un utilisateur final : c'est un utilisateur qui va réellement utiliser l'application, soit il utilise déjà une version précédente soit il va potentiellement l'utiliser dans l'avenir. Sa présence sera d'autant plus pertinente que, d'une part, il utilise l'application souvent et/ou longtemps et que, d'autre part, il utilise un maximum de fonctionnalités.
A l'inverse, un user proxy, c'est tout ce qui n'est pas un utilisateur final, c'est à dire qu'il n'utilisera pas ou peu l'application, à l'exception des tests auxquels il participera peut-être. Le user proxy prétend connaître les utilisateurs finaux et pouvoir s'exprimer en leur nom.
Les différents types de user proxy
Le client
Beaucoup de logiciels sont développés en sous traitance par des ESN. Il s’ensuit une relation contractuelle entre celui qui paye (le client) et celui qui réalise (l'ESN). Il y a rarement interaction directe avec les utilisateurs mais plutôt avec un chef de projet côté client, centré sur les notions de coûts/délais/périmètre.
Or, celui qui achète n'est pas toujours celui qui utilise ! Pour un logiciel de contrôle parental par exemple, les parents achètent le logiciel mais ne sont pas les utilisateurs principaux. Prendre en compte leurs besoins (contrôler l'accès aux sites sensibles, limiter les temps d'utilisation) ne dispense pas d'impliquer les enfants. Je connais des logiciels de contrôle parental qui ne permettent pas à l'enfant de connaître le temps restant ou qui ne le préviennent pas quand il va bientôt être écoulé (provoquant des crises inattendues lorsqu'il n'y a pas de sauvegarde automatique dans un jeu par exemple).
Ainsi, on peut rencontrer des user proxies au service marketing qui s'expriment sur une population d'acheteurs et non d'utilisateurs. Bien sûr les acheteurs sont conditionnés par les retours d'expérience des utilisateurs mais l'acheteur non utilisateur n'en reste pas moins un user proxy.
Le supérieur hiérarchique
Lorsque vous cherchez des utilisateurs, on vous proposera rarement le « grouillot de base » mais plutôt leurs supérieurs hiérarchiques. Si ceux-ci connaissent généralement la tâche prescrite, ce sont des users proxies qui masquent souvent la tâche réelle et les situations dégradées. Avec eux tout se passe conformément aux procédures et il vous présenteront éventuellement des utilisateurs finaux qui accréditeront cette thèse que j’appellerai les « bons éléments »
Il y a donc un biais formidable qui conduira bien souvent à idéaliser une population d'utilisateurs : soit c'est inconscient, soit c'est un choix assumé. Après tout, pourquoi se préoccuper dans le logiciel des comportements hors procédure ? A l’extrême, cela s'accompagnera d'une tendance à vouloir s'appuyer sur le projet informatique pour forcer un changement des comportements. On finit par s'écarter de la philosophie ergonomique, puisque c'est à l'utilisateur de s'adapter et non au dispositif technique.
Le responsable ou expert métier
Dans beaucoup de grosses structures, la maîtrise d’œuvre (R&D) et la maîtrise d'ouvrage (service métier), sont séparées dans deux entités distinctes. Dans ce genre d'organisation, le métier verra d'un très mauvaise œil, quelqu'un de la maîtrise d’œuvre (au hasard l'UX Designer) demander à rencontrer les utilisateurs finaux :
Comment cela, vous prétendez que je ne connais pas bien mes utilisateurs ?
Malheureusement, quand on gratte, on s’aperçoit que l'expert métier est bien souvent au siège de l'entreprise, éloigné des lieux d'utilisation. Quand il rencontre les utilisateurs, il va choisir les plus proches et l'échange sera assez bref.
Parfois l'expert métier est lui-même un ancien utilisateur et vous parlera de pratiques qui ont évoluées ou n'ont plus cours.
Le Product Owner (PO)
En tant que garant de la valeur pour les utilisateurs, le PO est probablement le moins « dangereux » des user proxy. En effet, il est difficile d'assurer cet objectif sans être directement en contact avec les utilisateurs finaux.
Pourtant, il arrive que le PO se concentre sur ses autres tâches : préparation des itérations, gestion de la backlog, spécification des user stories... Pris dans le feu de l'action, il en vient à négliger son rôle de représentant des utilisateurs. Ce rôle est pourtant crucial puisque en l'absence d'un UX Designer, il risque de devenir l'unique défenseur des utilisateurs au sein de l'équipe projet. De plus, il a les moyens d'agir puisque c'est lui qui définit le contenu des itérations.
L'UX designer
Aussi expérimenté et expert soit-t-il, l'UX designer n'utilisera pas non plus l'application (un audit ou quelques tests peut être). Le piège mortel est donc de céder au péché d'orgueil, en estimant qu'avec l'expérience, on peut prévoir et anticiper les réactions des utilisateurs. C'est d'autant plus dangereux que cette vision est valorisée par le reste de l'équipe. Après tout, pourquoi faire appel à un UX Designer s'il n'est pas capable de donner ses recommandations après avoir vu un écran 15 minutes ?
L'expérience m'ayant appris l'humilité, je n'ai pas honte d'admettre qu'après 15 ans de pratique, je reste parfois estomaqué des réactions et des comportements des utilisateurs lors d'un test. La conception centrée utilisateur reste une démarche expérimentale : on émets des hypothèses, on propose une solution puis on teste la solution pour valider ou pas les hypothèses.
Le développeur
In fine, c'est toujours le développeur qui a raison car c'est lui qui code ! L'expérience utilisateur est directement issue des lignes qu'ils alignent et ce n'est pas forcement ce qui a été spécifié. Son pouvoir est énorme car il peut à tout moment dégainer l'arme ultime :
On peut tout faire mais c'est plus cher !
Parfois (souvent?), le développeur devient un user proxy, lorsqu'il se met à la place de l'utilisateur. Cela part d'un bon sentiment mais le pousse à remettre en cause les spécifications et/ou maquettes que lui ont fourni la maîtrise d'ouvrage. J'encouragerai presque cette démarche qui démontre que le développeur n'est pas qu'un pisseur de code mais je ne donnerai pas pour autant de droit de veto.
Manquant d'informations sur les utilisateurs, le développeur va faire du « Comme pour moi ». Malheureusement, ce qui est bon pour un développeur l'ait rarement pour l'utilisateur final. De plus, étant juge et parti, le développeur sera enclin à privilégier les problématiques techniques aux problématiques ergonomiques.
Les proxys de user proxy
Le user proxy n'est pas toujours en contact direct avec les utilisateurs finaux. Parfois on s’aperçoit qu'un user proxy ne tient pas ses informations de première main, c'est à dire qu'il est en réalité en contact avec un autre user proxy. Dans certaines grandes structures par exemple, le PO récupère ses informations auprès du responsable métier. En creusant encore, on découvre que l'analyste et un prestataire de service et que les développements sont sous traités en Inde !
Si on se base sur le constat que l'expérience utilisateur est le produit des lignes de codes alignées par le développeur, il devient pertinent d'évaluer la distance qui sépare le développeur et l'utilisateur final, pendant la phase de réalisation.
Par exemple, dans une organisation agile, on peut avoir un product manager qui soit le seul à être en contact direct avec les utilisateurs.
Outre le fait, qu'il prétende incarner à lui seul, la multitude des utilisateurs, le PM ne va pas décrire le besoin directement au développeur mais passera par un PO. Dans cette organisation, la présence de deux niveaux entre le développeur et l'utilisateur final, augmente considérablement le risque d'une implémentation pas en phase avec le besoin exprimé.
On peut objecter qu'il est anormal que le PO ne soit pas en contact avec l'utilisateur final mais ce type d'organisation existe bel et bien. Que dire alors quand on a deux ou trois niveaux supplémentaires (cas d'un développement off-shore piloté par une ESN, cas d'un grand compte où l'AMOA et l'AMOE sont dans deux centres de profits distincts...) ?
Pourquoi avoir recours à des user proxy ?
Avant tout parce que c'est plus simple :
- Le user proxy est plus facilement accessible car il est sur place alors que les utilisateurs peuvent être éloignés ou dispersés géographiquement
- Le user proxy est souvent seul et c'est tellement plus facile de collaborer avec un interlocuteur unique
- C'est un effort considérable de se confronter au jugement des autres et on va avoir tendance à éviter de multiplier ces jugements
Il y a aussi souvent un parti pris idéologique, consistant à penser que ce qui est bien pour soi est nécessairement bien pour les autres. C'est sur cette hypothèse qu'on accepte la présence d'un unique représentant des utilisateurs. Dans ce mode de pensée, il y a un caractère absolu à l'expérience utilisateur, qui serait objectivement bonne au mauvaise, indépendamment de la variabilité de la population d'utilisateur cible.
A partir de là, il ne reste qu'à trouver un bon représentant, apte à juger de la qualité de l'expérience utilisateur. Souvent, il s'agira du responsable métier côté AMOA ou du PO. Parfois, et c'est plus grave, on laissera cette responsabilité à l'UX Designer, puisque c'est son domaine d'expertise. On a ainsi une population de soi disant UX designers qui, ultime compromission : conçoivent, maquettent, évaluent et testent des IHMs sans avoir vu l'ombre d'un utilisateur final !
Conclusion
Il ne s'agit pas d'en conclure qu'il ne faut pas faire intervenir les user proxies sur le projet. Au contraire, ils sont une source d'informations précieuse, surtout s'ils sont en contact direct avec l'utilisateur final. Cependant, on ne peut pas prétendre mettre en œuvre une véritable méthode de conception centrée utilisateurs qu'avec des users proxies. Il est crucial de choisir de vrais utilisateurs pour avoir un retour direct tout au long du projet.
Lorsqu'on évoque les méthodes centrées sur l'humain (Design thinking, Lean UX...), on est pas très clair sur qui participe aux ateliers: on parle d'équipe pluridisciplinaire, de team projet, d'équipe agile. A coup sur, il y aura des user proxies dans ces ateliers mais s'il n'y a que ça, il y a un vrai problème car on ne peut concevoir sur la seule introspection du besoin des autres.
S'il y a beaucoup d'obstacles à l'implication des vrais utilisateurs, on ne peut se prétendre UX Designer en acceptant une démarche centrée sur des users proxys. L'UX designer doit devenir le garant de participation des utilisateurs finaux tout au long du projet. Encore faut-il bien les choisir mais cela fera l'objet d'un prochain billet...
Quelques liens pour prolonger cette réflexion :
