Déduire les composants nécessaires de deux vues produit
Une liste de projets et une page de détail montrent les éléments réutilisables et les cas où des tâches différentes demandent des solutions propres.
Un système de design devient plus facile à utiliser lorsque son premier périmètre découle de véritables tâches d’interface. Commencez donc par les vues dont le produit a réellement besoin. Une longue liste de composants possibles renseigne encore peu sur les variantes que votre équipe doit utiliser.
Recenser deux vues et leurs tâches
Un portail client fictif sert d’exemple détaillé. Dans la liste des projets, les clients doivent reconnaître et ouvrir un projet. Dans la vue de détail, ils doivent lire son état et télécharger les documents approuvés. Ces vues appartiennent au même produit, mais répondent à des tâches différentes.
Pour chaque élément visible, notez objectif, contenu et états possibles. Un cadre similaire ne suffit pas à justifier un composant commun. Il faut aussi vérifier si sens et comportement concordent.
Choisir un socle commun et des assemblages distincts
Élément | Utilisation dans les vues | Décision pour le premier périmètre |
|---|---|---|
Indicateur d’état | Même état du projet dans la liste et le détail | Composant commun avec les mêmes termes d’état |
Menu d’actions | Actions de projet dans la liste, de document dans le détail | Socle de menu commun ; entrées et autorisations définies pour chaque parcours |
Carte de projet | Ouvre la vue de détail | Assemblage propre à la navigation entre projets |
Ligne de fichier | Nomme un document et propose son téléchargement | Assemblage propre à la tâche documentaire |
La carte de projet et la ligne de fichier peuvent partager de petits éléments de base. Elles ne doivent pas pour autant devenir un seul grand composant. Une exception est pertinente si une variante commune rend la tâche inutilement moins claire.
Renseigner concrètement une entrée de bibliothèque
Pour l’indicateur d’état, l’exemple consigne : utilisation dans les deux vues du projet ; texte d’état issu des données du projet ; couleur comme indication supplémentaire uniquement ; aucune action de clic propre. Les valeurs d’état nécessaires et la gestion des traductions longues restent à préciser. Ces décisions doivent être clarifiées avant la mise en œuvre, plutôt que masquées par des valeurs d’exemple arbitraires.
Carbon décrit les composants comme des solutions conçues et codées pour des tâches d’interface précises. Adoptez aussi cette perspective lors du choix : documentez ensemble objectif, variantes et limites d’un composant. Un nom existant dans une bibliothèque ne suffit pas comme règle d’utilisation.
Vérifier le premier périmètre dans les deux vues
Placez d’abord les composants choisis dans les deux conceptions. Vérifiez les contenus habituels et les traductions longues ; pour les éléments interactifs, contrôlez aussi utilisation au clavier et changements d’état. Notez la version utilisée et les différences conservées volontairement. L’exemple fournit un document de travail, pas une bibliothèque déjà implémentée. L’étape suivante est une sélection limitée, dont les points ouverts sont clarifiés, que l’équipe pourra ensuite implémenter et tester.
Sources
Écrit par
- Julia HoffmannRédactrice design et UXJulia Hoffmann est responsable chez ASES des contenus éditoriaux consacrés au design et à l’expérience utilisateur. Ses articles portent sur l’utilisation des sites web et des applications, la conception d’interfaces utilisateur et l’accessibilité numérique.
À lire aussi
Tous les articles
Votre projet avec ASES
Décrivez-nous votre projet. Nous revenons vers vous avec une première évaluation.