Business analysis et UX design
Une complémentarité à valoriser

Du 18 août au 17 septembre 2019 nous vous avions conviés à participer à un exercice de tri de cartes en ligne. Son objectif était de répartir 42 disciplines relatives au processus d’ingénierie des besoins utilisateurs entre les rôles de business analyst (BA) et UX designer (UX).
Nous vous proposons maintenant notre lecture des résultats obtenus.
Le jeu
Le billet proposé sur LinkedIn : voir ici
Le tri de cartes était de type fermé, c’est à dire présentant des catégories fixées à l’avance :
- Affectation au rôle BA
- Affectation au rôle UX
- Affectation à l’un ou l’autre
- La carte ne me parle pas
Nous avons utilisé le site Proven By Users pour héberger notre jeu en ligne.
Les sources documentaires exploitées :
- “BA UX” de Challis Hodge [01] et “Business Analysis and User Experience” d’Allison Bloodworth [02] qui proposent une répartition des tâches entre BA et UX.
- Nous avons extrait la liste des disciplines BA UX de [02] et du support
“UX + BA: Working Together in Harmony” de Jacklyn Burgan [03]
Afin de ne pas biaiser (trop) les résultats, ces sources n’avaient pas été révélées.
L‘objectif
Notre attendu vis à vis de ce jeu était de pouvoir apprécier dans quelle mesure la répartition des activités de l’ingénierie des besoins entre BA et UX proposée par [01] et [02] était partagée par les professionnels, cette distribution reconnaissant à l’UX un périmètre de responsabilité très large depuis la recherche UX jusqu’au design d’interaction.
Cette perspective de l’UX “à large spectre” — qui a notre assentiment — semble contrarier celle où la recherche utilisateur dans la phase d’expression des besoins est encore majoritairement perçue comme une tâche incombant à l’analyste métier, ce qui laisse penser que dans un cycle de développement logiciel le BA précède l’UX, ce dernier restant limité à la conception des interfaces. Certains auteurs de renom semblent accréditer cette orientation :
“L’analyste métier n’est pas le concepteur d’expérience, mais il a une compréhension des fonctionnalités essentielles de l’entreprise et des exigences non fonctionnelles. Ces connaissances, ainsi que les personas générés et les observations des utilisateurs réalisées au cours des activités liées aux exigences, constituent les inputs au design d’expérience.”
(S. et J. Robertson) [04]
Oui, l’analyse et la conception sont bien à dissocier, mais quelles leçons en retirer en ce qui concerne la recherche utilisateur BA UX : complémentarité, collaboration … ?
Les résultats
La participation
Nous remercions chaleureusement tous les participants et les nombreux internautes dont l’activité nous a permis de pouvoir exploiter plus de 60 retours.

La présentation des résultats
- Nous avons traduit les libellés courts tels que proposés par [02]. La distinction entre certaines disciplines n’était pas évidente sans explication complémentaire. Une marge d’interprétation était donc possible comme dans le cas de “creates functional specification document” par rapport à “feature writing” ou encore “conception des interfaces” par rapport à “conception des interactions”.
- Les tableaux suivants rendent compte des tris effectués. A gauche les totaux des colonnes ‘BA’ et ‘UX’ comptabilisent les résultats de l’ensemble des participants, à droite ils se limitent aux résultats des seuls participants s’étant identifiés UX ou UI.
- Lorsque la somme des valeurs dans les colonnes ‘BA’ et ‘UX’ ne donne pas 100, cela signifie que la carte a aussi été placée dans la catégorie ‘La carte ne me parle pas’ par certains participants.
- Le total de chaque carte dans la catégorie ‘Affectation à l’un ou l’autre’ a été ajouté pour moitié à ses résultats dans les catégories ‘Affectation au rôle BA’ et ‘Affectation au rôle UX’.

La prochaine figure rappelle tout d’abord la répartition des disciplines proposée par l’article [03] qui proposait par ailleurs des passages de témoin entre les activités du BA et celles de l’UX.

Nous avons ensuite reporté sur ce schéma les résultats non filtrés de notre card sorting sous la forme de points de couleur verte en respectant les règles suivantes:
- des points ont été mis sur toute carte discipline dont l’affection a été confirmée par les participants au card sorting ;
- le nombre de pastilles traduit le poids du vote. Par exemple pour la discipline “Architecture de l’information” qui porte 1 point dans la colonne ‘UX’ cela veut dire qu’elle a été reconnue comme relevant de la responsabilité de l’UX mais que l’écart en nombre de votes avec le BA a été faible ‘se reporter au tableau des résultats). A contrario, avec 3 points, “la collecte des besoins métier” ressort quasi unanimement comme une discipline de l’analyste métier ;
- une carte qui demeure sur fond rose signifie que le couple (rôle / discipline) proposé dans le classement [03] n’a pas été confirmé par le tri de cartes : le vote a associé la discipline à l’autre rôle.
L‘interprétation des données
Si on regarde notre distribution de pastilles de couleur verte, nous pouvons d’abord constater qu’à quelques exceptions près notre jeu en ligne a confirmé la proposition faite par [03] quant à la distribution des disciplines entre le business analyst et l’UX designer.
Comment expliquer les quelques écarts ?
D’abord, comme indiqué, ils peuvent se comprendre par l’ambiguïté de certains libellés :
- “Identify Opportunities for improvement” : l’activité était proposée comme une tâche ‘BA’ (amélioration d’un processus métier) mais à la lecture on pouvait tout aussi bien penser à une amélioration du produit et la classer du côté ‘UX’ ;
- “Presentation and speaking” n’étant pas un libellé auto-porteur, on pouvait penser à des activités de revue du produit (plutôt une charge UX) ou à des tâches de reporting projet. Les participants ont laissé au BA les tâches de gestion de projet.
Les écarts se réduisent encore lorsque l’on prend uniquement les tris effectués par les participants UX/UI designers. Les activités suivantes basculent alors du côté ‘UX’ :
- “Creation and administering of tests”
- “Presentation and speaking”
- “Communication to stakeholders”
- “Terminology creation”
- “Feature writing”
Ces résultats montrent qu’aujourd’hui l’UX design reste méconnue, limitée au design d’interaction alors que son périmètre recouvre aussi la recherche utilisateur.
Une telle restriction, lorsqu’elle se retrouve sur le terrain opérationnel d’un projet, limite la richesse que l’on peut attendre d’une collaboration entre BA et UX, à savoir :
- Pouvoir éclairer le design d’interaction et globalement la phase de conception en prenant en compte l’ensemble des dimensions qui fondent l’expérience utilisateur que l’on ne doit surtout pas cantonner à un alignement entre besoins métier et exigences utilisateur : il faut intégrer l’usage, l’apprentissage et les émotions … pour ne citer que ces aspects ;
- Mieux challenger et mettre à l’épreuve les hypothèses en vigueur sur les attendus des utilisateurs et ceci très tôt dans un projet ;
- Améliorer le fit entre la déclinaison des besoins métier, ce que fait très bien le BA, et les exigences qui émergent de la compréhension des scénarios d’usage dans leur contexte, ce que fait très bien l’UX.
Pour conclure, retenons que “BA UX” est avant tout une collaboration à mettre en oeuvre sur l’ensemble du cycle de développement d’un produit / service. L’UX designer doit pour cela pouvoir intégrer l’équipe projet et l’accompagner depuis les études jusqu’à la fourniture du produit.
Références
[01] BA UX, Challis Hodge, 2012
[02] Business Analysis and User Experience, Allison Bloodworth et al., 2011
[03] UX + BA: Working Together in Harmony, Jacklyn Burgan, 2014
[04] [Robertson et Robertson, 2012] Suzanne Robertson, James Robertson, « Mastering the Requirements Process: Getting Requirements Right »,
3rd edition, Addison-Wesley, 2012
