Mettez de l’UX dans votre gestion de projet.

Quand j’ai décidé de recher­cher un poste un agence en sortant de ma forma­tion, j’étais parti­cu­liè­re­ment inté­rêssé par la réso­lu­tion de problèmes variés sur des projets diffé­rents. Mais comme pour tout passage de la théo­rie à la pratique, il y a la réalité. Et je me suis fina­le­ment retrouvé à essayer de résoudre la prin­ci­pale problé­ma­tique rencon­trée par les agences : la gestion de projet.

---

Après avoir passé plusieurs mois à voir mes recherches et réflexions igno­rées, j’ai décidé de prendre le taureau par le cornes (le chef de projet), et de recher­cher une solu­tion viable pour satis­faire toutes les parties—­client, pres­ta­taire, et utili­sa­teurs. J’ai d’ailleurs présenté ce sujet au cours d’un apéro web, dont vous pouvez consul­ter les slides. Cet article est un résumé de la confé­rence présen­tée ce jour là.

Des problèmes, mais pas les bons.

Les agences de commu­ni­ca­tion ont pour rôle d’éta­blir une stra­té­gie et propo­ser des solu­tions en accord avec les objec­tifs clients. Mais ce proces­sus, souvent sous-traité, est lour­de­ment chargé de problé­ma­tiques liées à la commu­ni­ca­tion entre les diffé­rentes parties.

La frus­tra­tion des équipes est une notion assez courante en agence. Là où des points de vus alter­na­tifs sont une valeur ajou­tée, ils ne sont géné­ra­le­ment pas pris en compte. Et on se retrouve à faire appel à eux que dans une optique de produc­tion (comme à l’usine), et très peu dans un cadre de conseils. Or s’il y a bien un domaine dans lequel j’ai pu obser­ver de réels passion­nés par leur travail, c’est bien le Web. D’où la frus­tra­tion des inter­ve­nants à se retrou­ver limi­tés par les retours client. D’ailleurs, si vous vous inté­rês­sez à la problé­ma­tique du turno­ver en agence, je vous conseille de commen­cer par là …

Ensuite, les retards dans les projets sont au final assez nombreux. On parle géné­ra­le­ment de quelques jours/semaines, mais il arrive parfois qu’un projet se retrouve retardé de plusieurs mois. Qu’il sagisse du client qui envi­sage son projet d’une manière, ou du chef de projet qui veut appliquer sa vision, ou encore du pres­ta­taire qui fait appel à son exper­tise (ou à ses goûts), il y en a toujours un qui contre­dira les autres. Et cette pratique—que dis-je, ce sport natio­nal—ne fait qu’en­gen­drer des retards sur le dérou­le­ment du projet.

Enfin, il y a l’éter­nelle insa­tis­fac­tion client. En fonc­tion des projets, elle peut être liée à divers choses. Pour commen­cer il y a l’égo des diffé­rents inter­ve­nants. Chacun y va de sa vision, de son expé­rience. Mais encore une fois, c’est un débat sans fin où le gagnant est au final le plus gros poids dans la balance : le client ! On ne fait donc que retar­der l’iné­vi­table et on génère une mauvaise expé­rience de pres­ta­tion auprès du client. D’autre part, lors d’un brief avec le client, des objec­tifs sont déter­mi­nés, et la mission de l’agence est de conce­voir un outil répon­dant à ces objec­tifs. Sauf qu’en prenant en compte les diffé­rents avis person­nels (client et pres­ta­taires), on omet tota­le­ment l’im­pact de nos déci­sions sur la vali­da­tion des objec­tifs.

La seule chose dont je suis certain ici, c’est qu’il ne s’agit pas des problèmes auxquels je pensais avoir à faire en travaillant en agence. Oui, il fût un temps où je vivais dans le monde des bisou­nours. Puis je me suis inté­rêssé au sujet …

À la recherche d’une solu­tion.

Bien heureu­se­menent, ces problé­ma­tiques étant obser­vables depuis plusieurs années, des solu­tions ont été envi­sa­gées et mises en place dans les agences.

Faire l’au­truche est la plus courante. Ce n’est pas vrai­ment une solu­tion, mais c’est ce qui est le plus souvent mis en place. Après tout, si on satis­fait les désirs du client, il ne peut pas nous en vouloir. Enfin… Il paraît ! « Donnez lui la main, lais­sez-y le bras ».

Augmen­ter dras­tique­ment ses tarifs pour prévoir les nombreux retards des projets réali­sés est égale­ment l’une des solu­tions envi­sa­gées. La survie de l’agence étant en jeu, cette prévi­sion lui permet de garder la tête hors de l’eau, mais ne résout pas les problé­ma­tiques d’in­sa­tis­fac­tion client, de retards ni de frus­tra­tion des équipes projet.

Appliquer une nouvelle métho­do­lo­gie desti­née à simpli­fier la compré­hen­sion du projet et éviter l’ef­fet tunnel est une pratique en augmen­ta­tion. J’ai nommé : les méthodes agiles ! Et l’idée n’est pas si mauvaise. Après tout, la gestion de projet en silo a mainte fois montré ses faiblesses. Mais vouloir briser au bull­do­zer dix ans d’ha­bi­tudes de travail reste pure­ment théo­rique. En pratique, ça prend beau­coup de temps et des suées froides. Je vous conseille l’ar­ticle 10 actions pour faire progres­ser l’er­go­no­mie et l’UX en entre­prise de Raphaël Yhar­ras­sarry pour mieux comprendre le problème. Quoiqu’il en soit, il existe peut-être un juste milieu, non ?

D’ailleurs, si on s’in­té­resse au détail de ces solu­tions, on peut se rendre compte qu’elles ne résolvent, non pas des problèmes, mais des faits engen­drés par des problé­ma­tiques. Il ne s’agit donc pas de solu­tions viables, que ce soit sur le court terme, ou le long terme. Il faut donc recher­cher d’autres solu­tions plus adap­tées à la situa­tion actuelle.

Un problème de contexte.

La commu­ni­ca­tion interne d’un projet, c’est comme un débat. Chacun des inter­lo­cu­teurs dispose d’ar­gu­ments et c’est à celui qui a le plus de poids dans la balance qui sera vainqueur. Et en l’oc­cu­rence, pour le projet sur lequel vous travaillez, c’est le client : c’est son projet et son budget. Diffi­cile donc, en tant qu’a­gence, de faire valoir ses argu­ments basés sur des connais­sances consi­dé­rées à moindre ampleur.

On se retrouve donc face à deux idéa­tions oppo­sées. Comment faire, pour outre­pas­ser ces diffé­rences de contextes dans la concep­tion d’un projet ?

Là où le bât blesse, c’est lorsqu’on rappelle que les objec­tifs du projet ne sont rien sans les utili­sa­teurs. En effet, s’il n’y a pas d’uti­li­sa­teurs, il n’y a pas de vali­da­tion d’objec­tifs. Or, les utili­sa­teurs disposent eux aussi d’un point de vue qui leur est propre. Et à la diffé­rence du client qui ne jure que par son idée, et l’équipe projet—qui est le pire grou­pe­ment d’uti­li­sa­teurs (sans offence)—, ce contexte est celui sur lequel devrait être basée la stra­té­gie mise en place. Mais, comment s’y prendre ?

Les proces­sus d’UX design.

Le travail d’UX desi­gner repose sur un ensemble de connais­sances, de compé­tences, mais aussi et surtout de méthodes à appliquer tout au long d’un projet. Ces proces­sus servent juste­ment à l’éta­blis­se­ment d’un contexte d’uti­li­sa­tion en vu de conce­voir les spéci­fi­ca­tions et les justi­fi­ca­tions qu’un projet requiert. Or les nombreux livrables conçus à partir de ces méthodes peuvent égale­ment avoir un rôle de diffu­sion du contexte auprès de toutes les parties du projet.

D’autre part, l’UX design ne se limite pas à la seule satis­fac­tion de l’uti­li­sa­teur. Certains consi­dèrent que les infor­ma­tions rele­vées auprès des utili­sa­teurs sont infaillibles et permettent de satis­faire tous les besoins du projet. Or il y a cette règle de sécu­rité chez les déve­lop­peurs du « Do not trust user input » qui au final s’ap­plique tout autant dans la vali­da­tion des objec­tifs. Un utili­sa­teur satis­fait n’est pas forcé­ment un utili­sa­teur qui répon­dra à vos objec­tifs.

La concep­tion centrée utili­sa­teur, contrai­re­ment à la croyance popu­laire, n’est pas innée. Elle est étudiée, réflé­chie, proto­ty­pée, vali­dée. Bref, c’est une démarche scien­ti­fique.

Recher­cher et comprendre le contexte.

D’ailleurs, dans le milieu scien­ti­fique, il est demandé d’être ration­nel. Concrè­te­ment il s’agit de répondre à une problé­ma­tique par une solu­tion véri­fiée. Chez les jour­na­listes, on parle d’ailleurs d’objec­ti­visme. Et la concep­tion de services n’en est pas exemp­tée. Cepen­dant, la réalité est un peu diffé­rente.

J’ap­pelle ça la théo­rie du « moi je ». De la même manière que le point Godwin est attri­bué aux argu­ments extrêmes dans une conver­sa­tion qui dure, cette expres­sion est la plus employée dans le débat de la défi­ni­tion des spéci­fi­ca­tions. Or notre mission n’est pas de juger, ni d’être l’uti­li­sa­teur. Notre mission, encore une fois, est d’éta­blir les éléments répon­dants à la fois aux problé­ma­tiques des utili­sa­teurs, ainsi qu’aux objec­tifs client.

Il est donc essen­tiel d’étu­dier le contexte rela­tif aux utili­sa­teurs finaux. Les méthodes d’entre­tiens indi­vi­duels et de ques­tion­naires sont par exemple un excellent moyen d’ob­te­nir des infor­ma­tions quali­ta­tives liées au projet. On fera égale­ment appel à d’autres méthodes tel que le tri par carte pour obte­nir des infor­ma­tions spéci­fiques (ici l’ar­chi­tec­ture de notre projet).

Agré­ger et diffu­ser le contexte.

La première fois que j’ai mis en appli­ca­tion cette métho­do­lo­gie, j’ai comis une erreur. Étant le seul UX desi­gner à bord, et au vu du peu de temps dont je dispo­sais, je n’ai pas pris la peine d’agré­ger ni de diffu­ser suffi­sa­ment mes résul­tats de recherche. Si j’étais en mesure de comprendre le travail que j’avais déjà fourni jusque là, la justi­fi­ca­tion pour les autres inter­ve­nants (et notam­ment le respon­sable projet) était en revanche moins claire. Force a donc été de consta­ter que toute mon analyse du contexte n’avait servi à rien.

Et c’est forte­ment regret­table lorsqu’on sait que la diffu­sion de cette étude au travers de livrables comme les perso­nas, flow­charts, wire­frames et autres docu­ment ont un impact impor­tant dans la compré­hen­sion de ce contexte. Vous pouvez égale­ment adjoindre une analyse concur­ren­tielle sous forme de grille de compa­rai­son entre les fonc­tions présentes chez les concur­rents et les besoins utili­sa­teurs. Ce docu­ment ne fera que renfor­cer la compré­hen­sion de l’in­té­rêt de votre travail auprès du client.

Mettre en action les éléments qui permettent d’éta­blir les inter­ac­tions et la vali­da­tion des objec­tifs est crucial. Dans l’idéal, ce type d’in­for­ma­tion doit être constam­ment visible, que ce soit pour les inter­ve­nants, ou lorsque le client vient échan­ger avec vous. Comprendre, et faire comprendre, c’est la moitié de votre travail (si ce n’est plus).

Conce­voir et suivre les guide­lines.

Le plus gros problème de commu­ni­ca­tion interne que j’ai pû consta­ter jusqu’à aujourd’­hui, c’est le filtrage des infor­ma­tions entre les diffé­rentes parties. Heureu­se­ment, ce type de proces­sus apporte des spéci­fi­ca­tions claires et précises accep­tées par tous et faisant appel à tous les inter­ve­nants. Et si vous avez suffi­sa­ment commu­niqué ces infor­ma­tions, il ne reste alors à votre équipe qu’à suivre des guide­lines.

Géné­ra­le­ment, la réflexion d’un projet sans contexte de travail entraine des omis­sions dans les spéci­fi­ca­tions. Or si vous avez effec­tué concrè­te­ment vos recherches (et non imaginé des choses), vos spéci­fi­ca­tions contien­dront l’en­semble des éléments néces­saires à la réali­sa­tion du projet. Vos équipes n’au­ront alors plus à se soucier des problé­ma­tiques usuelles que sont les réflexions en cours de projet sur des inté­rac­tions non déter­mi­nées.

Ceci est un sujet à part entière, mais la spécia­lité de chacun est impor­tante. Le fait même d’évi­ter les réflexions sur les spéci­fi­ca­tions au cours du projet permet à chaque spécia­lité de s’étendre (et d’ex­pé­ri­men­ter) et ainsi appor­ter une plus value impor­tante par son savoir.

Proto­ty­per et itérer sur le projet.

Nous le savons que trop bien, la période de concep­tion est la période la plus frus­trante des équipes projets. Le client souhaite connaître l’avan­ce­ment de son projet. Il décide de remettre en cause certaines déci­sions et il faut alors appor­ter des modi­fi­ca­tions impor­tantes sur le projet alors même qu’il n’est même pas arrivé au stade de produc­tion (où le produit est fonc­tion­nel).

Quelles solu­tions avons-nous dans ce cas ? Je vous parlais plus haut de la méthode de l’au­truche, mais certains préfèrent le contrat qui stipule l’in­ter­dic­tion de modi­fier le projet une fois validé. Et ceci n’est pas une excel­lente expé­rience pour le client qui pert alors le contrôle de son projet.

Grand bien nous fasse, il existe une seconde phase dans l’op­ti­mi­sa­tion de l’ex­pé­rience utili­sa­teur : le proto­ty­page fonc­tion­nel. Et c’est l’oc­ca­sion rêvée pour démon­trer à votre client s’il a tord ou raison de remettre en cause votre concep­tion. Vous me direz certai­ne­ment qu’ac­cep­ter que le client ait raison, c’est mal. Mais l’in­té­rêt premier d’un proto­type est de véri­fier que le projet est sur la bonne voie (et de la bonne façon). Une remise en cause n’est donc en aucun cas une défaite;

Cas n°1 :
Votre client a tord, et le fait de mettre en place—de manière gros­siè­re—­son idée vous permet­tra de lui démon­trer son erreur. Vous pour­rez ainsi ache­ver le projet sans vous préoc­cu­per de cette problé­ma­tique appa­rue au cours du déve­lop­pe­ment;

Cas n°2 :
Votre client aura raison et ce projet sera remis dans le droit chemin. Les objec­tifs seront alors atteints et vous serez satis­fait d’avoir travaillé sur un projet réussi (oui, il faut aussi savoir se remettre en cause).

Dans tous les cas, vous serez, d’une façon ou d’une autre, gagnant. Certains parlent de l’ité­ra­tion de manière beau­coup plus précise. Et cet autre article met égale­ment avant l’in­té­rer de l’ex­pé­rience utili­sa­teur sur l’ex­cé­dant de fonc­tion­na­li­tés.

Prévoir et main­te­nir le produit.

La mise en produc­tion d’un service est égale­ment une étape déli­cate. C’est la période à laquelle est déter­miné le succès ou non de la pres­ta­tion réali­sée. Et dans ce cas là encore, il est inté­rês­sant de prévoir les diffé­rents retours client. Car oui, un projet qui ne donne­rait pas suffi­sa­ment de résul­tats posi­tifs est ouvert aux retours du client, paniqué de voir son projet échouer.

Les tech­no­lo­gies du web (et d’in­ter­net en géné­ral) évoluent, et nous permettent de faire évoluer nos produits. Et j’as­siste régu­liè­re­ment à la refonte complète de projets sous prétexte qu’ils ne soient plus au goût du jour (graphique­ment ou tech­no­lo­gique­ment parlant). Mais connais­sons-nous seule­ment la portée et la raison de telles modi­fi­ca­tions sur nos projets ?

Vous connais­sez ce dicton médi­cal « mieux vaut préve­nir que guérir ». Encore une fois, la gestion de projets n’en est pas exemp­tée. Se retrou­ver face à un gouffre parce que nous manquons de réponse est une problé­ma­tique quoti­dienne pour les char­gés de rela­tion client.

Plutôt que ce voir vos projets comme des produits finis, il serait plus avan­ta­geux de les voir comme des expé­ri­men­ta­tions conti­nues. Et ces expé­riences vous permettent de répondre aux problé­ma­tiques dans de futures mises à jour.

Le mot de la fin

Là où d’autres métho­do­lo­gies proposent un chan­ge­ment radi­cale, j’ai préféré une approche par l’adap­ta­tion à une situa­tion exis­tante (recherche, aggré­ga­tion, expé­ri­men­ta­tion, itéra­tion et suivi). De la même manière que les habi­tudes et compor­te­ments des utili­sa­teurs évoluent, celle des clients ne déroge pas à la règle. Il est donc inté­rês­sant de propo­ser une métho­do­lo­gie qui prend en compte, à la fois la menta­lité de votre client, et vos besoins en tant qu’a­gence.

Aussi, cette métho­do­lo­gie se veut appor­ter des réponses aux pres­ta­taires, mais aussi faire évoluer les menta­li­tés des uns et des autres. L’objec­tif recher­ché au travers ce chan­ge­ment de proces­sus est de rendre plus fluide la gestion d’un projet. L’ex­per­tise de vos équipes projet peut ainsi être valo­ri­sée. Peut-être envi­sa­ge­riez-vous alors de passer aux méthodes agiles … ?

En revanche, lors de la mise en appli­ca­tion de cette métho­do­lo­gie, je me suis heurté à une problé­ma­tique quelque peu préoc­cu­pante. Arri­ver en entre­prise et propo­ser une métho­do­lo­gie diffé­rente peut être assez mal vu auprès de certains mana­gers. Et ceci est forte­ment lié à notre culture « top-down » où le stagiaire ne doit jamais faire plus que ce qui lui ai demandé, par peur du rempla­ce­ment. Il faut donc réus­sir à appor­ter ce type de chan­ge­ment de deux façons :

• Démon­trer l’in­té­rêt et les béné­fices de ce chan­ge­ment dans la gestion de projet (l’im­pact en terme de budget, rela­tion client et satis­fac­tion des inter­ve­nants)
• Appor­ter une plus value rassu­rante pour les instances supé­rieures en préci­sant que cette métho­do­lo­gie n’a pour objec­tif que de vous permettre de faire votre travail dans des condi­tions adéquates.

Je m’ap­plique encore aujourd’­hui à procé­der à ce chan­ge­ment de métho­do­lo­gie. Cela prend du temps, mais « affaire à suivre »…