Impact
« Un formulaire de 17 champs, et personne ne sait pour qui il parle »
Créer un ticket, c'était affronter un formulaire de 17 champs aux intitulés pas toujours clairs. Les champs s'étaient accumulés au fil du temps sans qu'on revoie leur regroupement : deux champs côte à côte n'avaient plus forcément de lien entre eux. Un mode « avancé » envoyait certains champs vers un wizard encore plus complexe, sans régler le problème de fond.
Pour ne frustrer personne, l'équipe avait choisi de tout afficher, ce qui noyait l'information pour tout le monde. Chaque métier se battait pour la visibilité de ses propres champs, et personne ne tranchait.
Rationaliser sans exclure personne
J'ai écarté plusieurs pistes avant de trancher. Tout afficher, c'était le statu quo. N'afficher que les champs obligatoires excluait des besoins métier légitimes. Placer les champs optionnels à côté de ceux qu'ils complètent ne réglait rien non plus. Aucune de ces pistes ne répondait au vrai problème : des milliers d'utilisateurs de métiers différents, aux besoins qui ne se recoupent pas.
La décision s'appuie sur la loi de Hick : plus on présente d'options en même temps, plus on met de temps à décider. En réduisant l'affichage par défaut à un socle commun à tous les tickets, on allège la charge de chacun sans retirer de fonctionnalité à personne.
Ce socle devient un mode Fast, que chacun enrichit avec les champs de son métier : on construit sa boîte de dialogue selon ses besoins au lieu de la subir. Le mode Full correspond à l'état où tous les champs disponibles ont été ajoutés.
Regrouper par intention
J'ai retravaillé le regroupement selon le principe de proximité (Gestalt) : des champs proches visuellement sont perçus comme liés. Chaque groupe devait donc correspondre à une vraie unité de sens, et non à un empilement historique. Quand un groupe est entièrement rempli et devient trop dense, le formulaire passe en étapes au lieu de s'allonger sans fin.
Identité, description, organisation, classification projet.
Dates, jalons et décalages dans le temps (timeshift).
Dépendances entre livrables, blocage de clôture.
Accordéons épinglables, état mémorisé par utilisateur.
Regrouper ne suffisait pas à expliquer l'usage de chaque champ. J'ai donc ajouté des infobulles dans les champs concernés, surtout sur les dates, historiquement les plus mal comprises. C'est le principe de reconnaissance plutôt que rappel (Nielsen) : l'utilisateur trouve l'information au moment où il en a besoin, au lieu de devoir s'en souvenir.
Distinguer ce qui s'active de ce qui est optionnel
Les fonctionnalités complémentaires au livrable s'activent désormais avec un toggle, et non plus comme un champ optionnel parmi d'autres. Le toggle montre clairement un état binaire, disponible mais non activé. C'est le principe de visibilité de l'état du système (Nielsen).
Le choix du type de ticket sort du formulaire principal. Il ouvre une boîte de dialogue dédiée qui pré-remplit ce qui peut l'être. Cela sépare la décision de type, qui structure tout le reste, de la saisie courante.
Ce qui reste à améliorer
La fonction pour ajouter des champs existe, mais elle reste difficile à trouver : son point d'accès n'a pas encore trouvé sa place idéale. Le panneau de configuration gagnerait aussi à être ouvert par défaut.
