Dans les coulisses du Design System de Nokia

Frédéric Audet est Lead designer en charge du Design System chez Nokia. Après avoir débuté sa carrière au sein d’agences traditionnelles et numériques, il crée son entreprise avec l’objectif d’aider les startups à lancer leurs produits numériques. Suite à la vente de cette dernière, il accepte un poste chez Shopify où il peut rassembler toutes ses passions : l’entrepreneuriat, la résolution de problème et le design de produit numérique. C’est à ce moment qu’il découvre une nouvelle passion : créer et gérer un Design System pour grande entreprise. Avec l’intérêt de continuer dans cette direction, il accepte l’opportunité d’aider Nokia à implanter un Design System en tant que produit et stratégie organisationnelle.

Peux-tu te présenter et nous expliquer quel aspect de ton travail tu affectionnes le plus ?

Travailler sur un Design System comme celui de Nokia est assez intéressant étant donné l’ampleur de notre clientèle. La diversité et la polarité des projets contribuent à créer une aventure très enrichissante et stimulante. Nokia produit des logiciels qui permettent aux différents fournisseurs en télécommunication tels que Verizon, Bell, AT&T, Vodafone, etc. de gérer leurs réseaux afin de maintenir une qualité de service. Le Design System est utilisé par plus de 100 applications très spécifiques produites par des centaines d’équipes à travers le monde.

J’affectionne particulièrement la diversité et le challenge qui vient avec ma responsabilité. De plus, tous nos systèmes ont été très récemment convertis en React, donc beaucoup de travail à faire !

Je n’ose pas imaginer l’ampleur de votre Design System. Quels sont vos principaux challenges et comment y faites-vous face ?

Mon challenge principal est vendre l’importance du design à l’interne. Le ratio entre designer et développeur est largement disproportionnel, ce qui a crée une culture de “feature first” ou de style “waterfall”. Une culture où l’on accorde plus d’importance à sortir des applications au lieu de s’assurer que ses applications sont une solution à un, ou des problèmes bien définis et mesurables. Je dois faire face à des business units qui mesurent le succès de manière différente; à des équipes qui obtiennent plus de budget annuel s’ils sortent plus d’applications, etc.

Mon objectif est de donner aux non-designers les outils pour prendre les bonnes décisions.

Une personne à elle-même ne peut pas éduquer autant de différentes équipes sur l’importance de mettre l’utilisateur au centre. Les designers ne sont pas les seuls qui prennent des décisions qui ont un impact sur l’utilisateur. Les PM, les ingénieurs, les développeurs, les researchers, ils contribuent tous à créer une expérience. Je travaille actuellement sur une nouvelle plateforme qui aura comme but de rassembler nos valeurs corporatives, nos projets de recherche et qui aura plusieurs sections dédiées aux “guidelines” pour aider à uniformiser nos conseils et pratiques. Mon objectif est de donner aux non-designers les outils pour prendre les bonnes décisions.

L’autre défi est de devoir maintenir plusieurs versions d’un même système. Certains de nos clients ont négocié un support constant des versions antérieures de nos applications, donc nous devons supporter des composants plus anciens. Croyez-moi, ce n’est pas simple du tout ! Il n’y a pas de solution miracle à ce problème, mais l’ajout d’ Abstract à notre workflow d’équipe UX a été très pratique pour ajouter la notion de versioning à notre travail. Les différentes branches sur Git sont directement liées à des branches d’Abstract et contribuent à conserver cette parité design-code.

Comment collaborez-vous avec les autres équipes ? Par exemple, comment décidez-vous d’intégrer ou non des composants conçus par ces équipes ?

Je viens justement d’implémenter un nouveau processus de collaboration. Les différentes équipes auront toujours des besoins différents, mais cela ne veut pas dire que nous devons implémenter chacune de ses idées en Core Components !

Voici un aperçu du processus :

• La personne responsable doit comprendre le problème qu’il tente de résoudre et être en mesure de l’articuler clairement à un auditoire mixte.
• La personne responsable doit présenter des pistes d’explorations utilisant des composants du système. L’idée ici est de nous aider à comprendre le pourquoi de la demande initiale.
• Est-ce qu’il est possible de résoudre le problème avec un composant qui existe déjà ? Est-ce qu’il est possible de modifier un composant actuel afin d’en arriver au même résultat ?

Si le système est incapable de répondre au besoin, je demande à la personne responsable de produire un document avec les éléments suivants :

• Pourquoi (why) : Pourquoi devons-nous explorer un nouveau composant ?
• Quoi (what) : Quelle est la proposition ? Une élaboration exhaustive du composant qui devrait être produit avec la notion de “System Thinking” (une exploration basée sur plusieurs scénarios d’utilisation).
• Comment (how) : Comment cela sera implémenté ? Quelles seront les variantes possibles ?
• Interaction (behaviour) : Comment l’utilisateur va interagir avec le composant ? J’aime voir des prototypes !

Nous analysons le document et procédons à une analyse d’implémentation en nous demandant si le nouveau composant règle seulement un problème, ou plusieurs problèmes ?

• Si le composant règle seulement un cas spécifique, Core (mon équipe) assistera à la production du composant, mais il ne sera produit par l’équipe qui a fait la demande et ne fera pas parti du Design System.
• Dans le cas où le composant pourrait régler plusieurs problèmes, nous l’adopterons à Core, donc dans le Design System. Mon équipe sera en charge de son développement et nous aurons une collaboration étroite avec la personne qui a fait la demande initiale. Dans ce cas, je tente de laisser le designer terminer son travail, j’assiste seulement pour m’assurer que tout est bien produit.

Imaginons que tu puisses tout recommencer “from scratch” que ferais-tu de différent et pourquoi ?

Feedback Loops & Metrics

Dès le début, j’aurais débuté par tenter de comprendre les points de frictions des différentes équipes de développement. Nous n’avions aucune donnée et aucune manière logique de déterminer les priorités de notre équipe. Un Design System est supposé permettre aux designers et développeurs de conceptualiser une idée plus rapidement. Comment pouvons-nous accomplir cela si nous ne comprenons pas les points faibles du système actuel?

À mon arrivée, j’ai beaucoup travaillé pour convaincre les gens de l’importance de mesurer l’impact de notre travail. Une tâche longue et ardue, mais après quelques semaines nous avons implanté un système où nous pouvons mesurer nos efforts afin de calculer notre progrès. J’aurais bien aimé que ce soit fait dès le début.

Comme tout projet, j’ai débuté par définir l’opportunité et clarifier le problème: Comment l’équipe Core devrait mesurer son impact dans l’organisation ? Progressons-nous ? Comment se porte l’adoption des composants ? Nous n’en avions aucune idée !

Maintenant, tous les mois nous mettons une liste à jour et l’envoyons à l’organisation. Je crois en la transparence !

Quelques éléments clés :

• La quantité des applications qui utilisent nos composants.
• La quantité des styles qui sont encore inline dans le code.
• La quantité des composants à refaire pour supprimer la dépendance Material.
• La quantité des symboles Sketch en parité avec le stack React.
• Comparaison des composants les plus/moins utilisés? (avec tendance).
• Le taux d’adoption globale des différentes version du Design System.
• La quantité de bugs (issus) générés suite à une release.
• Etc.

La liste continue, mais le but et de réviser cette liste avec l’équipe et mesurer selon certains KPIs.

Nous ne devrions jamais prioriser en fonction de la personne qui crie le plus fort dans la pièce, mais plutôt suivre un processus de développement.

Il y a une façon très simple d’aider à prioriser les efforts. Tout projet peut entrer dans l’une de ces catégories :

1. High impact, low effort
2. Low impact, high effort

Malheureusement beaucoup trop de projets entrent dans la deuxième catégorie. Nous ne devrions jamais prioriser en fonction de la personne qui crie le plus fort dans la pièce, mais plutôt suivre un processus de développement. J’aurais bien aimé implanter ces processus dès le début !

Outils

Historiquement, la culture a été de laisser au designer la liberté des outils à utiliser. Le résultat est… désastreux ! Nos projets sont conçus avec Illustrator, Photoshop, Sketch et InDesign (oh oui). Imaginez la perte de temps pour tout convertir en symboles Sketch !

Nous utilisons maintenant Sketch/Abstract et je tente secrètement de nous convertir à Figma :)

Aurais-tu un dernier conseil pour conclure ?

Un aspect qui est super intéressant et qui n’existait pas quand j’ai débuté ma carrière il y a quelques années est le concept d’internship en grande entreprise. L’opportunité de faire partie d’une équipe, de poser des questions, de collaborer avec des designers d’expérience et même de tisser des liens avec des gens de l’industrie est priceless. Obtenir un poste en grande entreprise n’est pas simple, mais obtenir une opportunité d’internship est beaucoup plus facile !

Une expérience digitale est bien plus qu’une composition graphique de 1440*1080px.

Le cheminement de ma carrière a débuté en agence traditionnelle à concevoir des systèmes de branding pour petites entreprises, pour ensuite évoluer en agence numérique. Wow, quel changement ! Nous pouvons maintenant jouer avec les éléments graphiques et créer des expériences immersives. Dès lors j’ai compris l’importance du storytelling. Une expérience digitale est bien plus qu’une composition graphique de 1440*1080px.

J’ai ensuite crée mon entreprise où j’ai appris à gérer une équipe (plus de 20 employés). C’est à ce moment que j’ai compris l’importance de la présentation et de bien comprendre et d’écouter le besoin du client. L’embauche était un concept totalement nouveau pour moi. Gérer une entreprise créative n’est pas chose simple, mais extrêmement stimulante ! Ensuite, j’ai eu des rôles de designers senior/lead dans de grandes entreprises en Product Design. C’est à ce moment que j’ai compris l’importance de la collaboration, communication et design thinking (user empathy).

Évidemment, je suis biaisé sur le sujet, mais je recommande à tout designer de vivre l’expérience de l’agence au moins une fois dans sa vie. La pression, les projets créatifs, les longues heures… Si vous êtes passionné, vous allez adorer ! De plus, c’est une très belle manière de bâtir un portfolio.

N’hésitez pas à chercher de l’aide, ou même trouver un mentor.

Pour moi, un bon designer c’est :

• Quelqu’un qui est en mesure d’articuler clairement le pourquoi de son projet
• Quelqu’un qui est en mesure de demander de l’aide au lieu de s’improviser expert
• Quelqu’un qui est capable de présenter une idée clairement à un groupe
• Quelqu’un qui explore plusieurs options avant de décider d’une direction
• Quelqu’un qui a une empathie naturelle
• Quelqu’un qui sait interpréter une idée en concept visuel simple et engageant
• Quelqu’un de curieux qui cherche constamment à apprendre
• Quelqu’un qui cherche à comprendre l’impact qu’aura son projet sur le système (system thinking)
• Quelqu’un qui a une bonne confiance en ses capacités
• Quelqu’un qui sait adapter son ton verbal selon l’auditoire
• Quelqu’un qui sait bien écouter
• Quelqu’un qui comprend qu’un design n’est pas seulement qu’une belle interface

Pour terminer, je tiens à mentionner que tout au long de votre carrière, vous aurez des défis à relever. N’hésitez pas à chercher de l’aide, ou même trouver un mentor. Cette personne pourra vous ouvrir les yeux et aider à faire les choses d’un angle différent.

Bonne chance !

The Design Crew vous forme au Product Design. Nous vous proposons une journée dédiée au Design System. Venez en apprendre la conception auprès de Nicolas Duval, Lead Designer chez Blablacar.