Un système visuel que deux personnes peuvent tenir

À deux, un système de design échoue rarement par manque d'ambition. Il échoue parce qu'il décrit des composants que vous n'avez pas, des règles que personne ne rouvre, et des noms que l'autre ne retrouve pas. Le système dont vous avez besoin est plus petit que les exemples publics. Il couvre ce que vous réutilisez déjà cette semaine : quelques couleurs avec un rôle, une échelle de texte courte, les états des composants qui existent, et un endroit où l'autre peut changer une valeur sans vous demander. Le reste peut rester dans les maquettes. Un système n'est pas une preuve de sérieux. C'est un moyen de ne pas reprendre la même décision tous les mardis.

Vous pouvez le poser en deux séances, pas en un trimestre. La première sert à inventorier ce qui se répète vraiment. La seconde sert à le nommer, à le ranger, et à écrire ce qui a le droit de changer sans réunion. Si la page que vous produisez ne tient pas dans un seul fichier, ou dans une planche que vous épinglez, elle est déjà trop grande pour deux. Vous ajouterez plus tard, quand une troisième occurrence vous y forcera. Avant la troisième fois, une règle est souvent une précaution, pas un outil.

Cas : tenir six couleurs sans ouvrir une bibliothèque

Le site a dérivé : trois gris, deux verts, un orange utilisé une seule fois. Vous figez une liste de six couleurs nommées, cinq tailles de texte, et huit composants que vous acceptez de maintenir. L’orange unique devient une exception écrite, pas une neuvième couleur. Quand un nouvel écran a besoin d’un bleu, la réponse est non, sauf si vous retirez une couleur de la liste le même jour. Deux semaines plus tard, vous ouvrez la liste. Si elle a grandi sans décision, le système n’est déjà plus tenu.

Modèle à copier : la liste qui n’a pas le droit de grandir

• Six couleurs nommées, pas une de plus sans en retirer une le même jour.
• Quatre tailles de texte, déjà décidées sur une page réelle.
• Huit composants que vous acceptez d’ouvrir encore dans trois mois.
• Une exception écrite, avec sa date de fin. Une exception sans date devient une neuvième couleur.

Limiter le système à ce que vous réutilisez

Ouvrez les trois derniers livrables, pas une planche d'inspiration. Notez ce qui revient : un bouton, un champ, un titre, une carte, une alerte, une légende. Si un élément n'apparaît qu'une fois, laissez-le dans sa maquette. Le promouvoir maintenant vous oblige à inventer des variantes dont vous n'avez pas l'usage. Comptez les occurrences. Deux fois, vous pouvez encore copier. Trois fois, vous gagnez à extraire. Cette règle empêche le système de grossir par peur du vide. Elle vous laisse aussi le droit de supprimer. Un composant que vous n'avez pas utilisé depuis deux mois retourne dans les archives, ou disparaît. Garder « au cas où » est la façon la plus sûre de ne plus savoir quelle version fait foi.

Écrivez le périmètre en haut de la page, en trois lignes. Ce que le système couvre. Ce qu'il ne couvre pas. Qui a le droit d'y ajouter une pièce. À deux, la réponse à la troisième question est souvent : n'importe lequel, à condition d'écrire la raison en une phrase. Vous n'avez pas besoin d'un comité. Vous avez besoin d'une trace. Sans cette trace, l'ajout d'aujourd'hui contredit la règle d'hier, et vous ne savez plus laquelle ouvrir. La trace peut être un commentaire dans le fichier, daté, pas un compte rendu. Si vous ne pouvez pas expliquer l'ajout en une phrase, vous n'êtes pas devant une règle. Vous êtes devant un cas particulier, et il doit rester dans le projet qui l'a fait naître.

• Inventoriez seulement les pièces présentes dans les trois derniers livrables.
• Extrayez à la troisième occurrence, pas à la première envie de ranger.
• Écrivez en tête de page ce que le système ne couvre pas encore.
• Archivez ce qui n'a pas servi depuis deux mois, au lieu de le laisser comme modèle.

Nommer les couleurs par leur rôle

Les noms de couleurs qui décrivent la teinte cassent dès que la teinte change. « Bleu principal » devient faux le jour où l'action passe au vert, et tous les fichiers mentent. Nommez le rôle : fond, encre, encre douce, action, danger, succès. La valeur, elle, peut changer. Le rôle, non. Tenez la liste assez courte pour la retenir sans ouvrir un nuancier. Si vous dépassez huit rôles, vous êtes probablement en train de nommer des cas. « Fond de la carte promo de mars » n'est pas un rôle. C'est une exception, et elle vit dans le fichier de mars. Le système garde ce qui traverse les projets. Huit rôles suffisent : au-delà, vous nommez des campagnes, pas des règles.

À côté de chaque rôle, notez la valeur et le rapport de contraste quand le rôle sert à du texte ou à un composant. Vous n'avez pas à refaire la théorie ici : vous empêchez qu'une couleur d'action jolie devienne un texte illisible sur le fond que vous avez déjà choisi. Indiquez aussi ce que le rôle n'a pas le droit de faire. L'encre douce ne sert pas aux mentions que l'utilisateur doit lire pour finir une tâche. Le danger ne sert pas à décorer un titre. Ces interdictions courtes valent mieux qu'un long principe. Quand l'un de vous hésite, la phrase est déjà là, et la discussion dure une minute. Changez la valeur autant que vous voulez. Changer le rôle, en revanche, demande de regarder tous les endroits où il est déjà posé.

Tenir une échelle de texte courte

Deux personnes n'ont pas besoin de douze tailles. Elles ont besoin de quatre ou cinq rôles que l'on reconnaît sans mesurer : titre de page, titre de section, texte courant, légende, et parfois un chiffre mis en avant. Écrivez la taille, l'interligne et le poids. Dites où chaque rôle s'emploie, et où il ne s'emploie pas. Le titre de page n'entre pas dans une carte. La légende ne porte pas une instruction. Si un écran semble réclamer une taille intermédiaire, résistez une fois. Souvent, c'est l'espacement ou la longueur de ligne qui est faux, pas l'échelle. Ajouter une taille est facile. La retirer six mois plus tard, quand elle est partout, ne l'est pas.

Fixez aussi une longueur de ligne pour le texte courant, et un alignement par défaut. À deux, les détails qui divergent sont rarement les grands gestes. Ce sont la légende collée au bord, le titre centré sur un écran et aligné à gauche sur l'autre, l'interligne trop serré dans un export. Une phrase dans le système règle cela mieux qu'une relecture de fin de nuit. Vérifiez les styles dans l'outil que vous utilisez vraiment. Un guide qui décrit des tailles que les styles ne contiennent pas est déjà obsolète. Si vous travaillez à la fois en maquette et en code, les rôles portent le même nom des deux côtés. « TitleLg » d'un côté et « grand titre » de l'autre, c'est deux systèmes, donc aucun.

Documenter les états des composants que vous avez

Un bouton dessiné au repos n'est pas un bouton. Notez, pour chaque composant que vous avez extrait, les états que vous avez vraiment rencontrés : repos, survol, contour visible au clavier, actif, désactivé, erreur, chargement. Si un état n'existe pas encore dans le produit, ne l'inventez pas pour faire complet. Laissez une case vide. Elle rappellera, le jour venu, que la décision n'a pas été prise. Pour les champs, précisez le libellé, l'aide, l'erreur, et ce qui se passe quand le contenu est trop long. C'est presque toujours le texte long, pas la couleur, qui casse une petite équipe. La traduction, le nom d'un client, un message de validation : prévoyez le débordement maintenant, sur un exemple réel.

Écrivez le comportement en une ligne, pas en spécification. « Au clavier, bordure encre, visible sur le fond, sans dépendre de la seule couleur. » « En erreur, le texte d'erreur est une phrase, sous le champ, pas seulement une bordure rouge. » Ces lignes tiennent dans la planche, à côté du dessin. Elles évitent que l'un de vous code le survol pendant que l'autre le retire. Ajoutez le cas du contenu vide : une liste sans élément, un résultat de recherche nul, un bouton qui attend. Les états vides sont des composants, pas des oublis. Si vous ne les dessinez pas, le produit affichera un trou, ou un message improvisé, différent à chaque écran. Un seul modèle d'état vide, avec un titre et une action, suffit pour commencer.

1. Pour chaque composant extrait, listez seulement les états déjà rencontrés.
2. Écrivez une ligne de comportement à côté du dessin, pas dans un document à part.
3. Testez un texte trop long et un texte absent avant de dire que le composant est prêt.
4. Gardez un seul modèle d'état vide, réutilisé, plutôt qu'un message improvisé par écran.

Ranger pour que l'autre retrouve sans vous

Le meilleur système est inutile si l'autre ne sait pas où il vit. Choisissez un fichier, un dossier, un nom stable. Pas « systeme-final-v7 ». Un nom qui survivra à l'année. Dedans, l'ordre suit l'usage : couleurs, texte, composants, puis les décisions datées. Évitez les sous-dossiers au-delà d'un niveau. À deux, la recherche doit marcher par le nom du fichier et par trois mots que vous avez tous les deux en tête. Mettez en haut de la page un index de six lignes. Si l'index ne tient pas, le système a encore trop de pièces. Rangez les essais ailleurs, dans un dossier clairement nommé comme tel, pour qu'ils ne soient pas pris pour des modèles.

Convenez d'un geste quand vous changez une valeur. Vous modifiez, vous notez la date et la raison en une ligne, vous le dites. Pas une réunion. Un message. L'autre n'a pas à deviner pourquoi le bouton a rapetissé. Si vous travaillez en code et en maquette, décidez laquelle conduit. Une seule source pour les valeurs, l'autre se met à jour ensuite. Deux sources modifiées le même jour produisent des écrans qui se contredisent et une dispute inutile. Une fois par mois, ouvrez le fichier comme si vous étiez nouveau. Chaque endroit où vous hésitez est un nom à clarifier. Ce test de dix minutes remplace la documentation que vous n'écrirez pas.

Décider ce qui change sans réunion

Tout ne mérite pas une discussion. Séparez les changements en deux listes, écrites. D'un côté, ce que chacun peut faire seul : corriger une coquille dans un exemple, ajuster un espacement déjà prévu par l'échelle, remplacer une valeur de couleur par une autre qui respecte le rôle et le contraste, ajouter un exemple à un composant existant. De l'autre, ce que vous regardez à deux avant de toucher : un nouveau rôle de couleur, une nouvelle taille de texte, un composant supplémentaire, un changement de nom qui casse les fichiers en cours. La frontière doit être assez claire pour qu'un vendredi soir, personne n'ait à demander. Si vous hésitez, c'est que la frontière est mal écrite, pas que vous manquez de processus.

Pour les changements de la seconde liste, une conversation de dix minutes suffit. Apportez l'écran réel qui pose problème, pas une préférence. « Le titre de carte se confond avec le titre de page » est une raison. « J'aimerais quelque chose de plus tendu » n'en est pas une, tant que vous n'avez pas montré où l'échelle actuelle échoue. Décidez, notez la phrase, mettez à jour le fichier pendant l'appel si vous le pouvez. Une décision qui attend un « vrai passage de mise à jour » ne sera pas faite. Et résistez à l'idée d'adopter, d'un bloc, le système public d'une autre équipe. Vous pouvez voler une idée, une façon de nommer, un état que vous aviez oublié. Vous ne pouvez pas entretenir leur bibliothèque. La vôtre doit rester plus petite que votre semaine.

Tenir une revue de vingt minutes

Mettez une revue au calendrier, une fois par mois, vingt minutes, même si vous pensez que rien n'a bougé. L'ordre du jour est fixe. Qu'avons-nous copié-collé au lieu d'utiliser le système ? Quelle pièce est devenue fausse ? Quel nom prête à confusion ? Quelle exception de projet devrait entrer, ou au contraire rester dehors ? Tenez un compte simple : si vous avez contourné le bouton trois fois, le bouton est faux, ou le cas n'est pas un bouton. Corrigez l'un des deux pendant la revue, pas après. Une seule correction par mois, vraiment faite, vaut mieux qu'une liste de douze améliorations. La liste sans correction est la manière polie d'abandonner le fichier.

Terminez par une question de charge. Le système nous a-t-il fait gagner du temps sur le dernier livrable, ou nous a-t-il donné du travail en plus ? Si la réponse est « en plus » deux mois de suite, retirez des pièces. Vous n'êtes pas une équipe de système. Vous êtes deux personnes qui livrent. Le fichier doit rester un raccourci. Quand il devient une obligation morale, vous recommencerez à dessiner à côté, et vous aurez alors deux vérités. Notez le nom de la personne qui tient la prochaine revue. L'absence de nom est le premier signe que la page va pourrir. Avec un nom et vingt minutes, le système reste à la taille de votre travail, et c'est la seule taille qui compte.

Cette semaine, extrayez une seule pièce répétée, nommez-la par son rôle, et rangez-la là où l'autre la trouvera sans message. Vingt minutes bien placées valent mieux qu'une bibliothèque que vous n'ouvrirez pas.