La conception atomique est une méthodologie de construction d'interfaces utilisateur qui consiste à composer de petits éléments réutilisables en structures de plus en plus grandes. Introduite par Brad Frost en 2013, elle emprunte une métaphore chimique et définit cinq niveaux : les atomes, les plus petits éléments indivisibles tels que les étiquettes, les champs de saisie et les boutons ; les molécules, des groupes simples comme un champ de recherche avec son étiquette et son bouton ; les organismes, des assemblages plus complexes comme l'en-tête d'un site ou une fiche produit ; les modèles, des structures de page avec des espaces réservés au contenu ; et les pages, des modèles remplis de contenu réel.
L'apport de cette méthodologie réside dans un vocabulaire commun permettant de définir, implicitement pour chaque équipe d'interface, ce qu'est un composant, ce qu'est une composition et où commence la réutilisation. Sans cadre de référence, les équipes conçoivent les écrans individuellement, dupliquent les éléments similaires avec de légères variations et se retrouvent avec des dizaines de boutons et de cartes subtilement différents, qu'il faut maintenir individuellement. La conception atomique fournit une structure pour identifier les unités réutilisables et déterminer le niveau auquel appartient un élément donné de l'interface.
Ses avantages pratiques se manifestent davantage lors de la maintenance que lors de la création initiale. La modification d'un élément de base met à jour tous les éléments qui en dépendent ; ainsi, une modification du style ou de l'espacement du focus se propage de manière uniforme, sans nécessiter de recherche dans le code source. Les nouveaux écrans peuvent être assemblés à partir d'éléments existants, ce qui accélère le déploiement et réduit le nombre de décisions à prendre pour chaque nouvelle page. Le travail d'assurance qualité et d'accessibilité se concentre au niveau des composants, où une seule implémentation correcte suffit pour tous les usages, au lieu d'être répétée pour chaque page.
La méthodologie fait l'objet de critiques justifiées, principalement concernant son littéralisme. Les équipes consacrent un effort disproportionné à débattre de la nature d'un élément donné (molécule ou organisme), ce qui relève d'une argumentation taxonomique sans conséquence pratique. La métaphore chimique atteint également ses limites et se révèle difficilement compréhensible pour les non-spécialistes. La plupart des équipes expérimentées considèrent ces niveaux comme un guide souple, les simplifiant souvent en distinctions telles que primitives, composants et motifs, et privilégiant le principe de composition sous-jacent plutôt que la classification exacte.
La sur-abstraction représente le risque le plus grave. Créer une bibliothèque de composants avant de connaître les besoins réels du produit aboutit à des composants conçus pour des cas hypothétiques, avec des options de configuration excessives et des objectifs flous. La méthode la plus fiable consiste à concevoir des interfaces, à identifier les répétitions réelles et à extraire les composants une fois que le modèle est apparu plusieurs fois en situation réelle. Il est plus difficile de corriger une abstraction prématurée qu'une duplication, car chaque utilisateur d'un composant en limite les possibilités d'évolution.
La valeur de cette méthodologie repose en grande partie sur une gouvernance qu'elle ne fournit pas. Une bibliothèque de composants sans attribution claire de propriété, sans règles de contribution et sans processus de dépréciation accumule les variantes : trois cartes légèrement différentes, deux composants de bouton aux fonctions similaires et un nombre croissant de substitutions ponctuelles appliquées parce que le composant existant convenait presque. Définir qui approuve les nouveaux composants, comment une équipe demande une modification à un composant partagé et comment un modèle obsolète est supprimé de l'utilisation existante est plus important pour la cohérence à long terme que la taxonomie elle-même. Les organisations qui mettent en place cette gouvernance constatent que la bibliothèque réduit la charge de travail au fil du temps ; celles qui ne le font pas la voient devenir une surface incohérente supplémentaire nécessitant une maintenance en plus du code qu'elle était censée simplifier.
En termes de déploiement, cette approche est optimale lorsque la bibliothèque de conception et la bibliothèque de code correspondent parfaitement, de sorte qu'un composant de l'outil de conception possède une seule implémentation avec le même nom et les mêmes variantes. L'établissement de cette correspondance est une responsabilité partagée entre tous les acteurs. la conception des produits et le développement de produitset c'est ce qui détermine si un système de conception réduit le travail ou ajoute simplement un deuxième élément à maintenir en plus du code.