31/10/2018 9 Minutes read Design 

Vers une bonne pratique du Pair design

Le « pair design » : un anglicisme de plus ?  Cela fait un moment que j’entends parler de « pair design ».  La plupart du temps dans des articles anglophones traitant de la méthodologie agile ou de techniques de design d’expérience utilisateur, mais également récemment au cours des dernières conférences de Flupa UX Day 2014. 

ekino paris Team communication

Le « pair design » : un anglicisme de plus ?

Cela fait un moment que j’entends parler de « pair design ».

La plupart du temps dans des articles anglophones traitant de la méthodologie agile ou de techniques de design d’expérience utilisateur, mais également récemment au cours des dernières conférences de Flupa UX Day 2014.

Cela attise ma curiosité ces derniers temps, car ce sujet laisse supposer que le travail en binôme est la clé d’une expérience utilisateur réussie, en opposition avec le travail en solo.

Rares sont les occasions d’être à deux pour réaliser une même mission d’UX sur un projet.

Dans mes souvenirs, mes expériences qui pourraient se rapprocher le plus à la notion de pair design me font replonger au cœur de mes études supérieures ; à une époque où le fait de travailler à deux sur un même poste informatique était poussé par une contrainte matérielle plus que par un intérêt pédagogique.

Ah, les fameux travaux en binôme… à se battre pour savoir qui va prendre la souris ; et aussi l’occasion de se découvrir des affinités… ou pas.

Aujourd’hui, ce sujet semble beaucoup intéresser nos amis d’outre-atlantique qui sont prolifiques sur le sujet.

Peut-être sont-ils plus enclins à tester de nouvelle méthodes de design et à remettre leurs habitudes de travail en perspective ?

Mais de quoi elle parle en fait ?

Il semblerait que le pair design soit un produit dérivé du « pair programming » (ou « programmation en binôme » en français).

Super… Et le « pair programming », c’est quoi ?

En fait c’est :

  • 1 seul poste de travail : écran + clavier + souris ;
  • un “conducteur” (ou “driver”) qui prend le contrôle du qui code ;
  • un “observateur” (ou “observer”) qui analyse ce que l’autre fait, repère les imperfections et propose des alternatives ;
  • ils échangent leurs rôles toutes les 30 minutes environ ce qui permet de conserver une bonne dynamique dans les échanges

Le principe est d’impliquer deux développeurs qui vont écrire du code ensemble et qui pourront se compléter dans leurs niveaux de séniorité ou leurs domaines de compétences.

À tour de rôle, ils vont pouvoir prendre la casquette de « driver » et de « navigator ».

Le « driver » écrit le code et se charge des aspects tactiques, pendant que le « navigator » quand à lui, s’occupe d’observer, de vérifier chaque ligne de code. Il doit également se porter garant de la stratégie mise en œuvre en cherchant à anticiper les problèmes ou des idées d’améliorations en phase avec le projet sur le long terme.

Ces deux développeurs vont ainsi avoir l’occasion d’échanger et d’argumenter à l’oral leurs points de vue et leurs choix sur le code produit.

Aujourd’hui, cette méthode est donc réservée à un public de développeurs, front ou back, qui sont impliqués souvent dans une méthodologie plus globale de projet en agile ou Scrum.

Un des freins à l’adoption du pair programming en entreprise est l’idée que deux personnes travaillant sur un même projet constituent un gaspillage de ressources humaines.

Sauf que des méthodes de calculs scientifiques très compliquées (Wikipedia les expliquent très bien) démontrent que le temps investit par les deux développeurs en parallèle permet de délivrer un code de qualité, d’étudier toutes les possibilités, et tout cela beaucoup plus rapidement qu’un développeur seul.

Et, en bonus, moins de bugs couteux à réparer en fin de projet.

Le choix des deux développeurs qui vont collaborer ensemble en pair programming devra quand même se baser sur un certain nombre de critères qui facilitera le rapprochement des deux profils : différences de niveaux de séniorités ou d’expertises, intérêt commun pour le projet, ou juste de la bonne entente entre eux, etc.

Car s’ils peuvent s’épanouir dans ce type de collaboration, cette nouvelle situation peut, si elle est mal gérée ou “imposée” par le management, au contraire révéler de la désimplication pour le projet et exacerber des problèmes relationnels au sein de l’équipe.

Il faut donc être vigilant quand à la manière d’amener

Du pair programming au pair design, il n’y a donc peut-être qu’un pas ?

On peut effectivement se demander pourquoi on ne pourrait pas transposer très simplement cette méthode aux UX Designers, voir l’étendre également à d’autres profils de designers en général.

Il existe déjà, en agence, le principe des teams créatifs souvent constitués d’un Concepteur Rédacteur et d’un Directeur Artistique. Mais ces deux profils sont issus de l’univers de la pub et leur créativité trouve son essence dans leur complicité et dans la complémentarité de leurs métiers.

De l’autre côté de l’Atlantique, le concept n’a l’air d’être appliqué à l’heure actuelle que chez Cooper Design, une agence UX au Canada qui a déjà publié plusieurs articles pour partager leurs expériences sur le sujet, mais également des organisations comme le Designer Fund avec Bridge et le Interaction Design Department at CCA.

Et concrètement, ça fait quoi dans la vie de vrais « pair designers » ?

Un bon couple de pair designer va porter tout le spectre créatif d’un projet.

Tout comme nos pair programmers, notre paire sera ainsi constituée de deux profils, un « generator » et un « synthetizer », qui échangeront de casquettes le faire à tour de rôle.

  • Un « generator » aura pour mission, de porter l’invention du concept ou de la tâche à produire.

Il génère des idées et teste différentes pistes en les mettant rapidement sur le papier pour les partager et rendre la solution visuelle ou directement sur ordinateur.

Il va s’attacher aux aspects plus tactiques comme l’éditorial, le fonctionnel et les aspects esthétiques des éléments d’interfaces à produire.

  • Un « synthetizer » aura la responsabilité de clarifier et de rationaliser le travail produit afin de donner une vision, une direction au projet.

Il va poser des questions, aider à analyser, améliorer et itérer sur le design produit et à synthétiser leurs partis pris afin de donner un sens à leur travail. Il va devoir mettre des mots sur des concepts et grâce aux solutions visuelles produites par le « generator » et va devoir définir les préconisations qui vont permettre de partager et défendre leur travail notamment avec des responsables projets et des développeurs.

En guise de « designers », j’entends des profils similaires à ceux d’UX designers ou d’UI designers.

Pour les UX Designers, la réussite du binôme pourra trouver son bonheur grâce à des affinités différentes pour l’interaction design et l’architecture de l’information, par exemple.

Dans le contexte de la société Cooper Design, les binômes de pair designers reprennent des méthodes similaires à celles des pair programmers : un écran, un clavier et une seule souris, parler à voix haute pour échanger leurs idées, itérer sur du timeboxing (sur un temps limité) et sketcher (faire des croquis) rapidement sur papier ou sur tableau blanc pour produire rapidement un maximum d’idées, faire le tri et creuser les meilleures.

Ils auront pour objectif de réaliser un prototype qu’ils pourront ensuite faire tester auprès d’utilisateurs finaux.

Parfait. Et comment on s’y met ?

Plusieurs solutions s’offrent à nous :

Piste 1 : Full UX

Constituer un binôme d’UX designer avec un senior et un plus junior.

D’autres profils très proches peuvent également se retrouver en binôme ou représenter un des deux profils :

  • un UI (User Interface) Designer ou Visual Designer
  • un Service Designer
  • un Architecte de l’Information
  • etc.

Au lieu de faire appel à une personne unique pour une mission spécifique d’UX/UI Design, il faut profiter de l’occasion pour faire intervenir un binôme de pair designer et démontrer par l’exemple qu’ils peuvent prendre en charge le design de l’expérience utilisateur de bout en bout sur un projet.

Les pair designers peuvent avoir à suivre plusieurs projets en parallèle et ainsi faire partie de plusieurs équipes.

De mon point de vue, il s’agit de la solution la plus simple à mettre en œuvre dans un premier temps pour prouver l’efficacité et surtout la viabilité de cette méthode dans son entreprise.

Piste 2 : Cross-fonctionnel

Constituer un binôme interdisciplinaire avec un UX designer et au choix :

  • un développeur Front;
  • un spécialiste du contenu;
  • un consultant marketing;
  • un responsable projet;
  • un manager;
  • etc.

Pleins de combinaisons sont effectivement possibles, mais elles dépendent surtout des axes stratégiques que vous souhaitez donner à votre projet.

Le résultat sera différent d’une combinaison à l’autre mais permettra de répondre au mieux à l’environnement et aux contraintes de celui-ci.

Dans ce cas, c’est la complémentarité des expertises qui va venir enrichir l’expérience de la collaboration et la qualité du travail produit.

En partageant leurs expériences, leurs connaissances et leurs sensibilités, les membres de ce binôme vont renforcer la faisabilité et la viabilité du projet, qui sera du coup moins sujet à des retours en arrière par la suite.

Avec ce type de solution, nous répondons directement aux préceptes de base de l’agilité en entreprise.

Piste 3 : Cross-fonctionnel appliqué à l’ensemble de la matrice projet

Si on souhaite pousser le bouchon encore plus loin (merci Maurice), il serait logique de se demander pourquoi ne pas étendre cette méthode à l’ensemble d’une équipe projet agile rassemblée autour de la définition, la conception et la production d’un nouveau produit.

Cette alternative consisterait à créer des binômes temporaires et différents, sur une période donnée et avec une mission spécifique pour chaque.

Ils vont ainsi se passer le flambeau tout au long de l’avancement du projet et le « porter » à tour de rôle.

L’enjeu dans ce genre d’organisation est de favoriser la connaissance et la transmission d’information autour du projet mais également de favoriser une forte implication sur celui-ci de la part de ses équipes.

Il s’agit bien là d’une démarche stratégique qui peut impacter fortement les us et coutumes en terme de processus de travail et d’organisation au sein de votre entreprise.

Cependant l’avancement d’un projet ne peut pas se baser uniquement sur le travail de deux pair designer à un instant T et une équipe entière va devoir graviter autour d’eux.

Une première piste serait d’activer à chaque nouvelle phase de l’avancement du projet un nouveau couple de pair designers qui à un instant T feraient office de référents ou d’équipe pivot pour le reste des membres de l’équipe globale.

Par exemple, dans le cadre d’une démarche agile organisée en sprints, il pourrait y avoir une organisation de ce type :

  • Sprint 0 : Scrum Master + UX Designer
  • Sprint 1 : UX Designer + UI Designer
  • Sprint 2 : UI Designer + Développeur Front Office
  • Sprint 3 : Développeur Front Office + Développeur Back Office
  • Sprint 4 : Développeur Back Office + Scrum Master
  • Sprint 5 : Scrum Master + UX Designer

Une seconde piste serait de partir du principe que tous les membres d’une équipe projet pourraient bénéficier de cette approche et donc de mettre en place une organisation globale ou tout le monde serait répartit en binômes, soit avec des métiers similaires ou bien interdisciplinaires comme présenté plus haut.

Le rôle de scrum master transverse sera néanmoins nécessaire en parallèle pour faire office de fil conducteur et veiller ainsi à la qualité et au bon déroulement du projet.

Et au pays des bisounours tout va bien ? Il n’y a pas une solution plus simple pour commencer ?

Et bien au pays des bisounours, ça se passe plutôt bien.

Vous avez, dans votre agence, plein de super profils compétents et complémentaires, ouverts aux autres et qui n’attendent que ça d’améliorer leur travail et d’être sensibilisés aux métiers de leurs collègues.

Mais dans la vraie vie, il peut parfois être nécessaire de faire évoluer les choses en douceur.

Pour cela rien de plus simple : il suffit de concentrer des courtes périodes de pair design mais de les répéter plusieurs fois par semaine. Par exemple, commencer par des sessions de 5 min, puis 30 min, 1h, etc.

Les tous nouveaux pair designers seront les premiers convaincus de l’efficacité de la méthode et n’hésiteront pas à demander, eux mêmes, à pouvoir y investir plus de temps.

Quel intérêt pour mon entreprise ?

Elementary my dear…

Il y a certes quelques inconvénients…

  • il faut trouver la motivation et surtout les bons arguments pour se lancer (Cf. liste des avantages ci-dessous qui est là pour ça) ;
  • cela rajoute un peu de complexité au planning à tenir ;
  • il faut un environnement adapté, et de la place pour pouvoir s’isoler un peu, par exemple une salle dédiée avec tableau blanc pour travailler ;
  • cela va forcément impliquer plus d’interlocuteurs ;
  • il faut être vigilant quand à la communication avec le product owner qui aura besoin de se rendre compte de l’avancement du projet ;
  • il faudra faire attention à la déperdition d’informations et maintenir une documentation stable ;
  • si cette méthode est imposée, elle peut au contraire révéler la dés-implication de certains membres d’une équipe, ou exacerber les problèmes relationnels entre ses membres ;
  • enfin il faut accepter l’idée que cela ne soit tout simplement pas adapté à tous les types de projets.

…mais surtout beaucoup d’avantages

  • Qualité
    • l’équipe « pense » avant de « faire » ;
    • plus d’idées générées ;
    • aide à rester concentrés grâce à moins d’interruptions ;
    • le résultat est plus homogène ;
    • permet de designer et d’itérer rapidement sur ces éléments.
  • Implication
    • crée un véritable esprit d’équipe, et un climat de confiance ;
    • on passe du « j’ai désigné » au « nous avons désigné » ce qui va favoriser le team building.
  • Communication
    • facilite la communication et le transfert de connaissance sur le projet ;
    • cela permet de mieux justifier les choix effectués ;
    • et donne l’occasion après coup de faire de super best practices à partager sur le web.
  • Apprentissage
    • un formidable vecteur d’amélioration de ses compétences personnelles sur son propre métier
    • meilleure connaissance des autres métiers de la chaine
    • améliore l’adaptabilité des personnes concernées
    • une forme d’expertise globale s’homogénéise entre les membres de l’équipe.

Mais qu’est-ce qu’on attend ?

Il est important de toujours remettre en question ce que nous savons et de rester ouvert à la critique et à l’échange.

Le pair design va nous permettre de rendre nos temps de conception plus efficaces et à générer moins de retours en arrière.

Tout cela en restant motivés par l’idée de produire de belles choses ensemble.

Nous n’en sommes qu’au début du pair design en France et dans le monde, et le plus important c’est que vous soyez là pour y prendre part !

QUELQUES RESSOURCES SUR LE PAIR DESIGN