Dans le cas présent, l’UX Designer va chercher à comprendre :

• Pour quelles raisons l’utilisateur va se connecter sur l’extranet.
• Dans quel(s) contexte(s) il va le faire.
• Quels résultats il attend de l’utilisation de l’extranet.
• Quels sont les obstacles qui pourraient l’empêcher de l’utiliser dans les meilleures conditions.

Il est primordial de comprendre que l’ADN de toute démarche dite UX est l’utilisateur.

On ne se dit pas : « Voici le produit que l’on souhaite développer, définissons comment il peut répondre aux besoins de ce segment de clientèle ? ». Mais plutôt : « Nous avons identifié ces besoins chez ce segment de clientèle, que faut-il développer pour y répondre de manière précise ? »

Dans l’optique de toujours pouvoir justifier une adéquation parfaite entre la proposition de valeur et les besoins exprimés, une démarche UX se doit d’intégrer l’utilisateur dans les grandes phases de développement d’un produit afin de réduire le risque et les incertitudes. Dès lors que l’on exprime des hypothèses quant à cette adéquation, on prend le temps de réaliser quelques entretiens avec les utilisateurs afin d’en vérifier l’exactitude.

Ça ne veut pas dire qu’on lui demande de faire le travail à notre place, simplement qu’on s’appuie sur une connaissance précise de ses besoins pour lui proposer une offre adaptée.

Un bon UX Designer se doit d’assumer les responsabilités suivantes :

• Il doit être le plus à même de comprendre et d’exprimer les besoins des utilisateurs.
• Il doit être capable de porter la vision stratégique du produit défendue par le Product Owner.
• Il doit être le garant de la vision d’ensemble de la proposition de valeur qui va au-delà du produit.
• Il doit garantir l’adéquation parfaite entre les solutions développées et celles attendues par l’utilisateur.

À quel moment l’UX Design peut-il intervenir dans le développement d’un projet SI ?

Cette question dépend des grandes étapes que l’on attribue au développement d’un projet SI. Dans l’exemple ci-dessous, partons du principe que nous décidons de lancer un nouveau projet à partir d’une feuille blanche.

u développement d’un produit. Si on considère (à juste titre) qu’il a la responsabilité de s’assurer que toutes les décisions prises concernant la proposition de valeur respectent les besoins de l’utilisateur, alors il doit travailler en collaboration avec toutes les équipes.

Comment l’UX Design doit-il s’intégrer dans les cérémonies agiles / SCRUM ?

Maintenant que l’on a conscience du rôle que peut / doit jouer un UX Designer au sein d’un projet SI, il vient la question du management et de la gestion des rôles. Comment intégrer ces compétences de manière pertinente dans les cérémonies agiles et notamment les organisations SCRUM ?

L’UX Designer a deux types de responsabilités : l’une étant de garder un droit de regard sur tout ce qui est fait pour garantir le strict respect des besoins utilisateurs, et l’autre est purement opérationnel pour fournir aux équipes les bons outils pour être productif.

Pour tenter de répondre à cette question, appuyons-nous sur le schéma ci-dessous que beaucoup d’entre vous ont certainement déjà vu.

Avant la constitution d’un premier Product Backlog par le Product Owner, l’UX Designer doit avoir réalisé un certain nombre de choses :

• Le recueil des besoins : Pour ce faire, il réalise une étude qualitative pour identifier précisément les besoins des utilisateurs. Concrètement il s’agit d’identifier toutes les informations nécessaires au design et au développement de la proposition de valeur dans son ensemble. Il ne se concentre pas sur les attributs démographiques et marketing qui cherchent à identifier « qui est » le client, mais plutôt sur les raisons qui pousseront celui-ci à utiliser la proposition de valeur dans un contexte précis. Les documents à fournir sont un rapport d’étude complet et détaillé + un persona qui servira de référent à toutes les équipes.
• Le persona : Pourquoi le persona, qui finalement n’est qu’un document, aurait-il une place aussi importante dans le process ci-dessus ? Tout simplement parce que ce qui compte n’est pas forcément le document en tant que tel mais ce que vous allez en faire ensuite. L’intérêt du persona réside dans le fait qu’il permet à toutes les équipes d’avoir un premier niveau d’information identique sur chaque segment de clientèle. Le rôle de l’UX Designer à ce stade est donc de communiquer ce persona et plus largement le résultat de son travail de recueil des besoins.
• Le plan de release : Même si le plan de release est une responsabilité portée par le Product Owner, il est indispensable que ces deux personnes travaillent ensemble pour obtenir un résultat qui a du sens. Durant la Release Strategy, l’objectif est de définir et préciser ce qui sera développé dans les prochains mois. Pour que le travail soit bien fait, il faut que ce plan puisse cibler les besoins les plus importants exprimés par les utilisateurs et soit en phase avec la vision stratégique de l’entreprise. À noter, pas de livrables UX particuliers à cette étape, c’est la responsabilité du Product Owner. L’UX Designer se doit juste de s’appuyer sur ses connaissances pour assister le PO.

Une fois le travail de release terminé nous arrivons donc à la constitution du premier « Product Backlog » qui devrait logiquement concerner la première release.

• Le product Backlog : Lors de ses études terrain, l’UX Designer ne s’est pas contenté de savoir quels étaient les besoins de l’utilisateur mais aussi et surtout d’identifier le meilleur moyen pour y répondre. Concrètement il doit aider le PO à transformer chaque besoin en solution. Si par exemple le besoin exprimé est de pouvoir contacter le SAV, l’UX Designer doit savoir s’il faut préférer le téléphone, le chat, l’email, etc. Pour aller plus loin, si le chat est la solution la plus adéquate, l’UX Designer doit être en mesure de savoir ce que l’utilisateur aime ou redoute, en utilisant ce genre d’outil.

Arrive maintenant le moment du Sprint Planning.

• Le Sprint Planning : En arrivant au Sprint Planning, l’UX Designer doit pouvoir aider le PO et éventuellement les équipes techniques à définir des specs fonctionnelles détaillées et des conditions d’acceptation précises. Ce document peut prendre plusieurs formes :

Ensuite pour ce qui est des autres cérémonies comme le grooming, le stand-up meeting, la review, la rétrospective, je pense que l’UX Designer doit être présent de façon systématique.

Vous le savez sans doute, SCRUM n’est pas une méthodologie propre que l’on respecte à la lettre mais davantage un état d’esprit et une logique de production. Il est donc impossible de vous dire ici « vous devriez inclure l’UX Designer de cette manière-là, à ce moment-là et pas autrement ».

D’autant plus que chaque UX Designer a un profil différent et peut apporter davantage de valeur sur certains sujets plutôt que sur d’autres.

Cependant il est important de retenir que quels que soient ses sujets de prédilection et ses appétences, le rôle premier de l’UX Designer est de garantir que le produit que vous êtes en train de développer répond parfaitement aux besoins des utilisateurs. Avoir une approche centrée utilisateur signifie avoir l’humilité́ de dire « je ne suis pas sûr que ce soit la meilleure solution, validons d’abord ces hypothèses avec les clients ».

Manquer d’humilité lorsque l’on développe un produit (digital ou non), c’est risquer de devenir le nouveau « Juicero »…

Antoine Devaux