3 retours d’expérience de Design System réussis dans le domaine B2B

Use Design for design system

3 retours d’expérience de Design System réussis dans le domaine B2B

3 retours d’expérience de Design System réussis dans le domaine B2B 1375 974 Use Design

Si l’on parle facilement de la nécessité et de l’intérêt de mettre en place un Design System pour toute plateforme digitale grand public, nous savons chez use.design, pour en avoir réalisé plusieurs dizaines, que cet outil s’avère également précieux dans le domaine des applications professionnelles.

En voici 3 exemples, 3 petites histoires, qui au travers de leurs contextes et enjeux spécifiques, vous aideront à comprendre pourquoi il vous sera utile de développer et mettre en oeuvre un tel chantier avec vos équipes produit, design et développement.

Le premier retour d’expérience de Design System se focalise sur l’angle du besoin utilisateur, le second sur l’angle des équipes produit/développement, et le troisième sur le contexte des méthodologies Agile.

TECHNIDATA, ou comment un Design System peut porter la diversité des expériences utilisateurs

Avant que le terme Design System n’apparaisse ces dernières années, on parlait pour une interface utilisateur plus facilement de “Graphical or Design Guideline”. C’est donc en ces termes que notre équipe de designers a imaginé pour TECHNIDATA de développer une grammaire d’interface commune, tant du point de vue graphique qu’ergonomique, pour un ensemble d’applications de santé.

Un Design System pour de multiples supports d’interaction

Le point de départ est un simple constat, celui du besoin utilisateur :
Dans ce domaine de la santé, et plus particulièrement le contexte de l’hôpital, on sait en effet le peu de temps que les personnels de santé peuvent prendre pour se former aux nouveaux outils digitaux.
Leur besoin est donc de disposer d’application dont les interfaces leurs soient suffisamment intuitives, simples à appréhender, et surtout proposant une courbe d’apprentissage la plus rapide possible.
Et idéalement que ces mécanismes de découverte, d’apprentissage et d’utilisation, soient consistants d’une application à l’autre.
On réduit ainsi pour l’utilisateur la frustration d’avoir à ré-apprendre, et on gagne en confiance et en autonomie.

Au delà de l’univers graphique à imaginer et décliner, au delà des grands principes de navigation et d’interactions, les designers ont donc posé leurs objectifs au travers de la reformulation suivante :
Comment pourrait-on proposer des principes d’interface “universels” ? communs et reproductibles d’une application à une autre ?

Universels, au sens plus modeste dans le cas de TECHNIDATA, de la richesse de ces solutions applicatives (scope fonctionnel, contexte d’utilisation, supports et modes d’interactions, cible marché et profils utilisateurs).

Exemple de Design Guidelines qui cartographie les principes graphiques et ergonomiques

Le résultat s’est donc concrétisé par la création et la déclinaison d’un Design System sur 4 applications qui chacune développent une variante :

  • d’une architecture visuelle illustrant les niveaux de navigation = pour ainsi rendre intuitif (après le premier apprentissage) les modes de navigation et d’interactions quelle que soit l’application,
  • d’une gamme de couleurs pour les blocs et composants = pour ainsi structurer les écrans et favoriser la compréhension des messages,
  • d’un univers iconographique approprié au contexte métier et le plus figuratif possible = pour ainsi renforcer la connivence avec le domaine et les fonctions métier.

Restait donc aux équipes TECHNIDATA à implémenter ce Design System à l’occasion d’un chantier de refonte technologique ou plus modestement d’un “relooking”. Cependant, pour chacun de ces chantiers, la tâche n’avait rien de triviale. Car non seulement, les nouveaux principes ergonomiques nécessitaient de profonds changements du code, mais comme chaque logiciel disposait de son Framework/Language de développement, il fallait reconsidérer pour chaque implémentation les manières d’intégrer ces nouvelles spécifications ergonomiques et graphiques.

Cela représentait donc des chantiers coûteux en temps et en ressources. Je parle au passé car ce projet date d’il y a près de 10 ans, et depuis les choses ont bien changé, et nous le verrons dans le prochain exemple, si la technologie est unifiée, comme le permet par exemple Angular, le travail en est grandement facilité.

SUEZ Aquadvanced, ou comment faire naître et rendre vivant un Design System pour une équipe produit/développement

L’eau est une ressource précieuse, et sa gestion une expertise du quotidien, tant en amont pour la production d’eau potable, qu’en aval quand il s’agit de la retraiter. C’est sur ce secteur que SUEZ propose une gamme complète de solutions métiers destinées aux acteurs de la gestion d’eau et en particulier des collectivités locales.
Regroupées sous la marque Aquadvanced, ces applications venues d’horizons différents (sous domaine métier, pays et industriel, technologies, chaîne de valeur client) concourent toutes à aider le gestionnaire à maîtriser la ressource et à en sécuriser la distribution.

Une salles de supervision d’un réseau de gestion d’eau potable

Hors aujourd’hui ce gestionnaire veut avoir la maîtrise de la chaîne entière, pour mieux analyser le cycle de l’eau et ainsi mieux informer et servir ses usagers. Les équipes produit SUEZ ont décidé de construire sur cet insight pour développer une nouvelle ligne produit où l’ensemble des applications seraient unifiées dans leur expérience utilisateur (et leur technologie), pour offrir ainsi aux exploitants un outil moderne, performant et unifié.

Et pour cela, il fallait bâtir un Design System résolument orienté métier, et donc solide, mais tout à la fois “élastique” afin de porter les évolutions futures.
Car pour un acteur comme SUEZ, rien n’est jamais figé. La suite Aquadvanced se construit brique par brique, dans un temps qui doit tenir compte des évolutions sans cesse renouvelées des besoins clients.

Le Design System en cours d’élaboration et mise à disposition sur la plateforme caravel.design

La copie d’écran ci-dessus est une démonstration de l’utilisation de notre outil de gestion de projet UX caravel.design, afin de faciliter la mise en place et le suivi d’un projet de Design System.

Au delà du besoin utilisateur donc, que l’on a pu analyser dans le précédent retour d’expérience avec TECHNIDATA, ici l’enjeu fort est également en interne. En effet, comment garantir aux équipes produit et développement :

  • les bases d’une bonne compréhension de l’expérience utilisateur (profils, besoins, motivations attentes) ?
  • une bonne compréhension de l’état de l’art existant (historique métier et technologique, besoins spécifiques) ?
  • une force de proposition pertinente pour les architectures d’interface, et la diversité des composants à imaginer ?
  • la création d’une identité d’interface à la hauteur de la qualité de la marque SUEZ ?
  • une intégration des parties prenantes de manière à engager un état d’esprit “Design System” côté produit et côté développement ?
  • un suivi dans la durée par une “core team” à même d’assurer les évolutions design et techniques nécessaires ?

Ce sont certains des défis que notre équipe de designer s’est posée, et à réussi avec une équipe chez SUEZ motivée et engagé dans cette nouvelle vision de Design System.

Le Design System finalisé avec des exemples de déploiement sur divers applications

Une des réussites du projet est également passée par… une personne, un lien privilégié. Non pas un designer, mais un profil hybride chez SUEZ, développeur Front d’origine, il a su prendre en main le sujet, pour en assurer son expertise première : l’intégration du Design System dans Angular.
Mais aussi, il en fait un outil technique vivant, qu’il peut faire évoluer au fil des besoins des équipes produit (PO, Marketing).
Et surtout, au delà des outils, il assume pleinement son rôle d’animateur, qui rend le Design System vivant auprès de tous.
Est-ce les prémisses d’un nouveau rôle dans les entreprises ? Le Design System Manager ?
C’est effectivement le questionnement actuel des équipes Design chez BlaBlaCar présenté lors de la conférence UXdays en juin dernier.

Un an à peine après les premiers entretiens terrain avec des exploitants, les équipes SUEZ déployaient la première déclinaison du Design System sur quelques applications et pouvaient ainsi en découvrir tous les bénéfices, tant par les retours positifs des clients, que ceux de toutes les parties prenantes en interne.

THALES TopWings, ou comment développer un Design System complexe au travers d’une méthodologie Agile

Mettre en place et animer un Design System est un défi majeur, et nécessite un temps important, en particulier pour une expérience digitale riche et complexe. C’est un défi pour toutes les équipes de poser les bases tant UX que UI de ce que sera la future expérience client / utilisateurs digitale, puis de co-créer, de réaliser, d’implémenter, et de faire vivre. Et on voit déjà dans cette phrase, que les différentes étapes nécessaires, peuvent être fortement engageantes pour les équipes, dont les designers.

Le parcours utilisateur comme point de départ du scope de Design System à réaliser

Alors imaginez…

Que nous ne soyons pas sur ce “classique” cycle en V, mais sur une méthodologie Agile (type Scrum), ou comme il se doit – et là où est toute sa puissance – tout bouge suivant les Sprints, les itérations de conception, de développement et d’évaluation…

ET où vous n’avez pas 1 équipe, mais 5 à 9 en fonction des périodes, car le périmètre fonctionnel et les enjeux produits sont gigantesques…

ET que vous démarrez de ZERO, car il n’y a pas d’existant, ni fonctionnel, ni UX, ni UI ou de Direction Artistique…

Voilà un défi comme on les aime chez use.design !!!

ET ce défi, pour le résumer en un phrase, c’est bien une gageure : Comment peut-on concilier les principes du Design System (pérennisation, structuration, règles, normes, principes, gammes) alors que l’Agile, n’est que le juste contraire ? C’est à dire un château de sable – mouvant – que vous devez reconstruire à chaque ressac de la marée…

Les interactions sur les écrans types du Design System en cours de définition

Pour ce projet avec THALES, qui traite d’une super application d’EFB (Electronic Flight Bag), le dossier de vol digital du futur du pilote d’avion de ligne), nous avons pris le parti chez use.design de poser certaines bases solides afin d’éviter ces “sables mouvants” :

  • plusieurs équipes pour traiter toute la richesse fonctionnelle = 2 à 3 équipes chez nous sur 6 à 8 mois, constituées de 2 UX Designer super Sénior ;
  • un super héro de la UI = super senior + super expert des IHMs métier et aéronautique + adepte des fondamentaux du Design System,
  • s’appuyer sur des PO forts (sénior, et hyper expert du domaine métier) afin d’assurer la préparation / suivi des Sprint, rédaction des User Story avec les représentants des utilisateurs, et contact en temps réel avec les équipes de développement ;
  • assurer un lien virtuel (car équipes à divers endroits en France) au moyen d’une plateforme de suivi projet (JIRA + CONFLUENCE), et d’outils de maquettage et prototypage (Sketch + InVision + Prototypes iOS sur mesure) ;
  • Se rencontrer régulièrement en présentiel pour garder le lien, désamorcer les points de fiction projet, co-créer…

Le défi d’un Design System décliné sur divers dispositifs interactifs

La clé du succès me demanderez-vous ?
Elle n’est pas unique selon nous, mais dépend bien évidemment de ces solides bases posées plus haut. Et surtout elle réside dans une question d’équilibre.
Un parfait équilibre à trouver entre rigueur et flexibilité. Cet équilibre est dur à trouver car, comme je le disais, Design System et Agilité, ne sont pas nées pour faire bon ménage.

Mais comme rien n’est inné à la naissance, il vous faudra engager vos équipes (designers, PO, développeurs), à acquérir cette flexibilité au fil des Sprints.

Par exemple, que chacun puisse personnellement se remettre en question, au sens, faire preuve d’élasticité dans ses propos : passer de “non, ce composant est défini comme cela dans le Design System, c’est une règle…”, à “oui, pourquoi pas le faire évoluer de cette manière, je vais essayer…”. Se tenir prêt à dialoguer, en mode “et si…”, plutôt que “fais pas ci, fais pas ça…”

Et cela doit passer par un (très) bonne dose de confiance mutuelle. Si l’on considère ce triptyque (designers, PO, développeurs), alors les 3 doivent être mis au même pied d’égalité, par les managers et décideurs. Il ne doit pas y avoir de petit rôle, d’expertise de second ordre.

*A propos du Design System :

Pour ceux qui voudraient découvrir le Design System, de (très très très) nombreuses publications sont disponibles. En voici quelques-unes – sélection personnelle parfaitement subjective – pour débuter cette découverte :

Et bien sûr notre blog www.use.design sur lequel nous publions régulièrement des articles sur ce sujet… et bien d’autres !


Patrick Avril — CEO  @ Use Design, une agence de design à Paris qui donne vie à des stratégies, des produits digitaux et des services innovants.
Dites-nous qui vous êtes et ce qui vous ferait plaisir. Pensez à nous laisser un email et/ou un numéro de téléphone, comme vous préférez, et on vous recontacte rapidement 😉