Comment avons-nous conçu Shipyard, notre Design System ?

Votre produit est fonctionnel mais vous ne le trouvez pas très séduisant ? Alors, nous nous sommes sans doute posé les mêmes questions ! Pourquoi chercher à rendre beau un produit qui fonctionne très bien tel qu’il est ? Comment garantir la meilleure expérience à nos utilisateurs tout en simplifiant la conception produit ? Chez Captain Contrat, designers et développeurs se sont alliés pour mettre en place Shipyard, notre Design System.

Gautier Zimmermann
Captain Contrat Tech
7 min readJan 28, 2020

--

Voici Shipyard !

Dans cet article, je reviens sur la façon dont l’équipe Design de Captain Contrat a créé son Design System.

Si vous vous demandez pourquoi nous en avons créé un, Martin, développeur chez Captain Contrat, vous explique les raisons qui nous ont poussé à créer notre Design System.

Si vous êtes intéressé.e par l’implémentation du Design System du côté de l’équipe tech, il va falloir patienter, l’article arrive bientôt 😉

Vous n’avez pas les bases

Quand je suis arrivé chez Captain Contrat, la première chose qui m’a frappé, c’était le manque d’homogénéité entre les interfaces. L’expérience était relativement la même entre chaque écran, mais les polices d’écriture pouvaient varier d’un écran à l’autre, tout comme le rouge qui symbolise notre marque. Il en était de même dans nos outils : à chaque nouvelle maquette, les couleurs, les espaces ou les typographies étaient nouvelles.

Il étaient donc temps de repartir sur des bases simples.

Les couleurs

La décision fut radicale sur ce point : nous avons décidé de nous séparer de toutes nos couleurs existantes à l’exception de 2, le rouge et le doré de notre marque.

Puis, nous avons décidé de créer 7 palettes de couleurs de 10 nuances chacune :

  • Neutre
  • Rouge
  • Doré
  • Bleu
  • Vert
  • Orange
  • Violet

Si vous avez bien suivi, nous avons parlé de créer des bases simples et nous nous retrouvons avec 70 couleurs différentes. On a connu plus clair !

Pourtant, c’était le meilleur choix pour nous : il nous permet d’avoir dès le début l’ensemble des couleurs que nous utiliserons pour nos interfaces, mais également les couleurs pour l’aspect “marketing” (illustrations, code couleurs pour nos offres, etc.).

D’un point de vue purement produit, nous n’utilisons que 9 de ces couleurs pour nos interfaces.

Ce que nous avons retenu de la création de nos couleurs :

  • Le naming est TRÈS IMPORTANT.
    Il servira à vous comprendre entre designers, mais il vous permettra surtout de parler la même langue avec les développeurs. Nous avons très vite abandonné le système “darker-red > dark-red > red >…” qui était incompréhensible (et très peu scalable), pour nommer nos couleurs comme la graisse des polices d’écriture : Red900 > Red800 > Red700… Ce choix n’est pas sorti de notre chapeau, il a été le fruit de longues discussions avec les développeurs pour aligner tout le monde en amont.
  • Pour chaque couleur, choisissez une couleur principale (par exemple Red500). A partir de cette couleur vous pourrez trouver vos variantes plus claires et plus sombres facilement.
  • N’oubliez pas l’accessibilité. Chez Captain Contrat, plusieurs équipiers sont daltoniens. Vous imaginez donc bien qu’avez le rouge comme couleur principale, nous devons faire attention à ce que chacun puisse lire notre interface facilement.

Pour vous aider dans votre travail, je vous recommande l’outil Leonardo.

Les polices

Nous avons été encore plus radicaux en ce qui concerne les polices d’écriture. Nous les avons toutes remplacées au profit d’une unique : Nunito. Nous avons limité le nombre de graisse à 3 : Regular, Semibold & Bold.

Puis nous avons posé 3 règles :

  • La police de base a une taille de 16px — pour être facilement lisible sur desktop et mobile — et les autres tailles varient de 2 à 4px en fonction de cette taille de base
  • La hauteur entre chaque ligne a un ratio de 1:1.5, afin de faciliter la lecture des personnes atteintes de déficience visuelle ou de troubles de la lecture comme la dyslexie. Pour les titres, ce ratio est de 1:1.25.
  • Une ligne de texte doit faire de 80 à 100 caractères maximum, là encore pour simplifier la lecture.

Grâce à ces règles, nous avons pu déterminer la taille de nos titres sur mobile et desktop.

Ce que nous avons retenu de la création de nos polices :

  • Réfléchissez bien à la taille de votre police de base et aux hauteurs de ligne. Ces points peuvent sembler anodins, mais ils vous feront gagner un temps précieux par la suite. Tout en rendant votre interface plus lisible !

Les espacements

Les espacements sont un enfer. Surtout pour les développeurs. Il suffit d’un décalage, même insignifiant, sur une maquette pour créer une multitude de questions. C’est aussi un enfer pour les designers pour créer une régularité et une facilité de lecture sur les interfaces.

Pour cela, nous avons décidé de partir sur une grid de 8px. Je ne vais pas m’étendre sur ce choix, la littérature est déjà largement suffisante là dessus.

Maintenant, il faut déterminer les espacements que l’on va intégrer dans nos designs. Nous en avons choisi 5:

  • 4px
  • 8px
  • 16px
  • 32px
  • 64px

Nous avons opté pour une progression exponentielle des espacements, plutôt que linéaire pour une bonne raison : ne pas nous prendre la tête entre 16, 24 et 32 px lorsque l’on fait une maquette. Ces espacements sont très proches et ne permettent pas de faire un choix facilement. En supprimant 24px de la liste, tout devient plus simple.

Pour en savoir plus sur notre choix :

Ce que nous avons retenu de la création de nos espacements :

  • Les espacements sont probablement la chose la plus essentielle pour vos interfaces et pourtant ils sont souvent négligés. Ce sont eux qui vont rendre vos interfaces lisibles et respirables ou au contraire illisibles et compactes.
  • Prenez le temps de faire des tests et de vous renseigner. C’est ce que nous avons fait et nous n’avons désormais plus de questions entre designers et développeurs sur les espacements voulus.

Les ombres et les icônes

Passons rapidement sur les deux dernières bases de notre design system.

Pour gagner du temps nous avons décidé de suivre les recommandations du livre Refactoring UI pour l’implémentation des ombres.

En ce qui concerne les icônes, nous avons décidé de créer les nôtres afin d̶’̶e̶n̶ ̶f̶i̶n̶i̶r̶ ̶a̶v̶e̶c̶ ̶F̶o̶n̶t̶ ̶A̶w̶e̶s̶o̶m̶e̶ renforcer la personnalité de Captain Contrat sur notre interface. Pour faire comme nous, je vous recommande l’article suivant :

Et maintenant ?

Maintenant que nous avons les bases, il est temps de créer des composants ! Rassurez-vous, je ne vais pas rentrer dans le détail de la création de chaque composant. Je vais plutôt vous expliquer, dans les grandes lignes, la méthode que nous avons suivi :

  • Nous avons appliqué la méthode de EightShapes pour choisir les composants que nous devions réaliser en priorité, ceux qu’il faudrait que l’on ait à terme et ceux qui ne nous serviront jamais.
  • Nous nous sommes enfermés dans une salle avec Guillaume, également Product Designer chez Captain Contrat, et nous avons créé ensemble chaque composant sur Figma.
  • Nous avons ensuite documenté l’ensemble des composants pour expliquer à quoi ils servent, quand et comment les utiliser, et comment les intégrer côté devs. Ne négligez pas cette partie, elle vous évitera par la suite des casse-têtes du type “Ah mais on ne devait pas utiliser ce composant comme ça ?” → Non c’est expliqué dans la documentation.
Exemple de documentation dans Shipyard
  • Pour l’intégration, nous avons décidé de la faire progressivement. A chaque fois qu’un écran évolue, nous en profitons pour intégrer les nouveaux composants créés. Mais ça nous en parlerons dans un autre article 😉

Au moment où j’écris ces lignes, cela fait 5 mois que nous avons mis en place notre Design System. Ce dernier nous a déjà permis de gagner un temps précieux lors de la conception et l’implémentation de nouvelles fonctionnalités. Il nous a également permis de réduire drastiquement nos débats sur des détails insignifiants d’interface pour nous focaliser sur l’amélioration de l’expérience de nos utilisateurs.

Bien sûr, tout n’est pas encore parfait et nous aimerions aller plus loin : ajouter les illustrations à notre Design System, le tone of voice et bien plus encore. Mais cela arrivera et on écrira un nouvel article à cette occasion !

Cet article vous a plu ? N’hésitez pas à 👏👏👏

Découvrez également pourquoi nous avons mis en place notre Design System :

--

--