Je conçois des produits métier complexes à partir de l’usage réel.

Le contexte

J’ai été recrutée sur le support d’un logiciel de registres dématérialisés. Le métier m’est venu par les questions des utilisateurs, pas par une documentation. La suite est une seule idée reprise à trois échelles : traiter la friction en amont. Une réponse devient un contenu ; une catégorie de demandes devient un indicateur ; douze mois de conversations deviennent un outil de décision.

Les chantiers

1. 01

   Au guichet

   Répondre, former, comprendre. La formation des grands comptes, puis la continuité assurée après un départ sans passation, y compris l’accompagnement du remplaçant.

   À approfondir : La typologie des clients accompagnés, ce qu’une session de formation contenait.

2. 02

   Devancer l’appel

   Les questions qui reviennent deviennent des pages thématiques et des réponses prêtes à l’emploi. La qualification des demandes rend l’effet observable : on voit quelle catégorie baisse, et on choisit le contenu suivant en fonction.

   À approfondir : Le lien explicite entre une catégorie de demandes et le contenu qui l’a fait baisser, et les chiffres publiables en relatif.

3. 03

   Passer à l’échelle

   L’intégralité des conversations de support sur douze mois, classées par module, rien d’écarté, puis rapprochées du suivi de développement alors qu’aucun lien n’existe entre les deux outils. Le tableau de bord qui en sort a été refusé trois fois avant d’être juste : sept onglets sont devenus quatre, chacun portant une question. Le besoin était moins de données, pas plus.

   À approfondir : L’usage réel aujourd’hui : par qui, dans quelles réunions, avec quel effet.

Ce que j’ai produit

Le contexte

Une migration n’est pas un transfert de données : c’est un déménagement pour des gens qui ont des habitudes et des obligations. Il fallait retrouver, pour chaque geste de l’ancien outil, son équivalent dans le nouveau, dire ce qui n’en avait pas, et refuser de promettre ce qui n’existait pas. La récupération des données a été rendue accessible en autonomie depuis la plateforme, sans attendre l’échéance ni passer par le support.

Les chantiers

1. 01

   Les équivalences

   Reprendre geste par geste ce que faisaient les utilisateurs de l’ancien outil, et le retrouver dans le nouveau. Là où il n’y avait pas d’équivalent, le dire plutôt que de le contourner.

   À approfondir : Les cas sans équivalent, et ce qui a été décidé pour chacun.

2. 02

   Les registres de délibérations

   Porter les registres de délibérations dans le nouveau produit et refondre leur import documentaire, pour que les clients venus de l’ancien outil retrouvent un parcours complet.

   À approfondir : Ce que l’import faisait avant, ce qu’il fait après.

3. 03

   Reprendre ses données et partir

   Une page de récupération des données, accessible en autonomie, pour les clients qui ne migrent pas. Le sujet est autant juridique que d’interface : durées de conservation, portabilité, préavis.

   À approfondir : Le détail des obligations retenues et leur traduction en écrans.

Ce que j’ai produit

Le contexte

Le produit avait accumulé les entrées : chaque besoin nouveau avait ajouté sa porte, et plus personne ne trouvait la sienne. La refonte porte sur le cœur, là où se tiennent les titres, les rôles et les assemblées. Elle est validée par mes pairs ; les retours utilisateurs sont attendus.

Les chantiers

1. 01

   L’architecture de l’information

   Réduire le nombre de portes, rendre les parcours lisibles, et qualifier chaque page par ce qu’on y fait : configurer, agir, ou consulter.

   À approfondir : Le récit des versions successives, ce qui a été rejeté et pourquoi.

2. 02

   La gestion des mandats

   Modéliser les rôles de direction, leurs durées, leurs cumuls et leurs conditions de nomination, puis les rendre manipulables sans que l’utilisateur ait à connaître le droit qui les régit. Les rôles changent d’un pays à l’autre : le modèle devait le supporter.

   À approfondir : Le référentiel des rôles, la recherche réglementaire, les cas limites qui ont fait bouger le modèle.

3. 03

   Le démembrement des titres

   Un symptôme d’interface qui remontait à une erreur de modèle de données, avec des conséquences sur les soldes d’actionnaires. Analyse, correction du modèle, spécification de ses invariants.

   À approfondir : Le détail de l’enquête, les invariants retenus, la recette.

4. 04

   Le design system

   Extraire du produit existant un système qui tienne sur l’ensemble : jetons de couleur et d’espacement, composants, états. Il sert d’étape de validation avant le développement.

   À approfondir : L’écart entre les maquettes et la production, et le travail de remise à plat engagé.

Ce que j’ai produit