Le système de conception minimale viable

Système de conception UXPin en croissance stocké dans la bibliothèque du système de conception UXPin

Au cours des deux dernières semaines, j'ai eu le plaisir de parler de l'approche d'UXPin pour construire un système de conception sur plusieurs réunions et webinaires (vous pouvez en regarder un ici). J'ai eu beaucoup de plaisir à partager nos expériences, j'ai beaucoup appris à travers toutes les belles conversations après mes discussions.

Une question qui m'a été posée plusieurs fois, qui a également été soulevée lors de mes conversations avec notre équipe chez UXPin, était:

Combien de temps faut-il pour construire un système de conception?

Il n'y a pas de mauvaises questions et j'étais heureux de répondre à chaque fois. Cependant, chaque fois que j'entends cette question, je pense qu'elle pointe vers un problème plus profond: les systèmes de conception sont toujours mal compris et confondus avec une ancienne approche de la construction d'un guide de style.

The Zombie Style Guide Legacy

À l'époque, un membre malchanceux de l'équipe de conception ou de développement front-end était chargé de documenter toutes les conventions approuvées par l'équipe. Palettes de couleurs, styles de texte, normes de code, parfois même modèles d'interface utilisateur.

Cela ressemble à un système de conception? Tu as raison. Cela ressemble à un système de conception, mais ce n'est pas le cas.

Cette ancienne approche de la construction d'un guide de style visait à produire un artefact. C’est censé être un dérivé d’un processus de documentation. Et à chaque fois…

Avant que le guide de style ne soit terminé, il était déjà devenu un zombie.

Pourquoi? Tout simplement parce que le monde dynamique du développement de produits, où les changements se produisent constamment, ne répond pas bien aux actifs statiques qui prennent des semaines à se construire. Alors qu'un martyr de la conception / du développement avait du mal à documenter chaque convention, les conventions ne cessaient de changer. Construire un guide de style était une tâche sisyphe.

L'impossibilité de créer et de maintenir des guides de style a encouragé notre industrie à repenser le processus de maintien de la cohérence de l'expérience et du code. Entrez dans le système de conception.

Le système de conception est un processus

Contrairement aux guides de style statiques, les systèmes de conception sont dynamiques. Qu'est-ce que ça veut dire? Le guide de style est un artefact, le système de conception est un processus.

Les artefacts sont statiques, les processus sont dynamiques.

Au lieu de déléguer une personne pour créer la documentation, dans le monde du système de conception, nous prévoyons un nouveau flux de travail qui continue d'ajouter, de soustraire et de modifier toutes les informations pour créer des expériences utilisateur.

Au lieu de penser en termes de date de livraison, les équipes du système de conception (généralement appelées équipes des opérations de conception) prévoient d'aider les organisations à améliorer progressivement la cohérence interne de l'interface et à livrer plus rapidement de grands projets sur le marché.

Gérer l'entropie avec un guide de style et un système de conception

Unis contre l'entropie

Comme pour tout système fermé, l'entropie d'un produit numérique continue d'augmenter, à moins qu'il ne soit délibérément géré. Chaque nouvelle fonctionnalité, chaque nouveau membre de l'équipe, chaque nouvelle couche de gestion ou interaction entre les parties prenantes et le client, ajoute à l'entropie de l'expérience.

L'expérience produit par défaut devient le chaos.

La croissance de l'entropie est une constante et ne peut être contrôlée que par une action constante. C'est pourquoi le jeu final pour une équipe Design Operations n'est pas un artefact statique, c'est un flux de travail dans lequel une organisation unie de designers, développeurs, PM et autres membres de l'équipe construit un système de conception pour créer des expériences utilisateur.

Produit sans fin minimum viable

Demander la date de livraison d'un système de conception semble avoir une hypothèse cachée, c'est qu'il y a un certain moment où le système de conception est «terminé». La nature processuelle d'un système de conception annule cette hypothèse.

Le système de conception est un processus et est donc simultanément toujours prêt et jamais fait.

Un système de conception reste dans un état constant d'être un produit minimum viable. Le moment où un système de conception prend soudainement de la valeur n'existe pas. Une fois que le processus du système de conception est établi et convenu, la valeur minimale est atteinte. Avec chaque version ultérieure, le système de conception devient plus puissant, mais n'atteint jamais la valeur ultime. L'entropie continue de croître, l'interface continue de changer et le système de conception doit évoluer, en tant que processus, sans fin.

Démarrer souvent un petit navire

Un système de conception voit le jour lorsqu'une organisation reconnaît que l'augmentation de l'incohérence de l'interface utilisateur doit être résolue grâce à de nouveaux workflows.

L'entropie cesse de s'étendre avec la première convention convenue et mise en œuvre par une organisation de conception. Contrairement à un guide de style, la valeur d'un système de conception peut être immédiatement ressentie. Le système de conception commence à ajouter de la valeur presque immédiatement, même si la première convention n'est qu'un ensemble de 5 couleurs primaires avec la convention de dénomination correspondante. En fait, je dirais que:

Un système de conception avec une seule couleur définie, correctement nommée, mise en œuvre et acceptée par une organisation est mieux qu'un guide de style statique complet.

Pourquoi? Parce que cette couleur diminue immédiatement l'entropie, contrairement à un guide de style statique qui reste toujours obsolète et jamais mis en œuvre.

Au lieu de vous soucier de la date de livraison d'un système de conception, acceptez sa nature processuelle, commencez petit et expédiez souvent. Vous êtes en guerre avec le chaos et chaque petite bataille compte.

Bonne chance.

Voulez-vous voir comment nous construisons notre système de conception? Suivez nos sprints Design Operations:

  • Design Systems Sprint 0: la balle d'argent du développement de produits.
  • Design Systems Sprint 1: L'inventaire des interfaces
  • Design System Sprint 2: une palette de couleurs pour les gouverner tous
  • Design System Sprint 3: Gérer les bases
  • Design System Sprint 4: Principes de conception
  • Design System Sprint 5: Gestion de la typographie
  • Système de conception Sprint 6: les icônes les plus rapides sur Terre

Et voici une perspective plus large sur les systèmes de conception:

Les systèmes de conception sont un langage. Et cela change à jamais le développement de logiciels.

Rejoignez: https://www.uxpin.com/design-systems-early-access