# Donner un rôle à chaque vue

- Type : Note de conception 04
- Entreprise : Qlik · Expérience unifiée Talend et Qlik
- Période : En cours
- Rôle : Senior Product Designer
- Équipe : Équipe design system, Head of Design
- Livrables : Proposition d’architecture, modèles de page
- Statut : publié
- Contenus liés :
  - [Écrit 01 · Concevoir, c’est retirer](https://florianbutour.com/ecrits/concevoir-c-est-retirer.md)
  - [Écrit 03 · Un design system qui s’arrête au bouton](https://florianbutour.com/ecrits/un-design-system-qui-s-arrete-au-bouton.md)
- Page web : https://florianbutour.com/travaux/templates-types-assets

Chez Qlik, chaque asset type (dataset, data product ou pipeline project) avait son propre overview, construit au fil des besoins. Je travaille à les faire reposer sur des modèles de page communs, en donnant à chaque vue un rôle précis.

J’y travaille avec l’équipe design system et le Head of Design de Qlik, dans le cadre de l’expérience unifiée entre les produits Talend et Qlik.

## Avant : un overview trop chargé

D’un asset type à l’autre, aucun overview ne se ressemblait dans sa structure. Chacune accumulait ce qu’on voulait montrer, sans règle commune sur la répartition de l’information entre les vues.

Deux exemples suffisent. L’overview d’un data product affiche la liste complète de ses datasets ; celui d’un dataset affiche son schéma entier. Avec cinq cents colonnes ou une longue liste, la vue perd sa raison d’être : permettre d’identifier l’asset et de comprendre s’il répond au besoin avant d’en explorer le détail.

Fig. 01 · Avant : l’overview d’un data product empile tous ses datasets ; celle d’un dataset, son schéma entier. : Avant · Data product · Overview · Résumé · Liste complète des datasets · … et tout le reste, sans fin · Avant · Dataset · Overview · Résumé · Schéma complet · 500 colonnes · … et tout le reste, sans fin

## La démarche : un rôle par vue

Plutôt que de corriger chaque page, j’ai proposé de revoir l’architecture des assets à partir d’une règle simple : chaque vue a un rôle.

- **L’overview permet d’identifier l’asset, d’en comprendre l’utilité et d’accéder aux actions pertinentes.**
- **Le brut et l’exhaustif vivent dans des vues dédiées** : pour un dataset, des vues de profil, de schéma et d’aperçu des données ; pour un data product, une liste d’assets filtrable.

Je propose d’inscrire cette règle dans le design system de l’expérience unifiée sous forme de modèles de page communs. Leur application doit tenir compte des informations nécessaires pour évaluer chaque asset type.

Fig. 02 · Après : l’overview résume, montre la valeur et invite à agir ; le détail vit dans des vues dédiées, à un clic. : Après · Dataset ou data product · Overview · Résumer · Montrer la valeur · Inviter à agir · → voir le détail · Profil, schéma, aperçu · dataset · les cinq cents colonnes, à leur place · Ressources filtrables · data product · la liste complète, filtrable par dataset

## Faire adopter une architecture

Une règle de ce genre ne s’impose pas d’un coup. Le frein est simple : l’appliquer, c’est reprendre tous les asset types, un chantier lourd. Je propose deux façons de le rendre abordable : appliquer le modèle progressivement, un asset type à la fois, au fil de ses évolutions ; et passer par les templates, pour que chaque type adopte la structure commune sans être reconçu de zéro.

## État du travail et limites

Cette note décrit une proposition en cours, pas une architecture dont l’adoption serait achevée. La reprise progressive et les templates constituent le chemin d’adoption envisagé. Leur efficacité et les exceptions au modèle restent à documenter.

Une vue dédiée ne doit pas non plus rendre l’information difficile à trouver : alléger l’overview n’a d’intérêt que si l’accès au détail reste clair.