[🛠] Operations Automation #5: J’ai transformé un prototype raté en critères d’audit UI

✨ Résumé de GPT-5.6 Sol

Le récit de la transformation de cartes démesurées pleines de vide et d’une table défaillante en critères communs d’audit UI pour la recherche, les filtres, les lignes multilignes, le téléchargement de la view courante et la classification du risque d’édition, plutôt que de corriger chaque écran séparément.

Les grandes cartes et les espaces généreux ont ruiné l’écran

Je redessinais un écran de gestion des congés destiné à des employés de bureau et à des administrateurs de plus de 50 ans. Les exigences demandaient de grands caractères, de larges zones d’interaction et suffisamment d’espace. Le prototype a interprété ces mots de la manière la plus simple et la plus désastreuse possible.

Il a découpé une mesure qui tenait sur une ligne en trois —nom de l'élément → grand nombre → explication secondaire— puis l’a placée dans une carte énorme. Trois cartes occupaient tout le premier écran, tandis que le travail que l’utilisateur devait traiter immédiatement était repoussé plus bas. L’écran de demande empilait calendar, résumé et inputs dans de grandes boîtes blanches distinctes ; dans la table d’historique, les valeurs essentielles étaient vides et seuls les badges d’état subsistaient. Un scroll horizontal était même apparu.

Lorsque j’avais auparavant corrigé une table et des filtres écrasés sur un véritable appareil mobile, je pensais que supprimer l’overflow et les retours à la ligne cassés suffisait à améliorer l’écran. Ce prototype a révélé un problème plus fondamental. Un écran qui ne casse pas et un écran réellement utilisable sont deux choses entièrement différentes.

Les critères d’audit UI étaient défaillants avant l’écran

Le problème le plus grave était que cet écran avait survécu à une procédure d’audit distincte.

L’audit vérifiait si les routes s’ouvraient, si le texte était coupé, si les controls pouvaient être actionnés et si les couleurs ou les espacements étaient fortement désalignés. Mais il n’imposait pas les questions suivantes.

• L’utilisateur peut-il trouver dès le premier écran le travail qu’il doit traiter maintenant ?
• Les valeurs nécessaires à une même décision sont-elles réunies dans une seule view ?
• L’espace vide explique-t-il les relations entre les informations ou remplit-il simplement la taille du component ?
• La recherche, les filtres, le tri, le nombre total et les résultats d’une table forment-ils un seul flux ?
• Le résultat consulté peut-il être téléchargé à l’identique et réutilisé ?
• Les valeurs modifiables sont-elles distinguées de l’historique qui ne doit pas être écrasé ?

Lorsqu’un problème n’est pas dans l’audit, un Agent peut le voir et tout de même valider l’écran. Au lieu de réduire le padding écran par écran, j’ai donc commencé par modifier les critères communs afin que la même défaillance ne puisse plus passer.

Collection réunit la recherche, les résultats et le téléchargement

La référence que j’ai le plus étudiée était la table de gestion des demandes d’une autre application de congés. Son aide officielle traite également la recherche par date, le filtre des demandes et le flux d’approbation ou de refus en mode administrateur web comme une même tâche.¹ Dans l’image de référence, ce n’était pas le nombre de fonctions qui ressortait, mais la distance entre elles.

La période et le type de demande se trouvaient juste au-dessus des résultats. Les champs de recherche étaient alignés avec leurs colonnes, tandis que le nombre total de demandes et le téléchargement restaient dans la même view. Les valeurs à lire ensemble —dates, avant et après la modification, écart d’heures de travail— étaient regroupées sur plusieurs lignes dans une même cell plutôt que d’ajouter indéfiniment des colonnes. L’état et les actions disponibles se poursuivaient dans la même ligne.

J’ai généralisé cette structure en un contract commun de collection au lieu de la recopier uniquement dans un écran de congés.

• Les tables, grids, listes denses et views en liste du calendar placent le bloc search/filter juste au-dessus des résultats.
• Période et scope, recherche, filtres rapides, filtres détaillés, conditions appliquées, nombre total/actuel, reset et téléchargement restent dans la même view.
• Les valeurs utilisées pour une même décision sont regroupées dans des cells multilignes selon l’ordre information principale → information secondaire → avertissement conditionnel.
• Le contenu détermine la hauteur de la ligne. Plusieurs lignes ne justifient pas de créer des mini cards à hauteur fixe.
• Le téléchargement exporte l’ensemble des résultats correspondant aux conditions courantes, et non les quelques lignes visibles sur la page actuelle.
• L’export conserve le scope, la période, la recherche, les filtres, le tri, l’heure de référence et les colonnes métier visibles par l’utilisateur.
• Les données personnelles et les documents d’audit ne perdent pas entièrement le téléchargement ; ils appliquent la même autorisation, le même masking et le même audit.

Vérifier seulement qu’« un bouton de téléchargement existe » échouerait encore. Il faut aussi comparer le nombre, les lignes représentatives, les filtres appliqués, le tri et le masking de l’écran réel avec le fichier téléchargé.

Le mode d’édition dépend du risque des données

Corriger une valeur directement dans une table est pratique. Mais rendre toutes les cells semblables à Excel permet aussi d’écraser des approbations, des registres et des preuves juridiques comme de simples inputs.

J’ai donc classé la nature du changement avant de choisir le control d’édition.

Nature du changement	Interaction par défaut
Valeur unique, réversible et à faible risque	Inline edit avec affordance d’édition visible
Modifications sûres et répétées sur plusieurs lignes	Editable-grid mode explicite
Plusieurs fields nécessitant le contexte environnant	Side panel qui conserve la position dans la liste
Input ou confirmation courte et autonome	Modal à objectif unique
Changement à haut risque, date d’effet, autorisation, versionné ou append-only	Workflow distinct de preview-and-apply ou correction

Le double-click, Enter et F2 restent uniquement des accélérateurs pour les utilisateurs expérimentés. L’entrée en édition ne doit pas être cachée derrière eux seuls. Un grid a besoin d’une navigation au keyboard, d’une indication des cells modifiées, de validation, d’undo, d’une annulation globale, de la gestion des conflits stale, d’une preview avant application et d’un readback après application. L’approbation, le refus et les événements append-only du registre ne sont pas des cibles de cell edit.

J’ai séparé les règles communes d’audit du contract produit

Si tout ce que j’ai appris de l’écran de référence était écrit comme règles propres à Leave Operations, le projet suivant répéterait la même erreur. À l’inverse, si les étapes d’approbation des congés, les documents de promotion et les corrections du registre entraient dans un Skill commun, le critère partagé deviendrait la spécification d’un seul produit.

J’ai donc séparé les frontières.

Les règles communes et le Skill d’audit UI couvrent ces types de défaillance :

• Transformer un scalar court en immense carte autonome
• Séparer mécaniquement label, valeur et dénominateur sur trois lignes
• Éloigner la recherche et les filtres des résultats
• Collection dépourvue du nombre total, du reset ou du téléchargement de la view courante
• Table qui disperse les valeurs liées dans trop de colonnes ou impose une hauteur fixe aux lignes multilignes
• Export dont l’autorisation ou les conditions de la view courante diffèrent de l’écran
• Édition cachée uniquement derrière le hover ou le double-click
• Écrasement de données à haut risque, versioned ou append-only au moyen de cells ou popups ordinaires

La documentation de Leave Operations associe séparément ces principes à chaque page et view. Les tables de boîte d’approbation, employés, promotion, registre, conflits de présence, résultats de messages et téléphone professionnel reçoivent des contracts de recherche, filtre, tri et téléchargement. Elle sépare aussi les zones nécessitant des modifications répétées, comme les employés et leur rattachement, des approbations et registres qui ne doivent pas être modifiés directement.

Les écrans ne sont pas encore corrigés

Ce travail n’a pas amélioré l’UI réelle du produit. J’ai modifié les règles communes, le Skill d’audit propre à l’UI et les contracts d’écran de chaque produit, puis conservé l’image de référence avec son hash original. Les écrans desktop de Leave Operations ne sont pas encore implémentés selon ces contracts, et les employés de bureau et administrateurs de plus de 50 ans n’ont pas encore terminé eux-mêmes leur tâche depuis le point d’entrée normal.

Le prochain prototype ne devrait toutefois pas être validé pour les mêmes raisons. Les grands caractères et les zones d’interaction suffisamment larges restent des exigences, mais ne doivent pas servir d’excuses pour gonfler l’écran. L’objectif n’est pas une faible densité d'information, mais une forte densité d'information avec une faible charge cognitive.

Références

1. Centre d’aide Shiftee, Gérer les demandes. La page décrit le flux du mode administrateur web pour trouver les demandes par plage de dates et filtre, approuver ou refuser chacune d’elles, puis passer à la suivante. ↩