Étude de cas · Produit · Cas anonymisé

Rendre le produit métier
praticable.

Clarifier des parcours B2B denses dans un contexte de produits hérités, de technologies différentes et de règles métier imbriquées.

Rôle
Design UX/UI Manager
Product Design Lead
Environnement
Produits B2B complexes
Legacy, Product, Engineering
Mandat
Clarification de parcours
et cadrage des arbitrages
Résultat
3 familles de parcours clarifiées
décisions plus explicites avant livraison

01 · Situation

Un portefeuille de produits
aux héritages différents.

Le portefeuille regroupait des produits issus d’histoires différentes : rachats, générations techniques successives, habitudes locales et contraintes métier fortes.

Chaque produit avait une logique propre. Certaines interfaces répondaient à des usages très spécifiques, d’autres portaient encore les traces d’arbitrages anciens. Le sujet n’était donc pas de tout uniformiser, mais de rendre les parcours plus lisibles sans casser ce qui permettait aux utilisateurs de travailler.

Produits hétérogènes
Des interfaces, stacks et conventions qui ne racontaient pas toujours la même chose.
Parcours longs
Formulaires, étapes, statuts, exceptions et retours métier accumulés.
Règles implicites
Des décisions clés connues par les équipes, mais peu visibles dans l’interface.
Refonte risquée
Changer trop vite pouvait fragiliser des usages installés et coûteux à réapprendre.

02 · Cartographie

Comprendre avant
de simplifier.

Distinguer les règles métier des contraintes héritées.

Distinguer ce qui relève du métier, de l’historique produit, de la contrainte technique et de l’habitude d’interface.

J’ai commencé par reconstituer les parcours réels : étapes suivies par les utilisateurs, informations manipulées, décisions prises, dépendances entre écrans et points de friction récurrents.

Cette cartographie a permis d’éviter les raccourcis. Certaines lourdeurs étaient inutiles, d’autres protégeaient une règle métier importante. La qualité du travail venait de cette distinction.

Exemple simplifié de cartographie d’un parcours métier Le parcours va horizontalement de l’information à la décision, puis à l’action et au statut. Une exception forme une branche secondaire sous l’action. Un retour éventuel et discret peut ramener vers le début du parcours. 010203 EntréeChoixSortieÉtat InformationDécisionActionStatutException Exemple simplifié de cartographie verticale d’un parcours métier Le parcours descend de l’information à la décision, puis à l’action et au statut. Une exception forme une petite branche à droite de l’action. Un retour éventuel et discret peut ramener vers le début du parcours. 010203 EntréeChoixSortieÉtat InformationDécisionActionStatutException
Schéma reconstruit et anonymisé.

03 · Clarification

Réorganiser l’écran pour
rendre la décision visible.

Avant

Organisation actuelle

  • Informations réparties par historique technique
  • Statuts difficiles à rapprocher des actions
  • Exceptions visibles trop tard dans le parcours

Après

Organisation clarifiée

  • Contexte et règle métier regroupés
  • Décision attendue, statut et action alignés
  • Exceptions nommées avant validation
01

Regrouper

Rapprocher les informations qui servent à une même décision, au lieu de suivre l’ordre historique des données.

02

Hiérarchiser

Séparer lecture, action, statut et exception pour réduire l’effort de compréhension.

03

Stabiliser

Transformer les solutions récurrentes en patterns réutilisables sur plusieurs parcours.

Décision structurante

Ne pas chercher une interface plus courte à tout prix, mais une interface où l’utilisateur comprend plus vite ce qu’il doit vérifier, décider ou corriger.

04 · Arbitrage

Prioriser les évolutions
selon leur valeur et leur risque.

Dans un contexte legacy, la trajectoire la plus utile réduit la confusion tout en limitant le risque, même lorsqu’elle est peu visible.

  1. 01

    Identifier les irritants

    Repérer les écrans où l’utilisateur hésite, contourne ou sollicite l’équipe support.

  2. 02

    Qualifier le risque

    Comparer impact utilisateur, dette technique, fréquence d’usage et dépendances produit.

  3. 03

    Choisir le bon niveau

    Décider ce qui doit être corrigé localement, transformé en pattern ou remonté au Design System.

  4. 04

    Tester la compréhension

    Vérifier avec les utilisateurs métier, les retours support et les experts produit que la nouvelle organisation réduit réellement les hésitations.

05 · Transmission

Documenter les choix pour qu’ils
puissent être repris par l’équipe.

Les décisions importantes ont été documentées sous forme de principes simples : quand regrouper, quand séparer, comment traiter les exceptions, comment rendre un statut actionnable.

Ce travail a permis aux équipes Product et Engineering de réutiliser les arbitrages au-delà de l’écran traité, sans dépendre d’une validation permanente du design.

  1. Écran critiqueClarifier le parcours et les décisions attendues
  2. Pattern récurrentStabiliser les usages réutilisables
  3. PortefeuilleFaire circuler les repères entre produits

06 · Impact

Des produits plus lisibles et
des décisions plus faciles à reprendre.

  • 3familles de parcours clarifiées
  • Plusde décisions explicites avant livraison
  • Moinsd’ambiguïtés en recette et arbitrage
Utilisateur

Des parcours où les décisions attendues, statuts et exceptions sont plus explicites.

Produit

Des priorités mieux arbitrées entre valeur immédiate, dette et trajectoire long terme.

Engineering

Des évolutions mieux cadrées, avec moins d’ambiguïté sur le comportement attendu.

Design

Des patterns qui dépassent le cas isolé et nourrissent la cohérence du portefeuille.

Ce que je retiens

Dans un produit métier, simplifier consiste à expliciter ce qui aide l’utilisateur à décider et à retirer ce qui l’oblige à deviner.

Échanger sur le sujet

Clarifier les parcoursd’un produit métier complexe.

Parcours B2B, interfaces denses, arbitrages Product / Engineering et trajectoires compatibles avec le legacy.