Atelier 1
Questionner le cahier des charges
- Objectif
- Vérifier que le brief reflétait bien les besoins métier.
- Méthode
- Atelier collaboratif avec les parties prenantes.
- Résultat
- Des workflows absents du cahier des charges mis en lumière.
Institut Catholique de Lille × Tymate | Product Designer · Application web
Institut Catholique de Lille Centraliser et fluidifier la gestion des investissements
Remplacer un outil rigide par une plateforme qui s'adapte à chaque profil.
Chez Tymate, j'ai conçu en binôme avec un second product designer la plateforme web qui modernise la gestion des investissements de l'Institut Catholique de Lille : demandes centralisées, validations automatisées, tableau de bord interactif et gestion des catalogues.
J'ai participé à l'animation des ateliers, à la recherche avec les futurs utilisateurs et à la conception des interfaces, jusqu'au prototype haute fidélité.
- Mon rôle
- Product Designer, facilitation des ateliers
- Équipe
- 2 product designers, agence Tymate
- Durée
- 3 mois · 2023-2024
- Plateforme
- Application web desktop
- Méthodes
- Ateliers, entretiens, tests utilisateurs
- Utilisateurs
- Demandeurs, fonctions support, administrateurs
Contexte
Le client est arrivé avec un cahier des charges détaillé. L'outil en place manquait de souplesse : les demandes circulaient mal entre les équipes, les validations restaient manuelles et le suivi des investissements se faisait sans vision d'ensemble.
Toute la difficulté tenait aux profils : un même outil devait servir des personnes qui déposent une demande, d'autres qui la vérifient et d'autres qui l'arbitrent, avec des habitudes numériques très différentes.
Objectifs
- Confronter le cahier des charges aux besoins réels des utilisateurs.
- Réduire fortement les échanges d'e-mails autour des demandes.
- Favoriser l'adoption de l'outil par toutes les parties prenantes dès la première année.
Les défis
Trois contraintes ont orienté nos choix tout au long du projet.
- 01
Un périmètre de départ trop large
La première version prévoyait des fonctions avancées qui alourdissaient le développement. Nous avons recentré le produit sur un MVP construit autour des usages essentiels.
- 02
Des niveaux de pratique très variés
Certains utilisateurs étaient peu à l'aise avec les outils numériques. L'interface devait éviter les erreurs les plus courantes, comme les saisies en double ou les informations perdues.
- 03
Une intégration technique imposée
La plateforme devait s'appuyer sur l'API existante de l'université, développée par un prestataire. Chaque écran devait tenir compte de ces limites.
Recherche
Nous avons impliqué les parties prenantes et les futurs utilisateurs à chaque étape, à travers trois temps forts.
Atelier 2
Écouter les futurs utilisateurs
- Objectif
- Comprendre les attentes et les contraintes de chaque profil.
- Méthode
- Entretiens semi-directifs avec 4 personnes.
- Résultat
- Les irritants des outils actuels et les besoins essentiels.
Atelier 3
Co-concevoir la solution
- Objectif
- Faire émerger des idées et fixer les priorités.
- Méthode
- Atelier d'idéation avec les utilisateurs, méthode « Six to One ».
- Résultat
- Une liste priorisée d'idées pour bâtir le prototype.
Ce que la recherche a révélé
Chaque constat s'est traduit par un principe de conception.
| Constat | Réponse de conception |
|---|---|
| Trop de choix affichés en même temps | Des parcours guidés, une étape à la fois |
| Des saisies en double et des informations perdues | Sauvegarde automatique et alertes d'erreur |
| Des niveaux de pratique très hétérogènes | Une interface simple d'abord, les fonctions avancées à portée |
Nos recommandations
- Garder pour la première version les fonctionnalités essentielles, et écarter les cas marginaux.
- Automatiser les tâches répétitives pour limiter les erreurs.
- Itérer vite à partir des retours des utilisateurs.
La solution
Une plateforme unique, où chaque profil retrouve ce qui le concerne.
Workflow de validation
Chaque demande suit un circuit clair, avec des statuts mis à jour automatiquement.
Accès selon le profil
Demandeur, fonction support, administrateur : chacun voit les actions qui le concernent.
Tableau de bord
Le suivi des demandes en un coup d'œil, avec des rapports exportables en CSV et XLS.
Catalogues et stock
Les produits référencés et les quantités disponibles ajustent directement les demandes.
Résultats
−90 %d'échanges d'e-mails autour des demandes après la mise en place de la plateforme
MVPun périmètre recentré, livré plus vite et plus simple à faire évoluer
60 %d'utilisation active visée à 12 mois, avec des premiers retours positifs
Ce que j'en retiens
- 01
Le brief est un point de départ, pas une vérité
Les ateliers ont fait apparaître des besoins que le cahier des charges ne mentionnait pas. Je confronte désormais chaque brief aux utilisateurs dès les premiers jours.
- 02
Faire moins, mais mieux
Réduire le périmètre a débloqué le développement et clarifié l'interface. Un MVP bien ciblé apprend plus vite qu'une version complète.
- 03
Prévenir l'erreur plutôt que la corriger
La sauvegarde automatique et les alertes ont rassuré les utilisateurs les moins à l'aise. La confiance se construit aussi dans ces détails.
- 04
Tester dès les wireframes
Certains problèmes repérés tard auraient pu l'être plus tôt. Je place maintenant des tests légers dès les premières esquisses.
Galerie
