Design Thinking et méthode agile appliqués au développement de solutions

Une approche centrée sur le point de vue des utilisateurs

 La co-innovation avec les clients se développe au sein des départements R&D et, pour qu’elle soit un succès, elle doit être bien orchestrée. Co-innover ne s’improvise pas, car plusieurs acteurs entrent en scène : les experts techniques et métiers du prestataire, les clients et les futurs utilisateurs finaux. Plusieurs méthodes peuvent être utilisées, dont deux nous semblent les plus adaptées au développement d’applications orientées utilisateur : le Design Thinking  suivi d’un développement en méthode agile.

Le Design Thinking est pour partie issu d’une méthode éprouvée que l’on avait communément l’habitude d’appeler « Brainstorming ». L’objectif est de réunir des utilisateurs de nos clients avec des experts Sopra HR, afin qu’ils réfléchissent ensemble aux nouvelles fonctionnalités nécessaires à l’amélioration des processus métiers. Le but est d’arriver à trouver un accord entre plusieurs clients de secteurs d’activité différents et de synthétiser leur besoin en une phrase. L’exercice est difficile, car les problématiques peuvent différer d’un secteur à l’autre et il faut pouvoir décrire une solution qui retient l’essentiel, c’est-à-dire sa fonction et son champ d’application.

Les trois phases du Design Thinking

Lors des ateliers de réflexion de Design Thinking, nous invitons entre trois et cinq clients, répartis en groupes de trois/quatre personnes, composés d’experts métiers et d’utilisateurs chargés d’expliquer les difficultés auxquelles ils se confrontent quotidiennement. Ces ateliers de réflexion se déroulent sur 2 jours.

La méthode Design Thinking comporte trois phases majeures. La première consiste à définir le besoin. Les clients s’accordent en général assez facilement pendant cette première phase de décryptage. Cependant, il faut compter environ une demi-journée pour arriver à définir et étayer les points d’achoppement.

La deuxième phase consiste à créer des avatars, les « personas », qui vont incarner les différents types d’utilisateurs possibles. On crée un échantillon d’une trentaine de personnages virtuels avec leurs affinités et résistances au changement, pour les mettre en situation. Peu à peu, on affine les choix pour se focaliser sur trois ou quatre « caricatures » d’utilisateurs ou « personas » les plus pertinents par rapport à la solution à développer. Il s’agit le plus souvent d’un manager, d’un gestionnaire RH, d’un administrateur, d’un gestionnaire RH junior à l’aise avec les nouveaux usages digitaux ou encore d’un collaborateur avec beaucoup d’ancienneté et qui a vécu toutes les évolutions RH au sein de l’entreprise.

La troisième phase consiste à définir les « User Journey » pour chaque « persona ». Ces « User Journey » décrivent la façon dont chaque « persona » interagit avec la solution. Pendant cette phase, on fait interagir l’ensemble des utilisateurs. C’est là que se joue la réalisation finale de la solution, car les clients doivent s’accorder sur l’essentiel pour le développement des différentes fonctionnalités. La solution sera, au final, évidemment générique et ne couvrira pas forcément toutes leurs volontés initiales.

L’avantage de cette méthode est que les clients s’approprient la solution, fruit de leur propre créativité, et en deviennent ensuite des « ambassadeurs » : elle est devenue leur propre production, car ils ont participé à tout le processus de création jusqu’à décider du rendu final. Le Design Thinking est en effet une méthode extrêmement pragmatique, qui implique les participants en leur faisant littéralement « dessiner » leurs réalisations : les différents écrans, les templates ou modèles, les déclinaisons sur tablette, etc. Personne ne juge ou ne restreint sa créativité. Ce qui est important, c’est la restitution, la construction du système grâce aux différentes interactions des utilisateurs ou « personas », qui servira de base pour le développement de la solution. Une liste de fonctionnalités, ainsi que différents écrans qui leur correspondent au mieux sont définis.

Après ces ateliers, les différentes maquettes ou prototypes sont réalisés, ainsi que l’enchaînement des différentes pages ou écrans, qui seront ensuite validés avec les clients. Tout est misé sur la qualité de l’expérience utilisateur qui peut susciter des émotions positives. De fait, on part de l’usage tactile, sur tablette, pour l’adapter ensuite à l’ordinateur, car la tendance est aux usages mobiles et aux applications extrêmement simples à utiliser.

Un développement tout aussi agile

Pour continuer avec une approche centrée utilisateur, la phase de développement se fera en mode « agile », avec une forte interaction avec les clients. La « backlog de user stories » est créée, consistant en une série de mises en scène qui correspondent à une liste de fonctionnalités ou de tâches nécessaires pour la réalisation satisfaisante du projet. Un « Product Owner » ou PO est désigné qui en sera responsable. Sa mission est de traduire les différentes maquettes et besoins issus de la phase de Design Thinking en « user stories ». Leur nombre est illimité. Dès qu’une fonctionnalité vient à manquer, une nouvelle « user story » est créée. Cette « backlog » est ensuite priorisée pour mettre en tête les « user stories » qui apportent le plus de valeur à l’utilisateur.

Enfin, on sélectionne les « user stories » qui permettront d’aboutir à une solution de type « MVP » (Minimum Viable Product), qui pourra être mise sur le marché rapidement, dans la prochaine version du produit. Durant cette phase de développement, les échanges avec les clients continuent ; ils valident régulièrement l’avancement.

Des équipes d’environ huit personnes, organisées en mode start-up, sont ensuite constituées autour du PO, responsable du périmètre fonctionnel et en charge d’expliquer les « user stories » aux développeurs. Chaque équipe est polyvalente et multidisciplinaire et travaille sur un sous-module. Il y a une émulation positive et créative entre les équipes pour réaliser à temps le travail demandé. Par exemple, lors du « planning meeting », sorte de cérémonie, les développeurs revoient la « backlog » avec le PO et s’engagent à traiter un nombre de « stories » pendant une itération. Les « sprints », ou itérations de développement, durent normalement de deux à trois semaines. A l’issue d’un sprint, une fonctionnalité peut être présentée aux clients pour remarques et validation.

Appliquer les méthodes agiles et Design Thinking apporte une nouvelle manière de concevoir et développer des solutions plus efficientes, centrées avant tout sur l’usage et l’humain.