Contexte
Tessan répond à un problème d’accès aux soins : permettre une consultation médicale dans les zones où l’offre médicale manque, via des dispositifs déployés en pharmacie ou directement chez le patient.
Produit mature côté business, Tessan n’avait jamais été accompagné par un designer. Sans design system ni référence commune, les interfaces avaient dérivé chacune de leur côté : boutons d’action, couleurs, structures, alertes sans pattern cohérent … Au-delà du visuel, cette dérive pesait directement sur l’expérience patient ainsi que sur le coût de chaque nouvelle fonction, et sur sa maintenance. Une nouvelle charte graphique, lancée entre-temps sur le site web, avait par ailleurs été pensée pour du marketing plutôt que pour des interfaces produit — une contrainte avec laquelle il a fallu composer, plutôt qu’un cadre prêt à appliquer.
Objectifs
→ Mutualiser la conception et la production pour gagner en cohérence et en agilité
→ Recentrer les fonctions sur l’usager plutôt que sur le seul calendrier business
→ Construire des sources de référence versatiles et évolutives (visuelles et usages) garantes d’une source de qualité à chaque nouvelle fonction
Mon rôle
Product designer freelance intégrée à l’équipe produit sur trois axes menés en parallèle.
→ Construire le design system
Le concevoir et assurer son adoption : ateliers avec l’équipe produit, mise en place d’un Storybook pour les développeurs, et un travail de fond auprès de l’équipe technique pour poser les bases et faire évoluer la collaboration.
→ Conseiller et challenger l’équipe produit
Poser un regard extérieur sur les propositions de fonctions, pour pousser vers des solutions versatiles et plus centrées sur l’utilisateur
→ Concevoir des solutions ciblées
Plusieurs sujets menés de bout en bout, dont un problème critique d’orientation patient en salle d’attente et la refonte du parcours d’inscription.
Rétrospectives de collaboration autour du design system
Process
Le point de départ n’était pas un produit en cours de conception mais un existant en production. Un système donc, à faire émerger à partir d’audits des interfaces et compréhension des usages.
Le parti pris a été de construire des composants proches de l’existant, pour permettre des livraisons rapides et progressives par blocs (inscription, matching, historique…). De cette façon, les nouveaux blocs ont pu coexister avec le legacy sans trop de disparité.
Sous cette proximité visuelle, la structure, le UI et les patterns ont été largement retravaillés, permettant une première passe d’améliorations.
Au-delà des blocs, la priorité a d’abord été donnée aux fondations et aux composants les plus largement utilisés, pour s’élargir ensuite aux éléments singuliers.
Des tokens ont rapidement été mis en place pour préparer la bascule vers la nouvelle charte graphique, et assurer la cohérence en devenir.
Les utilisations des composants ont été documentées directement dans Figma.
Extraits du design system
Variables
Extrait de documentation
Cas pratiques
Matching
→ Problématique
Le point d’entrée du parcours de téléconsultation demande de choisir entre médecin généraliste et spécialiste — un choix présenté maladroitement menant régulièrement les patients dans la mauvaise file d’attente. Service client saturé sur ce seul sujet, patients qui attendaient longtemps pour repartir sans consultation faute du bon praticien : une urgence opérationnelle plus qu’un problème de conversion.
→ Solution
Des échanges avec le service client, en première ligne des patients concernés, ont permis d’identifier deux causes concrètes :
→ la prise de rendez-vous fictive générée par Doctolib (utilisée à des fins marketing) était interprétée comme un vrai rendez-vous, poussant à sélectionner “Spécialiste, j’ai un rendez-vous”
→ quand la file “généraliste” était saturée, certains patients tentaient de la contourner par l’accès spécialiste
Refonte de l’écran de choix, sous contrainte de développement rapide — composants simples, réutilisables, intégrés au design system :
→ titre flou remplacé par un titre principal et un sous-titre qui pointe vers l’action
→ deux tuiles de couleurs distinctes, pour une différenciation immédiate entre les deux choix
→ ajout d’icônes propres à chaque type de médecin, en évitant d’utiliser un calendrier comme dans l’existant pour minimiser la confusion
→ badge “créneau Doctolib” plutôt que “rendez-vous”
→ badge d’alerte sur la tuile spécialiste, signalant l’obligation d’un rendez-vous avec modale de confirmation
→ Résultats
Après déploiement, les demandes du service client liées à ce problème ont drastiquement chuté. Les directions prises au niveau des composants ont été un point de départ pour faire évoluer les éléments similaires du produit (modales, structure d’étapes, badges …)
Évolution de l’écran de choix
Composants
Inscription
→ Problématique
L’audit du parcours d’inscription — mené en début de mission — avait révélé une friction élevée à chaque étape : trop de champs par écran, clavier inadapté, priorisation des informations à revoir, choix manquants d’évidence, aucune confirmation claire en sortie de parcours. En usage réel sur cabine et borne, où se concentre la majorité des inscriptions, ces frictions se traduisaient concrètement : abandons, patients qui n’arrivaient pas à aller au bout seuls, et sollicitation constante des pharmaciens pour accompagner ou faire l’inscription à leur place.
Audit du parcours d’inscription
→ Solution
Quelques exemples de points retravaillés, abordés en termes de criticité :
→ Refonte de l’UX du formulaire : simplification du remplissage, hiérarchie claire de l’information, texte plus grand et plus lisible pour une consultation à distance de l’écran, réalité de l’usage en cabine
→ Reprise complète de l’UX writing sur tout le parcours — titres, sous-titres, boutons d’action — permettant l’accompagnement qu’il manquait et l’instauration d’un sentiment de confiance et de fiabilité
→ Suppression des étapes non nécessaires, automatisations, clarification des choix à effectuer
→ Connexion automatique après inscription
Quelques écrans d’authentification
Structure
Territorialité
→ Problématique
Une obligation réglementaire imposait de prioriser les médecins du territoire du patient plutôt que l’ensemble des médecins disponibles en France par défaut — une logique peu pertinente en téléconsultation, où la localisation du praticien importe peu. Restreindre la zone par défaut allonge mécaniquement le temps d’attente en salle virtuelle, alors que la promesse du produit est une téléconsultation en moins de 15 minutes. L’enjeu : respecter l’obligation tout en donnant à l’utilisateur les moyens d’élargir son rayon pour retrouver un temps d’attente correct.
→ Solution
→ Ville sélectionnée par défaut — la zone la plus restreinte, conforme à l’obligation réglementaire, sans bloquer l’accès aux zones plus larges
→ Zones concentriques (ville, région, France entière), chacune affichant le nombre de médecins disponibles et un temps d’attente estimé
→ Mise en avant visuelle de la zone la plus large via un badge “plus rapide”
→ Modale proposant explicitement d’élargir la zone pour réduire le temps d’attente
→ Liste de médecins disponible en complément, pour le choix d’un praticien en particulier (le filtrage par compétence restant hors périmètre de cette V1) — volontairement traitée en retrait visuel par rapport aux zones
Sélection avant entrée en salle d’attente
Autres chantiers
→ Accompagnant
Certains patients ne peuvent pas gérer leur compte seuls — trop jeunes, trop âgés, ou dépendants d’un tiers pour la consultation : infirmiers utilisant la mallette directement chez le patient, pharmaciens accompagnant un patient en cabine. Une obligation réglementaire imposait de capturer cette identité séparément. Solution : un formulaire d’identité dédié à l’accompagnant, et une liste de rôles familiaux issue d’un référentiel de santé officiel — une trentaine d’entrées à l’origine — retravaillée et priorisée pour un usage patient rapide.
User flow accompagnant
→ Pharma locator
Deux besoins distincts : trouver une pharmacie équipée d’une cabine avant une consultation, ou partager une ordonnance avec une pharmacie après une téléconsultation faite ailleurs (à terme, depuis l’application mobile). Conçu comme un MVP, le parcours combine une entrée autonome (carte et liste de pharmacies) et une entrée en fin de téléconsultation (choix du document à partager, choix de la pharmacie, confirmation avec itinéraire). Côté pharmacien, une interface de gestion des ordonnances reçues avec filtres par statut.
User flows
MVP gestion des ordonnances
