La fragmentation des tailles d'écran dans les téléphones, les tablettes et les ordinateurs de bureau peut créer d'immenses défis pour les concepteurs de produits et les ingénieurs d'interface utilisateur, en particulier dans les petites et moyennes entreprises qui cherchent à développer des solutions de conception évolutives. Alors qu'un système de conception est la réponse la plus évidente à de tels défis, la façon dont vous créez et segmentez les composants peut être le principal facteur entre le succès et l'échec.

L'équipe du système de conception de Mollie a été créée pour résoudre ce problème, mais au lieu d'adopter une approche par projet, nous avons décidé de fonctionner comme une équipe de produit. Nous avons donc encadré le défi avec une question « Comment pourrions-nous » :

« Comment pouvons-nous permettre une exploration et une mise en œuvre rapides d'interfaces utilisateur de haute qualité ? »

Cette question nous a aidés à penser différemment. La plus grande réalisation était que nous pouvions créer de meilleurs composants si nous nous concentrions sur le contexte de l'utilisateur plutôt que sur des plates-formes isolées (Web, iOS et Android). Cette approche nous a obligés à réfléchir à la meilleure expérience possible en fonction de la taille de l'écran et des méthodes de saisie. Par conséquent, nous avons défini la portée de nos composants en fonction de ces propriétés, de sorte que tous les composants devraient fournir un support et des fonctionnalités basés sur les éléments suivants :

• Taille de l'écran : grand ou petit.
• Mode de saisie : Souris, clavier ou tactile.

Une bibliothèque pour tous les contextes

En ce qui concerne les composants, nous choisissons d'avoir une bibliothèque dans Figma. Le contexte d'utilisation d'un composant est intégré dans ses propriétés. Le principal avantage de cette approche est que les concepteurs peuvent immédiatement savoir où un composant doit ou ne doit pas être utilisé. Tous nos composants appartiennent à l'une de ces quatre catégories :

1. Grand et petit écran
2. Grand écran ou petit écran
3. Grand écran uniquement
4. Petit écran uniquement

1. Grand et petit écran

C'est le type de composant le plus courant que nous ayons. La taille, le rembourrage et les styles sont conservés pour toutes les tailles d'écran et toutes les méthodes de saisie. Les boutons, onglets, badges et bien d'autres entrent dans cette catégorie.

Le principal défi dans ce type de composant est que nous devons prédire toutes les combinaisons possibles de variantes et d'états. Cela signifie que nous devons fournir tous les états interactifs attendus en fonction de la méthode de saisie, tels que la souris (survol), le clavier (toucher le focus) et le toucher (appuyer).

2. Grand écran ou petit écran

Ces composants présentent une différenciation visuelle entre les grands et les petits écrans, nous proposons donc une propriété permettant aux concepteurs de basculer entre ces variantes. Dans certains cas, le placement du contenu change, tandis que dans d'autres, le remplissage et les tailles de police diffèrent. Nous ne créons ces variantes que lorsque nous sommes sûrs que les inconvénients d'avoir une expérience différente l'emportent sur le coût de leur maintenance.

3. Grand écran uniquement

Ces composants sont rares et généralement liés à nos modèles de navigation, tels que les composants Navbar et Menu sur les grands écrans. Nous devons donc fournir un composant dédié pour prendre en charge ces modèles dans une taille d'écran spécifique. Nous ne fusionnons pas les variantes dans ce cas car elles diffèrent trop par les rembourrages, les marges, la typographie et les états.

4. Petit écran uniquement

Celui-ci est le pendant du genre ci-dessus, où la variante petit écran propose un schéma de navigation différent. Un exemple d'un tel composant sur des écrans plus petits est la barre d'onglets.

Pour en revenir à la question initiale « comment pourrions-nous », je peux affirmer avec confiance que cette approche a été cruciale pour résoudre notre problème. L'impact le plus significatif a été la possibilité d'avoir des décisions de conception évolutives. Lorsqu'une décision que nous prenons, par exemple, pour les petites tailles d'écran, peut être exploitée dans nos applications sur différentes plates-formes. Nous avons encore un système de conception jeune, mais qui évolue rapidement vers un produit mature.

Bonus : notre métrique pour les composants de construction

L'adoption n'est pas notre principale mesure, du moins pour le moment. Depuis que nous venons de passer en revue une refonte, 100 % de la plate-forme est construite à l'aide de notre système de conception. Au lieu de cela, nous nous concentrons sur la disponibilité des composants et des jetons. Au fur et à mesure que nous trouvons des moyens d'améliorer ces éléments, nous signalons les éléments comme "Problème connu" lors de l'identification d'une opportunité/d'un bogue. Ce qui devient alors une tâche pour notre équipe de système de conception.

Notre scénario est relativement unique. Même si nous avons une petite équipe avec quatre concepteurs de produits ( nous embauchons ! ) et plus de 20 ingénieurs UI, nous avons une équipe dédiée au système de conception. Un investissement qui nous permet de travailler sur ce type d'initiative.

Caio Manzotti est concepteur de produits senior pour les systèmes de conception chez Mollie , basé à Amsterdam.