La collaboration entre designers chez Alan

• L’organisation produit d’Alan
• Les bases 🔨
• Design Lunches 🍱
• Design reviews 🔎
• Le mentorat et les 1:1s 🙌
• Et ensuite ?

Photo : Josh Calabrese (Unsplash)

Alan a déjà beaucoup parlé de son choix d’éliminer les réunions et de sa culture de l’écrit. Qu’on adhère ou qu’on déteste, ça ne laisse pas grand monde indifférent et ça génère pas mal de questions — notamment « comment est-ce que les designers collaborent dans un environnement pareil ? »

Commençons par voir comment nous travaillons chez Alan, de manière générale.

Avant d’aller plus loin, notons que nous utilisons essentiellement l’anglais puisque nous avons parmi nous des anglophones — cet article conservera donc quelques anglicismes.

Les crews

Chez Alan, les designers travaillent au sein de petites équipes pluridisciplinaires que nous appelons crews. Dans d’autres structures, on peut trouver des équivalents sous les noms « pods » ou « squads ». Pour faire court, c’est une équipe projet.

En plus d’un designer, chacune de ces crews comprend au moins un ingénieur (souvent plusieurs) et un product manager. L’équipe peut aussi inclure des gens de l’équipe Assurance, des commerciaux ou des responsables de service client, en fonction du sujet qu’elle aborde.

Les crews ont généralement une vie assez courte : autour de 3 mois.

Elles sont mises en place pour aborder un problème spécifique et sont libres d’écrire leur mission statement, leurs objectifs et leur feuille de route en toute autonomie.

Les crews mettent en place plusieurs “initiatives” (ou projets), qui sont là pour leur permettre d’atteindre leurs objectifs.

Les initiatives

Comme les crews, les initiatives impliquent au moins un designer, un ingénieur et product manager. Il y a deux étapes majeures pour une initiative :

• Le « framing » (la définition) : on s’assure qu’on comprend les racines de la problématique. On fait une estimation du travail à accomplir et on établit un premier jet de solution.

• Le « making » (l’exécution) : on livre la solution qu’on avait envisagée à l’étape précédente.

L’essentiel de la communication dans ce processus se fait à l’écrit, dans des discussions asynchrones qu’on appelle des « issues », parce qu’on se sert des « issues » Github comme support (pour faire simple, ça ressemble à un forum de discussion).

Dès cette étape, le fait de communiquer à l’écrit avec le reste d’une crew facilite énormément le fait d’inviter un autre designer dans une discussion pour avoir son point de vue. Il suffit de l’inviter avec une question directe (@nom) et il aura immédiatement tout le contexte à portée, ce qui lui permettra de fournir une réponse détaillée.

Les communautés

Une communauté, c’est un ensemble d’Alaners qui partagent les mêmes compétences ou la même fiche de poste. Par exemple, nous avons une communauté Product Design.

Entre autres, les communautés sont responsables de :

• s’assurer que la communication horizontale entre ses membres fonctionne bien ;

• organiser tout ce qui est propre à leur communauté, comme le partage de ses processus et de ses outils de travail.

Intéressons-nous maintenant à la façon dont les designers travaillent ensemble dans cet environnement !

Révélation : les designers ont un channel Slack dédié. Il sert entre autres à discuter de tout et de rien, puisque les designers ne sont pas groupés dans un coin des bureaux. De l’actualité du design aux questions de travail en passant par des piques sur la dernière mise à jour de Sketch : tout y passe.

Toujours sur Slack, tout le monde écrit son HPFO le mardi.

HPFO, ça veut dire Highlight, Progress, Fire, Objectives. En français, ça donnerait Temps forts, Progrès, Incendies, Objectifs — mais plutôt que de rajouter un nouveau sigle, on a choisi de conserver la version anglaise. C’est un petit récapitulatif de ce qu’on a fait la semaine passée et de ce qu’on prévoit de faire pendant la suivante.

Grâce aux HPFO, chaque designer a un petit aperçu de ce que font les autres.

Les lundis midi, les designers mangent ensemble.

Julien, Marion, Nassime (notre nouvel User Researcher) et moi mangeons notre Frichti, tandis que Marie (un cran plus tatillonne 🧐) s’amène ses petits plats maison (qui, pour être honnête, ont l’air délicieux).

On commence par discuter de nos vies en général. Ça peut être Julien qui taquine Marion sur son petit accent, les derniers films ou expos qu’on a vus, le dernier thread Twitter qui a fait parler de lui, les aventures d’Elon Musk, des hypothèses sur ce qui s’est passé dans la tête des gens qui ont développé les Post-Its Z-Note, ou comment la réalité virtuelle et la réalité augmentée vont changer les usages à l’avenir… Tout y passe.

Une fois le repas terminé, on partage notre travail qui pourrait avoir un impact celui des autres designers. Ça peut être des screenshots de nouveaux éléments d’interface, des nouveaux flows ; l’idée, c’est de tenir la communauté au courant.

En amont de ces déjeuners, on se partage les éléments dont on veut parler dans un Google Doc dédié. Comme ça, tout le monde peut regarder un peu en avance et utiliser le temps qu’on a en face-à-face au mieux.

Les méthodes d’Alan sont très axées sur l’usage de l’intelligence collective.

À différents stades d’un projet, un designer peut demander à ce qu’une design review ait lieu :

• à l’étape préparatoire — la review va couvrir la base même du projet (est-ce qu’on doit le faire ? est-ce que c’est la bonne approche ? est-ce qu’on peut améliorer le projet ?)

• à l’étape du brouillon — on va couvrir l’utilisabilité et les aspects visuels

• à la dernière vérification — quand on s’approche de l’état final, on va s’intéresser à des aspects d’UI et à des détails d’interaction.

La review prend une trentaine de minutes à deux reviewers (tous deux product designers). La personne qui montre son travail présente le contexte (d’où il part et ses objectifs) en 5 minutes, et partage un lien vers sa présentation.

Les reviewers prennent alors 15 minutes pour tester la démo en silence, en prenant des notes.

Les reviewers font ensuite leurs retours.

La personne qui présentait peut alors itérer sur le projet comme elle le souhaite. On croit beaucoup aux responsabilités partagées (tous les Alaners sont autonomes dans leurs décisions).

Pour Alan, c’est important que chacun ait la chance d’évoluer dans la direction qui l’intéresse. Pour ça, on passe beaucoup par le mentoring direct, sous forme de 1:1.

Les 1:1, ce sont des discussions de 45 minutes, qui peuvent avoir lieu toutes les semaines ou toutes les deux semaines — dans la vraie vie, ou en vidéo si besoin. L’essentiel de nos 1:1 se fait en marchant, ce qui aide à libérer la parole et nous décrasse un peu les jambes.

Un Alaner peut être coaché par n’importe quel autre Alaner : ça n’est pas forcément quelqu’un de la même communauté. Donc si par exemple je veux développer mes compétences en gestion de projet, je peux demander à me faire coacher par un product manager.

Les discussions de nos 1:1 portent généralement sur des sujets meta (un mot qu’on aime beaucoup). On ne parle pas des projets à proprement parler, mais de comment on peut le faire mieux ou plus efficacement, que ce soit à notre échelle personnelle ou à celle de l’entreprise. C’est aussi l’occasion de discuter de développement personnel et comment il peut aller de paire avec celui d’Alan.

On discute aussi d’autres sujets, comme :

• mieux communiquer ;

• les bonnes pratiques de Design thinking et d’idéation ;

• nos projets personnels ou nos intérêts communs ;

• ce qui nous y plaît ou non dans nos activités du moment.

Il y a beaucoup de très bons écrits sur comment gérer des 1:1 (comme cet article). Voici un petit aperçu de comment nous gérons les nôtres chez Alan :

• Les deux participants prennent des notes (privées) de leur côté, sur leurs frustrations et leurs questions ;

• Avant le 1:1, on se partage la liste des sujets qu’on voudrait évoquer en se basant sur nos notes de la semaine ;

• Après le 1:1, on prend des notes rapides sur la discussion pour nourrir les futurs échanges ou pour y repenser à tête reposée.

Dernier point : chez Alan, les 1:1 peuvent se faire dans le cadre d’une relation de mentorat (une personne en aide une autre, c’est souvent à sens unique) ou entre pairs (deux personnes sont au même niveau et s’échangent simplement leurs conseils).

Puisque l’équipe de design est relativement petite, tous les designers ont des 1:1 avec les autres — là encore, toutes les semaines ou toutes les deux semaines.

L’équipe grandit rapidement et nos méthodes évoluent en conséquence.

Par exemple l’équipe (jusqu’ici composée exclusivement de profils très senior) s’ouvre à des personnes moins expérimentées ou plus spécialisées — l’occasion de repenser l’organisation et les méthodes !

J’espère que cet article vous aura donné une image claire de comment les designers fonctionnent chez Alan.

Merci de nous avoir lu !