Alors, qu’est-ce qu’un système de design ?
Un système de design peut être défini comme une collection de composants qui sont régis par des directives claires d’utilisation au sein d’un produit ou d’un ensemble de produits.
Un système de design entièrement développé contient à la fois des éléments tangibles et intangibles. Du côté tangible, vous avez les bibliothèques de composants, à la fois pour les éléments UX/UI et le code. Ce sont les principaux blocs de construction que les designers et développeurs peuvent utiliser, réutiliser, et réutiliser encore et encore tout au long du cycle de vie entier de votre produit. Nous les explorerons plus en détail dans un moment.
Du côté intangible, vous avez non seulement les directives de mise en œuvre, mais aussi les raisons derrière le système que vous avez développé - le « pourquoi » du système. C’est essentiel pour l’adoption du système et pour s’assurer que tout le monde dans l’équipe est sur la même longueur d’onde.
Par-dessus tout cela se trouve la gouvernance globale du système de design. Ce sont les politiques et procédures qui guident comment le système est mis à jour pour s’assurer que le système de design évolue avec les besoins de votre organisation et produit.
Éléments d’un système de design
Tout système de design que vous implémentez est vraiment la somme de ses parties. Généralement, vous pouvez trouver les éléments suivants dans la plupart des systèmes de design.
Objectif et buts
C’est la partie « pourquoi » du système - pourquoi avez-vous même un système de design ? Quel est l’objectif et que visez-vous à accomplir ? Comment bénéficiera-t-il au produit en cours de développement, à l’entreprise dans son ensemble, et, encore plus important, comment bénéficiera-t-il à ceux qui utilisent le système et facilitera-t-il leur vie ?
Avec des objectifs et buts définis pour le système, vous alignez tous ceux impliqués dans le processus de design et développement. Cela favorise également l’adhésion et aide à s’assurer que les gens implémentent réellement le système de design.
Langage de design visuel
Avec tout système, vous avez besoin d’un langage commun. Ce sont vraiment les blocs de construction de base à partir desquels vos designers travailleront et que vos développeurs implémenteront en code.
- Couleur : Quelles sont les couleurs primaires qui seront utilisées dans tout le produit, et quand et où seront-elles utilisées ? Par exemple, un seul bouton pourrait avoir trois couleurs différentes : initial, survol et cliqué. Celles-ci doivent être implémentées de manière cohérente.
- Imagerie : Directives pour le type et le style d’icônes, illustrations, et autre imagerie visuelle qui sera utilisée dans tout le produit. Une fois créées, celles-ci siégeront dans votre bibliothèque de composants UI (voir ci-dessous), mais cela servira votre équipe de design quand le besoin de nouvelles se présente.
- Typographie : Ce n’est pas seulement le nom de la police qui sera utilisée, mais aussi les différentes tailles, poids, couleurs et styles. Différentes combinaisons seront utilisées dans différentes zones, et sur différentes plateformes, et vous voulez être sûr que c’est cohérent dans tout votre produit.
- Dimensionnement et espacement : C’est incroyable à quel point le dimensionnement et l’espacement affectent le design de votre système. Ici, la plateforme pour laquelle vous construisez aura des impacts significatifs - l’espace disponible sur un smartphone est très différent d’une application desktop.
Bibliothèque de composants UI
Ceci est souvent appelé une bibliothèque de motifs car vous implémentez différents motifs, ou groupements de composants, dans différentes situations. Ce que vous voulez éviter c’est prescrire une mise en page pour chaque page de votre application. Cela résulte en un cauchemar quand vous ajoutez une nouvelle fonctionnalité car vos designers devraient alors mettre à jour chaque page affectée. Au lieu de cela, vous avez chaque élément comme un composant singulier, et puis des exemples de comment les éléments sont exécutés ensemble. Consultez le travail de Brad Frost sur l’Atomic Design pour d’excellents exemples de comment cela peut être exécuté.
Bibliothèque de composants de code
Quels éléments de code pouvez-vous componentiser qui peuvent être réutilisés, surtout en ce qui concerne le design du produit ? À un niveau simple, si vous implémentez toujours un bouton ou une liste déroulante de la même manière, ils devraient être componentisés pour que les développeurs puissent les implémenter rapidement sans avoir à recoder ces mêmes éléments encore et encore. Comme tout code que vous développez, ceux-ci seront versionnés.
Documentation
Ce sont les directives écrites de comment et quand les composants UI et Code de votre système de design seront implémentés. La documentation est un élément clé de votre système qui vous sépare des organisations qui ont simplement des guides de style ou des bibliothèques de composants. Cela guide l’implémentation du système pour assurer la cohérence à travers un produit ou une suite de produits reliés.
Modèle de gouvernance
Les organisations grandissent et évoluent. Les produits grandissent et évoluent. Votre système de design doit grandir et évoluer avec eux. Ce qui a fonctionné pour vous en tant que startup avec deux développeurs et un designer ne fonctionnera pas nécessairement quand vous êtes une équipe de 10 ou 20, ou quand vous commencez à ajouter des contractuels tiers ou des équipes distribuées.
Votre modèle de gouvernance dicte comment le système de design grandira, qui est en charge de quels éléments, comment les nouvelles versions de vos bibliothèques de composants sont promues et dépréciées, et que se passe-t-il quand des cas limites sont découverts. Comme tout, la croissance et le changement sans contrôle c’est le chaos.
À quel point détaillé ou strict un système de design doit-il être ?
La réponse courte à cette question est : ça dépend. Bien qu’un système de design puisse bénéficier à une organisation de toute taille, les petites équipes avec un haut niveau de maturité peuvent être capables de fonctionner avec un ensemble de contrôles plus lâche. Tandis que les grandes équipes avec beaucoup de développeurs juniors peuvent nécessiter des contrôles plus serrés.
Comme mentionné, développer votre système de design n’est pas un simple processus unique. Vous devez continuellement évaluer le système et faire des ajustements selon les besoins. En plus d’analyser votre produit pour voir à quel point il est bien implémenté, recueillez des commentaires des designers et développeurs qui utilisent réellement le système pour évaluer son efficacité.
Avantages d’un système de design
Quand il s’agit d’un look et d’une sensation cohérents pour votre produit, ou pour une suite de produits, les avantages sont assez évidents. La cohérence du design et de la fonction peut augmenter l’expérience d’un utilisateur et sa satisfaction globale avec un produit.
Les systèmes de design peuvent aussi améliorer la vitesse de développement. Les composants réutilisables réduisent le retravail et les systèmes bien documentés éliminent les conjectures de comment les éléments devraient être implémentés. De plus, vous supprimez les temps d’arrêt car les développeurs n’ont plus besoin d’attendre que les designers mettent à jour le design de chaque écran.
Finalement, vous supprimez les silos avec vos développeurs et designers travaillant sur le système et à partir du système, et promouvez plus de collaboration entre les deux.
Tout cela mène à moins de gaspillage, des équipes améliorées, des implémentations plus rapides, et un meilleur produit global que vous livrez à vos clients.