Les nombreux visages des systèmes de conception thématiques

Il est très rare qu’un seul système de conception soit créé pour servir exactement un produit qui exprime exactement un langage de conception. Presque tous les systèmes de conception sur lesquels nous avons travaillé nécessitent un degré élevé de flexibilité afin de répondre correctement aux besoins de nos clients. Une partie de cette flexibilité est obtenue par la variabilité de la structure, du style, du comportement et du contenu des composants. Mais une flexibilité esthétique avancée est souvent obtenue en créant un système de conception thématique.

Mais de quoi parlons-nous précisément lorsque nous parlons d’un système de conception thématique ? Cet article parlera des différentes saveurs de thémabilité qu’un système de conception peut avoir besoin de prendre en charge, y compris la prise en charge :

Plusieurs marques
Sous-marques
Marque blanche
Saisons ou Campagnes
Plusieurs générations d’un langage de conception
Plusieurs plates-formes ou familles de produits (application Web vs site Web marketing)
Thèmes sombres et clairs

Une architecture de jetons à trois niveaux

Avant de plonger dans chacun de ces scénarios, je vais prendre un peu de temps pour expliquer l’architecture de thème qui peut prendre en charge tous ces scénarios. Une architecture de jeton de conception à trois niveaux peut faire passer un ensemble spécifique de jetons via un ensemble de composants d’interface utilisateur du système de conception :

Un exemple de mappage d’architecture de jeton à trois niveaux

Voici une ventilation de chacun des 3 niveaux:

Jetons de niveau 1 définir les propriétés de conception du thème dans l’abstrait, qui servent de matières premières pour le langage visuel de l’interface utilisateur.
Jetons de niveau 2 sont une couche de thème sémantique qui mappe les jetons de niveau 1 à une utilisation de haut niveau dans une interface utilisateur.
Jetons de niveau 3 sont spécifiques aux composants et sont mappés aux jetons de niveau 2.

Quelques exemples de cette architecture en pratique :

Tier 1: color-brand-green =>
Tier 2: theme-color-primary-background =>
Tier 3: button-primary-background

Tier 1: border-radius-large =>
Tier 2: theme-border-radius =>
Tier 3: card-border-radius

Cette architecture contrôle l’apparence d’une marque dans sa propre couche, loin de la bibliothèque de composants de base, ce qui débloque la possibilité de faire passer différents langages de conception via un ensemble partagé de composants de base.

D’un point de vue technique, soit nous créons un design-tokens répertoire dans notre référentiel de système de conception, ou créez un référentiel autonome pour stocker nos jetons de conception de thème. L’essentiel de chaque thème ressemble à ceci :

theme-name
--tier-1-definitions
----animation.json
----border.json
----colors.json
----etc
--tier-2-usage
--tier-3-component

Nous avons utilisé de nombreux outils au fil des ans, mais nous nous sommes largement installés sur Style Dictionary pour gérer et transformer nos jetons. Je laisserai de côté comment cela se passe dans les outils de conception statique car c’est une toute autre boule de cire !

Avec cette vue d’ensemble architecturale couverte, plongeons dans les scénarios que cette architecture aide à résoudre.

Plusieurs marques

Nous avons travaillé avec Pfizer, DotDash, Condé Nast et de nombreuses autres organisations pour créer des systèmes de conception capables de prendre en charge les langages de conception de la myriade de marques de l’organisation.

Chaque marque partage les mêmes os : HTML, API, styles CSS communs (des choses comme display et propriétés de positionnement) et le comportement de JavaScript, tout en faisant passer des esthétiques très différentes à travers ces composants.

La structure du répertoire de jetons de conception pour la prise en charge de plusieurs marques a tendance à ressembler à ceci :

- core
- brand-theme-1
- brand-theme-2
- brand-theme-n

L’équipe du système de conception publie les thèmes, et les consommateurs du système de conception insèrent les jetons de base (qui sont partagés entre tous les thèmes) et le thème de marque approprié dans leur produit afin d’obtenir les résultats souhaités.

core + brand-theme-n

Sous-marques

Une couche supplémentaire peut être ajoutée pour prendre en charge les sous-marques, qui sont des marques qui héritent d’une marque mère mais contiennent certaines nuances ou dérogations afin de différencier les sous-marques.

Un exemple de sous-branding dans l’identité de marque de New York

Appliquée aux systèmes de conception thématiques, une couche de sous-marque supplémentaire peut être ajoutée afin d’ajouter ou de remplacer les valeurs de jeton afin d’obtenir le résultat souhaité. Le thème de la sous-marque peut être jeté sur la pile comme suit :

core + brand-theme + sub-brand-theme

Marque blanche

Nous avons travaillé avec une entreprise qui crée et vend des logiciels hypothécaires aux banques. Bien qu’il s’agisse d’un logiciel tiers, les banques souhaitent naturellement que l’expérience utilisateur incarne la marque de la banque et les normes de langage de conception pour communiquer la confiance à leurs clients lorsqu’ils demandent et gèrent leurs prêts hypothécaires.

Semblables aux sous-marques, les expériences en marque blanche prennent une expérience de marque de base et ajoutent ou remplacent certaines propriétés de conception (en se concentrant presque toujours sur la couleur et la typographie) pour obtenir le résultat souhaité.

core + brand-theme + white-label-theme

Le white-label-theme peut être fourni sous forme de fichier de configuration spécifique au client, ou peut même être affiché dans un CMS afin que les clients contrôlent leurs propres remplacements d’interface utilisateur (pensez à skinner Gmail ou votre thème Myspace à l’époque).

Saisons ou campagnes

Nous avons travaillé avec de nombreux détaillants qui ont besoin d’un haut degré de flexibilité du système de conception pour s’adapter aux campagnes ou promotions saisonnières. Par exemple, l’équipe peut avoir besoin de créer une page d’accueil de site Web de commerce électronique pour la Saint-Valentin qui comporte des boutons d’appel à l’action roses et une police de caractères différente pour les en-têtes promotionnels. Il est tout à fait possible de s’adapter à ces langages de conception éphémères et extrêmement divergents à l’aide d’un système de conception thématique bien architecturé.

L’exécution est identique à la prise en charge d’expériences de sous-marque ou de marque blanche, avec des valeurs de thème spécifiques à la campagne qui remplacent ou étendent les valeurs de base et de marque :

core + brand-theme + campaign-theme

Plusieurs générations d’un langage de conception

L’une des promesses d’un système de conception est de pouvoir apporter des modifications globales à un langage de conception en un claquement de doigts. C’est la théorie en tout cas. Mais concrètement, comment cela fonctionne-t-il ? La réponse est la création d’un système de conception thématique qui peut prendre en charge à la fois les langages de conception hérités et futurs (aka 2.0 ! 3.0 ! Next Generation ! NextGen ! Rebrand ! Facelift ! Site Web du futur ! Nous avons tout entendu.).

L’approche est identique à la prise en charge de plusieurs marques, mais avec l’intention de pouvoir soutenir le passé tout en déployant l’avenir de manière réfléchie et systématique.

- core
- legacy-theme
- next-generation-theme

Cette architecture peut être extrêmement puissante ; il donne à l’équipe du système de conception le contrôle sur la manière exacte de déployer les refontes esthétiques des produits numériques de l’organisation. Les équipes consommatrices peuvent adopter le système de conception en utilisant le legacy-theme avec une perturbation minimale de l’expérience utilisateur existante. Une fois les composants du système de conception en place, les équipes du système de conception et du produit peuvent alors coordonner le moment de basculer vers le next-generation-theme. Nous avons trouvé que cette approche était un outil puissant pour répondre à l’appréhension compréhensible des équipes à l’idée de changer trop, trop vite lors de l’adoption du système de conception.

Familles de produits

Une question courante que je réponds tout le temps est “Est-ce que nos produits logiciels (alias “applications”) et nos produits marketing (alias “sites Web”) peuvent/devraient-ils partager le même système de conception?” J’utiliserai mon outil bien-aimé de facturation/dépenses/suivi du temps Harvest pour démontrer la séparation entre le site Web marketing et le produit Web. Harvest a un site Web marketing qui vend le produit et fournit des informations importantes :

Page d’accueil du site Web de marketing de suivi du temps de récolte

Et ils ont l’expérience réelle de l’application Web où vous pouvez suivre le temps, créer des factures, gérer des produits, etc. :

Application Web de suivi du temps de récolte

D’après mon expérience, le fossé humain entre le marketing et le produit est souvent aussi fort que le fossé que nous observons entre les concepteurs et les développeurs. C’est une rupture fascinante à observer encore et encore dans mon travail de consultant en systèmes de conception.

Il est vrai à 100 % que ces expériences numériques ont des besoins, des considérations et des publics différents (la plupart du temps). Donc, bien sûr, ces deux mondes ne peuvent pas partager le même système de conception, n’est-ce pas ? Eh bien, pas exactement.

D’une part, la marque est la marque et elle doit être cohérente et cohérente dans l’ensemble de l’écosystème numérique de l’organisation. De plus, lorsque vous explosez à la fois les expériences marketing et les expériences produit dans leurs morceaux atomiques, vous constaterez qu’ils sont constitués de la même chose : boutons, champs de formulaire, texte, icônes, etc. Ces composants communs font partie des systèmes de conception. Ne serait-il donc pas judicieux de créer des contrôles de formulaire robustes, flexibles et accessibles qui pourraient bien fonctionner à la fois pour les expériences produit et marketing ?

Lorsque vous décomposez vraiment les différences entre ces expériences apparemment différentes, cela se résume à quelques domaines clés :

Les sites de marketing utilisent les espaces blancs dans le wazoo et besoin que les choses soient de taille géante, tandis que les applications de produits ont besoin que les choses soient plus compactes et utilitaires
Les sites de marketing utilisent une typographie différente – et plus grande – que les applications Web de produits.
Les expériences de marketing et de produit utilisent différents composants : héros, rabatteurs, cartes, tableaux de comparaison et devis pour les sites Web de marketing et tableaux, formulaires, graphiques et graphiques pour les applications de produit.

Ces différences justifient-elles des systèmes de conception totalement distincts ? Peut être. Mais je ne suis pas convaincu. Certains sites utilisent certains composants, d’autres utilisent d’autres composants. Une clé à molette et une scie circulaire ne sont probablement pas nécessaires pour le même travail, mais elles peuvent toutes deux cohabiter comme outils au sous-sol. En ce qui concerne les différences esthétiques, nous pouvons créer différents thèmes pour s’adapter aux différentes échelles de caractères, tailles et autres différences entre les expériences de site Web marketing et d’application de produit.

- core
- marketing
- product

Mode sombre et clair

J’ai écrit ailleurs sur la différence entre le vrai mode sombre et les styles «inversés» (alias «knockout»). Les jetons inversés/knockout, qui gèrent le rendu de certains composants lorsqu’ils sont assis sur un fond sombre, sont souvent définis dans un thème spécifique. Par exemple, theme-color-neutral-dark-content peut être appliqué à la couleur de texte par défaut, mais theme-color-neutral-dark-content-inverted serait appliqué aux composants qui sont assis sur un fond sombre.

Prise en charge officielle du mode sombre (c’est-à-dire prefers-color-scheme: dark) peut être traité de plusieurs manières. Les jetons en mode sombre peuvent être co-localisés aux côtés de leurs homologues en mode clair dans un thème. Alternativement, si les modes clair et sombre divergent énormément, vous pouvez les diviser en leur propre thème.

- core
- brand-theme-light
- brand-theme-dark

Une fondation souple

Les systèmes de conception sont souvent critiqués comme étant une solution « taille unique » qui ne pourrait pas bien servir différentes expériences. Cette perspective est bien sûr des conneries ; un système de conception peut être aussi flexible que l’organisation en a besoin. Et bien que cet article couvre la flexibilité du point de vue du langage de conception, de nombreux autres aspects de la flexibilité sont impliqués dans les systèmes de conception (variantes de composants, prise en charge de plusieurs piles technologiques, composition, recettes, etc.). Pris ensemble, les systèmes de conception peuvent fournir une base flexible sur laquelle de nombreux produits divers peuvent être construits.