Tech.Rocks Summit 2021

Design in tech : enjeux et conseils pratiques

Tech.Rocks Summit 2021 · 10 décembre 2021 · 33 min · en français

Résumé

Rares sont aujourd'hui les entreprises tech sans designers, mais avoir des designers ne résout pas tout. Amélie Boucher explique comment faire du design plus qu'un vernis pour qu'il apporte une réelle valeur ajoutée aux produits : défis, secrets des organisations qui réussissent et pièges à éviter. Elle partage retours d'expérience et conseils pour mieux intégrer le design dans les équipes.

Summary

Few tech companies today have no designers, yet having designers does not solve everything. Amélie Boucher explains how to make design more than a veneer so that it adds real value to products: the challenges, the secrets of successful organisations and the pitfalls to avoid. She shares experience and advice for better integrating design into teams.

Thèmes : Architecture & développement

Transcript complet

Transcription automatique, à relire : les noms propres peuvent être mal orthographiés.

Elle va nous parler design dans la tête, les enjeux et les conseils pratiques d'Amélie Boucher, consultante et coach UX Design chez ErgoLab. Merci d'être là pour cette conférence sur les enjeux du design dans les entreprises tech. Je suis Amélie Boucher et j'exerce depuis plus de 15 ans maintenant dans le domaine. Aujourd'hui, je coach et j'accompagne des entreprises tech justement sur ce sujet des organisations design. En plus de cette expérience et du fait que Plein d'autres entreprises tech dans le monde rencontrent les mêmes problématiques que nous. Pour préparer ce talk, j'ai fait un petit sondage sur le Slack de Tech.Rocks. Alors merci à ceux qui ont répondu. Et puis j'ai aussi interviewé cinq leaders du design en France pour avoir leur point de vue. Donc j'en profite pour les remercier aussi. Alors, comment commencer? Il y a quelque temps encore, on pouvait dire que prendre la voie du design ou intégrer le design en entreprise tech, ça relevait vraiment d'un choix.

Tout le monde ne le faisait pas, d'abord, on pouvait s'en passer, se reposer sur des agences externes éventuellement qui venaient intervenir ponctuellement. Aujourd'hui, il est vraiment clair que si on veut réussir, cette intégration du design devient quasiment de l'ordre de la dette. Il faut reconnaître que... les utilisateurs sont plus en plus exigeants par rapport à la qualité des expériences qu'ils vivent. Ils sont habitués à ces expériences, des expériences de grande qualité, même sur des produits gratuits. Et cette exigence, elle se retrouve aujourd'hui aussi bien dans des produits B2C que dans des produits B2B, alors que ce domaine B2B a longtemps été un peu mis au rebut en termes de design. Bon, et cette tendance-là, elle ne va pas s'arrêter. Du coup, on peut se poser la question où la question de comment on intègre le design en entreprise tech devient de plus en plus importante. Vous ne serez pas surpris si je vous dis que la compétence est de plus en plus internalisée dans les entreprises versus externalisée et réalisée par des agences.

Et donc aujourd'hui, ensemble, on va se demander à quoi c'est important de faire attention. À quelques éléments que moi j'ai choisis. Et on va évoquer ensemble quatre chapitres, en commençant par celui de la culture design. Pourquoi je commence par ça? D'abord parce qu'évidemment, il va sans dire que c'est fondamental, mais aussi parce que ces fameux design leaders que j'ai interviewés et aussi ceux que je rencontre au quotidien me parlent tout le temps, de façon permanente, de ce sujet de culture design, comme un élément fondateur de la réussite de l'intégration d'une équipe design, mais aussi des pratiques de design dans une entreprise. Autrement dit, quand la culture design n'est pas là, ça ne marche pas, au moins bien, et quand elle est là, Et là, ça peut donner des choses magnifiques. C'est fondamental pour intégrer la pratique dans le quotidien et pour avoir du succès dans les opérations. Cependant, et alors Jean-Louis Fréchin a cette formule hyper intéressante, il dit qu'en France on est un pays designer et pas de design.

Ça veut dire que, et pourtant on est nombreux, on est beaucoup de designers, on exerce, il y a une pratique. Mais si on compare avec notamment nos voisins, le design est souvent vu, il dit lui, confondu avec quelque chose de l'ordre de la décoration. Quelque chose de l'art de la surface, superficiel. Et donc, il faut aller lutter contre ça. Et ça demande d'aller cultiver, instaurer cette culture de design. Ça peut se faire, ça doit se faire sur deux niveaux. D'abord, évidemment, les décideurs. C'est ce dont me parlent le plus souvent les managers de design dans notre entreprise tech en France. On parle très volontiers de soutien ou de non-soutien, quand ça ne marche pas, du top management, du board, des décideurs. Et c'est plus facile, tout le monde le reconnaît et s'accorde à le dire, si on est dans une culture qui est design-centrique. Mais si ce n'est pas le cas, Il y a quand même une solution, entre guillemets, qui est d'aller donner les moyens.

Et on a plein d'exemples d'entreprises qui, même s'ils n'ont pas une philosophie de design comme... fondatrices de leur entreprise, ont su quand même donner les moyens à des designers et placer les bonnes personnes à la tête des entreprises pour réussir. On peut prendre l'exemple chez Doctolib, par exemple, qui donne à Michael David des moyens extraordinaires pour réussir à cultiver, intégrer ce design dans l'entreprise et en faire quelque chose de central. Il y a ensuite le volet entreprise. Et entreprise, ça veut dire tous les collaborateurs. Et là, on peut se poser la question de... Comment on fait pour faire s'immiscer la culture design ? Et juste le dire, évidemment, ne suffit pas. C'est ce qu'on met souvent derrière le terme évangélisation. Évangélisation, ça veut dire qu'on acculture un peu par le discours. On va dire, je grossis le trait, le design, c'est bien, faites-en. Souvent, j'entends, tu sais Amélie, nous on est dans une entreprise tech, on est vraiment des ingénieurs, nos racines sont là-dedans chez nous, le design du coup c'est compliqué parce que ce n'est pas dans la culture.

Est-ce que tu pourrais venir évangéliser les équipes? Donc alors oui, il y va avec grand plaisir et c'est utile, mais clairement ça ne suffit pas. Une autre route, ça va être de pratiquer l'acculturation par le projet, d'aller montrer tout simplement par l'exemple. De ne pas décréter qu'il faut faire du design, mais de le faire et de démontrer à quoi ça sert, donc comment on pratique le design, et surtout, parce que c'est ça qui va faire mouche, voilà les résultats auxquels on peut parvenir. Il s'agit donc de faire pour donner cette habitude et démontrer l'impact que peut avoir le design. Julien de chez Conto, qui est lead product designer chez Conto, me dit cette phrase, tu prends un projet et tu essaies d'en faire un standard de travail. Puisque cette culture, du coup, elle peut se construire par le projet, on va voir ensemble comment on peut organiser les équipes pour mener ces projets.

Et c'est le deuxième chapitre sur les quatre dont je vous parlais au départ. On parle donc de l'organisation du design dans l'entreprise. La première question est celle qui revient le plus souvent dans mes conversations avec les boîtes tech. C'est, mais combien il faut de designers? Alors, on attend un chiffre un peu magique que je n'ai pas, naturellement. À part celui à la façon de Peter Merrol, ce qui consiste à dire, tu n'auras jamais assez de designers. Donc, tant qu'on te donne du budget, prends-le, vous allez le chercher. Mais une fois qu'on a dépassé ça, le plus courant, c'est de fonctionner avec un ratio. On prévoit les headcounts en fonction de ce qu'on a en face chez les autres métiers, que ce soit product manager ou développeur, qui sont souvent les deux registres sur lesquels on va se comparer en termes de ratio. Je voulais vous montrer cette étude de Nissan Norman qui est parue en 2020 et qui montre que le ratio vraiment typique qu'on retrouve le plus souvent dans les entreprises tech, c'est un designer pour dix développeurs.

Vous voyez sur le slide ici qu'ils ajoutent cette nuance du researcher avec un ratio de 1 researcher pour 5 designers pour 50 développeurs. Ça, c'est ce qu'on retrouve le plus souvent. On peut faire mieux, évidemment. Je vous ai mis juste trois exemples parmi plein d'entreprises qui ont vraiment décidé de s'équiper avec un grand nombre de designers en se disant que c'est un moyen pour nous de faire mieux en termes de design. Et c'est intéressant, selon moi, parce que ça reflète aussi ce que le design signifie pour l'entreprise. On voit chez IBM, par exemple, qu'ils visent à peu près à 1 sur 8. Et chez Oda, qui est un supermarché en ligne norvégien, ils sont carrément 1 sur 3 ou 4 développeurs. Ça dit quelque chose de ce que le design veut dire pour Oda. Par contre, il est évident que ce ratio ne fait pas tout. Et ce que je veux vous dire ici, c'est qu'il faut faire extrêmement attention, j'insiste sur le extrêmement parce que c'est quelque chose que je vois quasiment à tous les coups quand j'embarque avec de nouvelles équipes, à un espèce de headcount très simpliste,

parce qu'évidemment, ce n'est pas ça qui compte. Et on ne peut pas aligner les designers comme étant autant de sosies. Parce qu'avec ce type de raisonnement, en fait, ce qu'on voit et ce qu'on observe très souvent, c'est que c'est un espèce de placement de designer dans les squads, parce qu'il faut. Et comme il faut un designer par squad, on en met un. Quasiment peu importe lequel, et sous peu importe lequel, souvent on va viser celui qui coûte le moins cher. Donc le plus junior, voir des gens en alternance, il n'est pas rare de voir des designers dans des squads avec toute l'autonomie que ça suppose, qui sont encore à l'école, ce qui peut être extrêmement dangereux, évidemment. Et même si on améliore un peu le tableau, si on va juste chercher le meilleur rapport qualité-prix, évidemment que c'est un peu compliqué. Donc, pour résumer sur ce point-là, si vous avez une organisation agile, en tout cas par squad, à la Spotify, faites très attention à la séniorité. Parce que dans ces squads, du coup, il y a un seul designer. Et que tous ne se ressemblent pas, et heureusement.

Réfléchir du coup avec cette notion de ratio, c'est un moyen, une bonne base évidemment, mais ce n'est clairement pas une garantie de faire du bon design ou d'avoir du succès. Pour penser ce sujet-là, moi je préfère raisonner en termes d'impact et qu'on vienne à se demander qu'est-ce que délivre l'équipe design? Comment a l'impact sur les métriques? Ce fameux projet d'exemple qu'on a essayé d'utiliser, quel effet ça a eu sur les métriques? Quels ont été les changements sur la qualité de design, sur l'utilisabilité, sur la satisfaction utilisateur? Est-ce que ça a fait bouger les curseurs? Ce qui permet de se décider, notamment je pense au recrutement et à la taille, au volume de l'équipe, en fonction du nombre de gens que j'ai, sur quoi je concentre les ressources que j'ai et où est-ce que finalement l'équipe design a la plus grande valeur ajoutée. Ça c'était pour la partie nombre de designers.

Ensuite, évidemment, on se pose très rapidement la question, et c'est la deuxième question qu'on me pose le plus souvent, c'est souvent, en plus quand on grossit, c'est ok, on commence à avoir 10, 15 designers, 50, comment on fait pour structurer, comment on fait travailler les gens ensemble et c'est quoi le meilleur modèle? Alors, disclaimer, il n'y a pas de meilleur modèle, mais quand même, on peut essayer de lister ce qui existe et puis les avantages et inconvénients de chacun. Toujours Nielsen Norman ont sorti cette étude, cette année je crois, auprès de 557 professionnels dans 59 pays, donc c'est assez énorme. Et ils ont demandé aux gens simplement comment l'équipe design est intégrée dans l'entreprise au global. Et on voit à peu près que ça se distribue à part égale entre trois modèles, centralisé, décentralisé et hybride. Et on va voir ensemble ce que signifie chacun. Le modèle centralisé, c'est un modèle de design studio.

C'est le modèle de l'agence. En pratiquant comme ça, on a un pool de designers qui sont au service des product teams, qui viennent leur exprimer des besoins et auxquels l'équipe de design est censée répondre. Je n'ai pas ici, à parté, représenté tous les métiers ni tous les niveaux de management pour ne pas complexifier. Mais voilà, ça c'est le modèle centralisé, le modèle de l'agence. Il a un gros avantage qui est le fait qu'il existe une équipe design. Et il existe une équipe design qui va pouvoir partager ses compétences, pouvoir ne pas tous se ressembler, pouvoir avoir des experts sur tel et tel sujet. Mais il présente surtout beaucoup de défauts. C'est le modèle souvent avec lequel on commence, par ailleurs, avec lequel on est obligé de commencer, parce que quand on a un petit nombre de designers, on n'a pas vraiment le choix que de partager les rôles. Ces défauts donc, ça nécessite d'abord du trafic management, c'est-à-dire les besoins sont exprimés, ils arrivent en pile, qui va pouvoir les faire, est-ce qu'il y a des disponibilités, etc.

Ça donne souvent des relations, moi ce que j'observe en France avec mes clients, c'est que ça donne souvent des relations de clients fournisseurs, ce qui n'est jamais souhaitable pour que les projets soient à succès. On observe souvent aussi du fait du modèle, et c'est bien du fait du modèle, un manque d'efficience et de fluidité dans les collaborations. Et puis, c'est sans doute le plus important, évidemment, une difficulté à faire équipe au sens produit. Et le travers le plus couramment vu, c'est cette idée de nous versus eux, l'équipe design versus le reste du monde. Et on est incompris et c'est terrible. Donc c'est un modèle qui ne fonctionne pas très bien en entreprise tech et d'autant moins qu'on grossit. Ça peut aller jusqu'à donner, et je crois que c'est ce qui est arrivé à Uber en 2017 ou 2018, des comportements de type, en fait, on ne va même plus demander aux designers de travailler parce que c'est toujours compliqué de travailler avec eux, donc on finit par s'en passer.

Parce qu'on a un rapport coût-bénéfice de ce modèle, qui est en défaveur de l'intégration du design. Bref, quand on commence, c'est très bien, mais plus on grossit, moins ça devient souhaitable. L'inverse, c'est le modèle décentralisé. à la Spotify, je mets de gros guillemets, parce qu'eux-mêmes n'ont jamais voulu qu'on appelle leur modèle de cette manière-là, c'était simplement la façon dont ils travaillaient. C'est un modèle intégré. On a un designer par product team, et souvent un manager au-dessus de tout ça, mais qui finalement a des actions quasiment que de management et pas opérationnelles. Ce modèle avec des squads, des tribes, et malgré ces initiatives de chapters ou de guilds qui vont venir agir de manière transverse, Le plus gros défaut est que souvent, on travaille en silo, et quasiment uniquement en silo, d'autant plus qu'on manque de temps. Et je pense que toute l'audience qui sera à écouter ce talk manque de temps et voit que ses équipes manquent de temps.

Et plus on manque de temps, moins on va à la guilde mensuelle, moins on participe à ce chapitre et plus on se retrouve finalement renfermé sur cette île. Donc le plus important défaut de ce modèle, c'est l'effet de silo. Pourquoi c'est embêtant, particulièrement pour le design? C'est embêtant parce que l'expérience globale et transversale, c'est ce que vivent vos utilisateurs. Ils utilisent une application, une solution, ils ne se disent pas en passant d'un écran sur un autre, ou d'un flow à un autre, d'un usage à un autre, tiens, là je suis avec l'équipe A et là je suis avec l'équipe B. Non, ils vivent une expérience de bout en bout et elle est plus ou moins cohérente. Ce travail en silo provoque assez naturellement des expériences qui ne sont pas très unifiées, pas très cohérentes, qui manquent de cohésion. Il y a d'autres défauts à ce modèle, notamment on observe souvent un espèce de rapport de force déséquilibré. On a tendance, malgré nous, à avoir plutôt des designers juniors

face à des product managers seniors, et du coup un rapport de force qui fait que le designer devient souvent un exécutant de la pensée du PM. C'est un stéréotype, mais ça existe vraiment. Et comme il est tout seul, ce designer, forcément, il n'a pas beaucoup de vos chapitres. Ça fait aussi qu'il y a une grande impossibilité à venir actionner la multidisciplinarité du design. Le design est multidisciplinaire, enfin il doit l'être pour être de qualité. Pour être de qualité, on a besoin d'experts. En fait, c'est l'anti-mouton à cinq pattes. On voit d'ailleurs sur le marché de plus en plus ces profils un peu spécialisés, de UX writers, user researchers, design ops, motion designers, spécialistes des design systems ou en tout genre. Peut-être que demain, je vais encore plus loin sur le champ de l'expertise, peut-être que demain vous allez avoir envie de travailler avec un anthropologue dans l'équipe design.

Peut-être que vous allez avoir besoin d'un spécialiste qui va venir faire grandir toute l'entreprise sur ces sujets. Avec cette organisation décentralisée, c'est impossible. On ne peut pas mettre un expert, un user researcher, qui va tout seul se débrouiller dans sa product team, alors que la conception, par exemple, n'est pas du tout son fort. La seule manière de gérer les profils design dans ce modèle décentralisé, finalement, c'est l'ultra généraliste. Et on aboutit en fait à des profils sosies où il faut surtout que tout le monde se ressemble et pratique de la même manière. Alors que la qualité du design, se font précisément sur la diversité. On y reviendra tout à l'heure. Même Spotify, finalement, a pu souffrir de ce modèle décentralisé. Je vous montre juste un exemple rapide. Nicole Burrow, qui arrive chez eux en 2018, arrive avec des designers qui étaient assis dans leur product team. On voit là très clairement le fait qu'ils sont tout seuls, ces petites pastilles jaunes.

Et elle se rend compte que ça pose évidemment rapidement de gros problèmes d'isolation. En fait, les designers sont tout seuls et n'ont pas d'autre choix. Ils décident assez rapidement de revoir la configuration des bureaux pour que les designers aient à la fois cette appartenance à leur squad, qui est extrêmement importante pour l'empowerment, mais aussi un lien de discipline avec leurs confrères. Ça me donne une transition parfaite pour introduire le troisième type de modèle qu'on a vu tout à l'heure, qui est le modèle hybride. Le modèle hybride, c'est le meilleur des deux mondes, évidemment, avec non seulement un product designer ou des deux au par ailleurs, par product team, mais aussi un pool d'experts qui va venir être au service. De chacun des designers dans le modèle intégré, mais aussi de tous les collaborateurs dans l'entreprise en général. Et là, ça donne des choses intéressantes.

Sur la possibilité d'aller accueillir des experts, des gens vraiment spécialisés sur une discipline. Ce qui est intéressant de noter, je termine sur cette fameuse étude de Nielsen Normal, c'est que ce modèle hybride, on l'observe beaucoup plus dans les entreprises à mesure qu'elles sont grandes. Donc c'est un espèce de témoin de maturité et de la façon dont on va venir intégrer efficacement le design en entreprise. Pour conclure sur ces sujets d'organisation, vous aurez remarqué que le sujet principal finalement, c'est vraiment cet effet de silo versus une vue transversale de l'expérience. On est toujours dans cette rubrique d'organisation. Il y a un point important sur l'expertise, le leadership créatif ou stratégique et le management. J'aurais presque pu dire versus le management. Et là, le conseil le plus important, c'est d'arriver à laisser de la place à l'expertise.

Et quelle que soit la taille de l'entreprise, je vous ai mis l'exemple de ce qu'on voit le plus souvent et de façon symétrique à d'autres métiers dans la tech, qui sont ces parcours de carrière drill track, où on permet aux designers, en l'occurrence, à mesure qu'ils montent en séniorité, de soit prendre un chemin qui s'oriente vers le management, soit de rester sur la branche de l'expertise avec des rôles de contributeurs individuels. C'est très important de garder ça en tête, quelle que soit la taille de l'entreprise. On a un exemple chez Spotify là, mais ça marche même si vous êtes plus petit. Point de vue management, Peter Merholz découpe l'activité d'un manager de design en quatre parties. Et il repère que, enfin il donne cette idée que c'est un signal important de remarquer qu'à partir du moment où en tant que manager design, si vos managers design n'arrivent plus qu'à s'occuper des deux derniers chapitres, à savoir people et operational, il y a quelque chose qui cloche.

Il y a quelque chose qui cloche parce que finalement, là, on est uniquement dans le management et non dans l'activité, non dans le leadership créatif et stratégique. Donc, on perd une partie extrêmement importante de ce qui peut faire le succès du design dans une entreprise. C'est le bon moment pour aller se dire, pour que le manager du design puisse dire, là, j'ai besoin, à y dire à son N plus 1 ou au patron, là, je n'y arrive plus. Et ça veut dire que sans doute, j'ai besoin d'un head of design ops pour m'aider à organiser les choses. J'ai besoin de directeurs du design qui viennent finalement. s'occuper de cette partie stratégique et opérationnelle pour que je puisse mettre le focus sur ce qui m'est demandé selon mon rôle. Dernier chapitre sur ce sujet organisation, c'est quelle place on donne au brand design. Traditionnellement, le brand design, la communication, on va dire, était porté par les départements marketing. De plus en plus, on assiste à un rapprochement du brand design, en tout cas il y a des initiatives notables qui peuvent être remarquées de ce point de vue,

pour rapprocher le brand design et le product design sous une seule bannière qui serait le design, un département design de l'entreprise. On peut remarquer que quand ce n'est pas le cas, et c'est très souvent, c'est 90% des cas, pas le cas, ça donne souvent des problématiques, des challenges politiques. C'est ce que nous dit Jay Harlow qui travaille chez Clover. Parce que le design est vu comme faisant partie du produit. Il est vu par défaut comme différent de la brand, différent de la communication, différent des problématiques de marketing. Il faut viser, et c'est ce qui permet d'avoir un design efficace en entreprise, une bonne intégration du design en entreprise, plutôt une vue du design global, soit par l'organisation, soit par des pratiques collaboratives. Et quand on arrive à une vue de design global qui englobe product design d'une part et brand design de l'autre, là on va pouvoir être vraiment au service d'une expérience utilisateur transversale de bout en bout.

Il y a de plus en plus d'entreprises tech qui opèrent ce rapprochement-là. Il y en a qui sont nées avec, elles ont décidé dès le début que c'était comme ça, et puis d'autres qui, petit à petit, changent de modèle. Ça va souvent être la croissance et la représentativité des équipes design. Mais par contre, et c'était le rôle de ma démonstration là, ça n'est pas du tout, et ça ne doit pas être dépendant de la taille de l'entreprise. On voit là que chez Caffeine, par exemple, avec Nicolas, ils sont 200, mais ils ont ce département design qui s'occupe à la fois de product et de plan. Si on prend un exemple de ce à quoi ça sert, de l'impact de ça, celui qui peut-être pourrait paraître le plus petit, un changement de couleur, Michael David, très récemment, nous a expliqué le fait qu'ils se sont rendus compte en faisant des tests d'accessibilité que leur ancien bleu n'était pas accessible. Le contraste de couleurs entre les caractères et le fond faisait qu'on avait un score d'accessibilité pas dans les normes. Ils ont pu, grâce au fait qu'au quotidien, le brand design, les gens qui s'occupent du design system et le product design travaillent déjà main dans la main, opérer très rapidement à ce que nous avons fait.

assez facilement, malgré le fait qu'il soit 2000, un changement de ce bleu iconique vers un bleu plus foncé qui respectait les normes. Cet étendard équipe de design global, pour le résumer, c'est un bon outil pour s'assurer que l'expérience utilisateur soit réellement travaillée de bout en bout dans la cohérence. Troisième chapitre qu'on va évoquer ensemble, la collaboration, donc non des moindres. On a souvent vu, et c'est une réalité, que designers et développeurs parlent souvent pas le même langage et peuvent avoir du mal à se comprendre. Vous m'avez beaucoup remonté dans ce fameux sondage dont je vous parlais au départ. Cette notion de compréhension comme étant clé dans la relation designer-développeur. J'ai mis en exergue là ces mots-clés de compréhension, de partage, d'acculturation. On voit que c'est vraiment clé et que si on n'a pas ça en creux, ça ne marche pas ou ça ne marche pas assez bien.

Sur le sujet de collaboration, il y aurait deux pièges parmi tant d'autres, deux pièges que je voudrais souligner. Le premier qui serait de réserver le design au designer. Et le deuxième, de se dire que collaborer, c'est une perte de temps, parce que ça prend du temps. Je vais vous montrer quelques exemples et pourquoi collaborer, ce n'est pas juste collaborer. Collaborer, ce n'est pas juste collaborer, c'est faire... Faire équipe, c'est quoi ? C'est travailler ensemble, c'est se connaître, passer du temps ensemble, c'est se soutenir dans l'adversité, c'est partager des moments, des points de vue, et puis c'est aviser ensemble en fonction de ce qui nous arrive, comment on va bien pouvoir se débrouiller ensemble, dans l'équipe. L'année dernière, je suis intervenue dans une product team chez Sologé. Et puis, on menait des activités d'user research et on avait envie de comprendre comment nos utilisateurs percevaient le service au global.

On avait envie d'avoir une vue quantitative, d'avoir un gros volume de données, à côté d'approches plus qualitatives. On avait ce besoin d'avoir des données vraiment quantiques. On n'avait en revanche pas envie d'opter pour une méthode de questionnaire très classique, qui permet d'interroger plein de gens avec des réponses prédéfinies, d'avoir très rapidement des camemberts, mais qui ne nous apprend pas grand-chose. Donc on a utilisé une technique qu'on appelle les phrases à compléter, qui consiste tout simplement à utiliser une technique de questionnaire, mais à simplement proposer à l'utilisateur des débuts de phrases qu'on le laisse compléter selon ses opinions. Ça peut donner par exemple, chez ce loger, je vois souvent des annonces qui... Trois petits points. Alors on se rend compte quand je dis cette phrase que c'est un exercice pas très facile. Donc on avait très peur que les gens ne répondent pas. Au final on a eu plus de 2000 réponses. Et on s'est dit comment on fait? Soit on jette des choses, soit finalement on se dit... Comment on peut faire pour traiter ces résultats ? On est obligé de le faire manuellement, ensemble. Et donc, c'est ce qu'on a fait. Ingénieur, product manager, product designer, on s'est mis ensemble, on a catégorisé les types de réponses avec des tags, et puis on s'est attribué des lots à traiter.

Et faire ce travail ensemble, ça nous a permis de faire équipe. Collaborer, c'est aussi grandir ensemble. Dans grandir ensemble, il y a le apprendre ensemble. Je vous donne un autre exemple. On a mené pour la partie quali des interviews. J'ai coaché les ingénieurs, ceux qui le souhaitaient, ils n'ont pas tous fait, pour faire passer des interviews. À quoi ça a servi? À développer leur empathie, le truc qu'on cherche, le mirage qu'on cherche tous un peu. On ne peut pas juste décréter qu'on a de l'empathie envers les utilisateurs. Ça se produit au contact de ces utilisateurs. Donc là, c'est un moyen de faire équipe autour de ces sujets-là. Collaborer, c'est aussi être plus véloce. Julien de Checonto m'a expliqué qu'ils font venir les ingénieurs vraiment très tôt, mais pas juste faire venir les ingénieurs, ils ont de vraies pratiques de co-conception. Et ça leur permet finalement, comme il dit, de lever des pièges plus rapidement et d'aller plus vite. Il faut aussi évidemment le faire au bon moment.

C'est très intéressant de noter que le début et la fin d'un projet sont des moments assez clés. Je vous ai mis là quelques citations d'un ingénieur de chez Dropbox. qui dit que pour lui c'est très important de faire équipe avec son product designer avant même que le product designer fasse des design reviews avec les autres designers, que c'est un moyen pour lui d'être efficace. Et puis qu'il aime bien carrément s'asseoir avec le designer à la fin pour vraiment polir les derniers détails ensemble et que c'est ce qui lui permet de bien travailler. Le dernier challenge que je voulais évoquer, et non des moindres, c'est celui de la créativité. Et là, quelle que soit la... La culture du design dans l'entreprise, l'organisation que vous avez mis en place, les pratiques collaboratives dont on vient de parler. Il y a de nos jours un truc qu'on ne peut faire qu'observer, c'est un espèce de phagocytage de l'activité de design pour la transformer en quelque chose de l'ordre de l'usine. Alors là, j'ai pris une super photo, mais c'est moins beau que ça dans la réalité. Ce n'est pas très glorieux. On est quasiment dans quelque chose de tayloriste.

Marie, à ce propos que j'ai interrogé en interview, me dit que, de son point de vue, et je la rejoins, un product designer aujourd'hui, c'est un soldat. Or, on a besoin de la créativité. C'est ce qui permet de développer des choses dont on est fier. Ça permet de prendre du plaisir dans l'activité de design, donc de conserver ses designers. Et quand on connaît les turnovers actuels dans les entreprises tech, ce n'est pas rien. Un caractère pénurique du marché du recrutement. Et puis, ça permet de se différencier dans une industrie qui est très standardisée. Léa Mendes da Silva chez Payfit insiste sur un point très important, ça me permet de reboucler avec l'organisation de la diversité dans une équipe et du fait que c'est un moyen de réussir à être plus créatif. Parce que quand tout le monde pense de la même manière, évidemment que tout le monde va générer plus ou moins les mêmes idées, c'est difficile d'innover. Entre guillemets. Une organisation en squat très efficiente, tournée vers l'exécution de tâches, ne pourra jamais accueillir cette diversité.

qu'est un... Un rapide récap de tout ce qu'on a vu ensemble. Culture d'abord, parce que plutôt que convaincre par la théorie, on va l'essayer d'aller prouver par l'exemple, par le projet. Pensez l'organisation des équipes design dans l'organisation de l'entreprise. En fait, designer son organisation design. Troisièmement, reconnaître qu'un des sujets clés, c'est la collaboration. Parce qu'au-dessus de tout, finalement, on travaille avec de l'humain. Et donc s'intéresser à la relation, à être ensemble. Et puis dernier point, revenir à un fondement du cheminement design. Et bien sûr, adopter les méthodes et les process qui nous permettent d'être plus efficients. Mais ne pas oublier la base et s'assurer qu'on se donne les moyens de rester dans cette énergie créative. Voilà, j'en ai terminé. Merci beaucoup d'avoir assisté à cette conférence et puis on se retrouve pour vos questions.