ClinSearch

<h1>Context</h1><p>ClinSearch supports pharmaceutical companies, contract research organizations, universities and public institutions in conducting clinical studies.</p><p>The company already had an internal tool to manage these studies. It wanted to strengthen its software business with <strong>EDClin: a software suite covering the full journey from study build to study closeout</strong>.</p><p>I joined as a Product Designer with an initial brief focused on a clinical form builder. As I explored the subject in greater depth, the nature of the scope changed: every form depends on a protocol, a schedule of visits, data collection rules and clearly defined responsibilities.</p><p><strong>The real challenge became making the lifecycle of a regulated study understandable while preserving the controls that make its data reliable.</strong></p><h1>Key figures</h1><ul><li><p><strong>10 months</strong> of work, from scoping to design documentation.</p></li><li><p><strong>3 web applications</strong> in the target architecture: administration, study build and data collection.</p></li><li><p><strong>10 user roles</strong> considered when designing access rights and responsibilities.</p></li><li><p><strong>More than 100 screens</strong> designed for desktop use, along with animated prototypes.</p></li><li><p><strong>More than 80 components</strong> in a design system built on an open-source foundation, complete with design tokens.</p></li></ul><h1>The initial situation</h1><p>The existing tool had grown through successive additions. Its workflows had become difficult to follow, and setting up a new study still relied heavily on manual work.</p><ul><li><p>Clinical Project Managers had to <strong>annotate Excel exports and interpret large data tables</strong> to understand progress.</p></li><li><p>The rigidity of the tool required <strong>custom development for each study</strong>.</p></li><li><p>Regulatory review discussions took place outside the software, fragmenting the decision trail.</p></li><li><p>Gaps in regulatory coverage limited ClinSearch’s commercial and international ambitions.</p></li></ul><p>Form creation brought all these difficulties together: what looked like a questionnaire also defined the data that would be collected, reviewed and used throughout the study.</p><h1>Before</h1><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt8ium91o3s4kmo0k2p12fw.png"><div class="image-overlay"></div></div></div></div><ul><li><p>A setup process split between the internal tool, Excel files and conversations outside the product.</p></li><li><p>A strong dependency on the technical team to adapt data collection to the protocol.</p></li><li><p>Fragmented visibility into what was ready, what still required review and who needed to act.</p></li></ul><h1>After</h1><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt8j1f71o4n4kmo41l1cgw6.png"><div class="image-overlay"></div></div></div></div><ul><li><p>A <strong>Builder</strong> connecting visits, forms and data collection rules within a single study configuration.</p></li><li><p>Libraries of reusable resources to avoid rebuilding every form.</p></li><li><p>A <strong>Review → Approve → Deploy</strong> workflow connecting review, approval and deployment.</p></li><li><p>Changes explained and placed in context before a study is updated.</p></li></ul><h1>The challenge</h1><p><strong>Give clinical teams greater autonomy while making the consequences of their decisions visible.</strong></p><p>This meant:</p><ul><li><p>Designing a coherent ecosystem with dependencies between data, screens, roles and states.</p></li><li><p>Supporting novice users while preserving the level of control expected by experienced Data Managers.</p></li><li><p>Translating business and regulatory constraints into concrete interface behaviors.</p></li><li><p>Structuring the product work while the PM role had limited coverage during the design phase.</p></li><li><p>Preparing the design and specifications for handover to the internal teams.</p></li></ul><h1>Impact &amp; Results</h1><h3>A shared goal: from six weeks to five days</h3><p>Together with the CEO and CTO, we set a target: <strong>reduce the time between contract signature and the availability of the electronic Case Report Form, or eCRF, from 8 weeks to 2 weeks</strong>.</p><p>This goal relied on four levers designed together: form reuse, study schedule configuration, an integrated review and approval workflow, and automated deployment of the data collection interface.</p><p><strong>This was a target validated with the company’s leadership, not an improvement measured in actual use.</strong></p><h3>Deliverables supporting this ambition</h3><ul><li><p><strong>A clearly defined product architecture</strong>: the responsibilities of each application and their dependencies were established.</p></li><li><p><strong>Detailed design workflows</strong>: project creation, form building, site preparation and deployment management.</p></li><li><p><strong>A reusable UI foundation</strong>: components, design tokens and documented behaviors to support future development.</p></li><li><p><strong>Handover specifications</strong>: validated decisions were documented for the technical teams and the internal handover.</p></li></ul><p>Reducing custom development, easing the workload of Project Managers and opening access to new markets remained the intended benefits.</p><h1>The team</h1><ul><li><p><strong>1 CEO</strong>, responsible for the strategic vision.</p></li><li><p><strong>1 CTO</strong>, the technical decision-maker, working with a development team of 3 to 8 people.</p></li><li><p><strong>2 Regulatory Affairs Managers</strong>.</p></li><li><p><strong>1 Senior Product Designer (myself)</strong>, responsible for scoping, design and specifications.</p></li><li><p><strong>1 PM</strong>, mainly involved in the next phase of the project, once the design had been established.</p></li></ul><p>I worked continuously with Clinical Project Managers, Data Managers and developers. I also supported designers during the internal handover.</p><p>During the design phase, my role included product scoping responsibilities: assessing needs, organizing the backlog, estimating the design workload and preparing scope trade-offs.</p><h1>Methodology</h1><h2>1. Discovery</h2><p>I drew on user research conducted before I joined, involving around ten people interviewed on site. I continued this work through regular discussions with Data Managers and business teams.</p><p>In parallel, I studied domain literature, the frameworks used by the regulatory team and existing market solutions. Thematic workshops brought together business, technical and regulatory stakeholders. When a specific issue blocked a decision, I organized a focused discussion with the relevant experts.</p><p>This immersion allowed me to connect the needs into a coherent sequence: <strong>protocol → visits → forms → rules → review → deployment</strong>.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt8kipt1m4q4kjc1dva9lf1.png"><div class="image-overlay"></div></div></div></div><p><em>Caption : Mapping regulatory sequences and business needs / Desk research using textbooks written for medical students</em></p><h2>2. UI Foundations / Design System: bringing consistency to the ecosystem</h2><p>I defined the boundaries between three applications:</p><ul><li><p><strong>Admin Hub</strong>: managing organizations, teams and access without exposing clinical data.</p></li><li><p><strong>Builder</strong>: defining the study, its forms, its rules and the configurations to be deployed.</p></li><li><p><strong>EDC Runtime</strong>: running the study and collecting data. Its role and interfaces with the Builder were defined at an architectural level; its detailed design was outside the scope of this iteration.</p></li></ul><p>On this foundation, I built a design system to bring consistency to interactions across complex forms, large tables, navigation, states and system feedback.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt8jmjh1mas4kj548wy79zc.png"><div class="image-overlay"></div></div></div></div><h2>3. Design Sprints: using screens to clarify the requirements</h2><p>There were no specifications at the start of the project. <strong>Each screen served as a working hypothesis</strong>: it made a proposal tangible, enabled experts to challenge it and brought missing rules to light.</p><p>I organized the requirements into work packages, estimated the design effort and scheduled workshops along the roadmap. Each package went through design and review loops with business, technical and regulatory stakeholders.</p><p>Specifications were written once the decisions had been validated. They documented behaviors, states and dependencies so developers could understand the reasoning behind the screens.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt8l2kr1ktb4kka23b3gxb9.png"><div class="image-overlay"></div></div></div></div><h1>Decisions &amp; Trade-offs</h1><p>Three tensions guided the design:</p><p>Tension Design decision Accepted trade-off Accessibility for novices / control for experts A shared structure, with advanced settings revealed progressively. Organizing complexity requires more work than multiplying screens or hiding options. Reuse / study stability Copy resources from a library into the study, with no automatic link for future updates. Improvements to the shared template must be brought explicitly into the relevant studies. Speed of change / control over consequences Separate draft work from changes made after deployment. A study change requires an impact review before approval.</p><h1>Key outcomes</h1><h2>1. Form Editor: making an expert data model manageable</h2><p>The form builder had to serve two profiles: someone who wants to reproduce a protocol and a Data Manager who wants control over variables, stored values and validation rules.</p><p><strong>I chose a shared structure with progressive disclosure of advanced settings.</strong> Users build their form and access the details of the data model when their task requires it.</p><p>One example captures the challenge: a medical date may only be known to the year or month. The design supports these levels of precision, representing the information available without forcing users to enter a complete date.</p><p>The model also includes stable identifiers, a distinction between displayed labels and stored values, and controlled value lists. Referred to as “CDASH / SDTM Lite” during the project, this approach adopts some foundations of clinical data standards without making knowledge of them a prerequisite for using the interface.</p><p>Finally, libraries allow forms and items to be reused. <strong>Each resource is copied into the study</strong>: a later update to the library must not silently alter an ongoing study.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt8ligf1oes4khbevov7a1r.png"><div class="image-overlay"></div></div></div></div><p><em>Caption : A shared structure that makes forms easy to build while preserving control over the data collected.</em></p><h2>2. Review &amp; Deployment: understanding a change before approving it</h2><p>Reviewing a form in isolation is not enough: its behavior may depend on other forms, visits or cross-study rules. The design therefore distinguishes form-level review from review within the context of the study.</p><p>The same reasoning transformed deployment. Changing a configuration already in use may affect future data collection or the interpretation of existing data. The workflow must make these consequences reviewable.</p><p>I structured the lifecycle as <strong>draft → test environment → approved and deployed version → amendment</strong>. The <em>Delta &amp; Impact Viewer</em> was designed to answer the validator’s questions: what changed, why and with what impact?</p><p>Approval applies to an identified version of the configuration. Returning to a previous state is also controlled: it must preserve the chain of changes and the history of what was used.</p><p><strong>This work turned deployment into an explicit decision, supported by context and a traceable record.</strong></p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt8md3o1map4kjcf3pk4kdt.png"><div class="image-overlay"></div></div></div></div><p><em>Caption : Diagram explaining the lifecycle of a clinical study project, including deployment to a test environment and updates to the live version.</em><br></p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt8msfi1mko4kjm0wg7btpi.png"><div class="image-overlay"></div></div></div></div><p><em>Caption : Giving the validator the context needed to approve a specific version.</em></p><h2>3. Site Activation: making site readiness visible</h2><p>At first, an “Active” status seemed sufficient to summarize the availability of a research site. A closer look at the model revealed that a site could be ready for some activities but not others.</p><p><strong>Activation was therefore reframed as the outcome of a verifiable preparation process.</strong> The design brings together prerequisites, training, supporting evidence, responsibilities and the required access rights.</p><p>The site page must show what is ready, what is missing and who needs to act. It also distinguishes the Medical Center, a long-term entity, from its participation in a specific study.</p><p>This distinction makes it possible to reuse information about the center while preserving the conditions and responsibilities specific to each study.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt8n5i91oic4km3beb7hqff.png"><div class="image-overlay"></div></div></div></div><p><em>Caption : Moving from a global status to clear, actionable readiness.</em></p><h1>Key learnings</h1><h3>Consider change from the moment the model is designed</h3><p>At first, I underestimated the consequences of changing the configuration of a study that had already been deployed. Changing a data domain can have cascading effects; addressing this issue late meant revisiting screens that had already been validated.</p><p>On a future product of this kind, I would define change management and dependencies earlier, alongside the initial creation workflow.</p><h3>Formalize the product mandate at the outset</h3><p>The latitude given to me by the CEO allowed me to structure the project. It also meant carrying scope trade-offs alongside the design work without an explicit product mandate.</p><p>I would now clarify at kick-off who prepares priorities, who makes the final decisions and how changes in scope are handled.</p><h3>Keep the architecture extensible and the scope focused</h3><p>The project progressively expanded into monitoring, alerts and advanced analytics. I had to refocus the core work on the <strong>protocol → build → validation → deployment</strong> sequence, while separating strategic extensions.</p><p>Preparing a product for future growth also means deciding what can wait.</p><h3>Make domain complexity easier to navigate</h3><p>A business distinction may look unnecessary on screen and become essential once its consequences are examined. This project taught me to question proposed simplifications: what information disappears, what control is lost and who needs it?</p><p>My role was to place information and controls at the point where they support a decision, with a level of detail suited to the task.</p><h3>Limitations &amp; hypotheses</h3><p>The design draws on three levels of knowledge:</p><ul><li><p><strong>Desk and regulatory research</strong>, which informed the data, traceability and lifecycle models.</p></li><li><p><strong>Existing user research and discussions with business teams during the engagement</strong>, which informed the workflows and design reviews. Data Managers were particularly involved; not every role was studied to the same depth.</p></li><li><p><strong>Design hypotheses</strong>, particularly around novice autonomy, understanding impact and the expected time savings. Their effectiveness remains to be established through usability testing and dedicated measurement.</p></li></ul>

From scoping to specifications, designing a tool that enables teams to build a study, review its configuration and manage how it evolves.


Product Designer

UX/UI Designer

UX Designer

Designing a clinical study platform that meets the complexity of the domain

<h1>Contexte</h1><p>ClinSearch accompagne les laboratoires pharmaceutiques, les organismes de recherche clinique, les universités et les institutions publiques dans la conduite de leurs études cliniques.</p><p>L’entreprise dispose d’un outil interne pour gérer ces études. Elle souhaite renforcer son activité d’éditeur avec <strong>EDClin : une suite logicielle couvrant la construction d’une étude jusqu’à sa clôture</strong>.</p><p>J’interviens comme Product Designer avec une demande initiale centrée sur un créateur de formulaires cliniques. En approfondissant le sujet, le périmètre change de nature : chaque formulaire dépend d’un protocole, d’un calendrier de visites, de règles de collecte et de responsabilités précises.</p><p><strong>Le véritable enjeu devient de rendre compréhensible le cycle de vie d’une étude réglementée, en préservant les contrôles qui rendent la donnée fiable.</strong></p><h1>Quelques chiffres</h1><ul><li><p><strong>10 mois</strong> de mission, du cadrage à la documentation de conception.</p></li><li><p><strong>3 applications web</strong> dans l’architecture cible : administration, construction des études et collecte des données.</p></li><li><p><strong>10 rôles utilisateurs</strong> pris en compte dans la conception des accès et des responsabilités.</p></li><li><p><strong>Plus de 100 maquettes</strong> adaptées aux usages desktop et accompagnées de prototypes animés.</p></li><li><p><strong>Plus de 80 composants</strong> dans un design system construit sur une base open source, avec ses design tokens.</p></li></ul><h1>Le constat</h1><p>L’outil existant s’est enrichi par ajouts successifs. Les parcours sont devenus difficiles à suivre et la préparation d’une nouvelle étude repose encore largement sur des interventions manuelles.</p><ul><li><p>Les chefs de projet clinique doivent <strong>annoter des exports Excel et interpréter de grandes tables de données</strong> pour comprendre l’avancement.</p></li><li><p>La rigidité de l’outil entraîne <strong>du développement sur mesure pour chaque étude</strong>.</p></li><li><p>Les échanges de revue réglementaire se déroulent en dehors du logiciel, ce qui fragmente le suivi des décisions.</p></li><li><p>La couverture des exigences réglementaires constitue un frein à l’ambition commerciale et internationale de ClinSearch.</p></li></ul><p>La création des formulaires concentre ces difficultés : ce qui ressemble à un questionnaire est aussi la définition des données qui seront collectées, vérifiées et exploitées pendant l’étude.</p><h1>Avant</h1><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt7xx8a1k364kj565442rke.png"><div class="image-overlay"></div></div></div></div><ul><li><p>Une préparation répartie entre l’outil interne, des fichiers Words et Excel et des échanges externes.</p></li><li><p>Une forte dépendance à l’équipe technique pour adapter la collecte au protocole.</p></li><li><p>Une visibilité fragmentée sur ce qui est prêt, ce qui reste à vérifier et qui doit intervenir.</p></li></ul><h1>Après</h1><p></p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt7p1mt1l4y4jixh7wwd2su.png"><div class="image-overlay"></div></div></div></div><ul><li><p>Un <strong>Builder</strong> reliant les visites, les formulaires et les règles de collecte dans une même configuration d’étude.</p></li><li><p>Des bibliothèques de ressources réutilisables pour éviter de reconstruire chaque formulaire.</p></li><li><p>Un parcours <strong>Review → Approve → Deploy</strong> pour articuler la revue, l’approbation et le déploiement.</p></li><li><p>Des changements explicités et contextualisés avant de faire évoluer une étude.</p></li></ul><h1>Le défi</h1><p><strong>Donner de l’autonomie aux équipes cliniques tout en rendant visibles les conséquences de leurs décisions.</strong></p><p>Cela impliquait de :</p><ul><li><p>Concevoir un écosystème cohérent, avec des dépendances entre données, écrans, rôles et états.</p></li><li><p>Accompagner les utilisateurs novices tout en conservant le niveau de contrôle attendu par les Data Managers expérimentés.</p></li><li><p>Traduire les contraintes métier et réglementaires en comportements d’interface concrets.</p></li><li><p>Structurer le travail produit alors que le rôle de PM était peu couvert pendant la conception.</p></li><li><p>Préparer la reprise du design et des spécifications par les équipes internes.</p></li></ul><h1>Impact &amp; Résultats</h1><h3>Un objectif partagé : passer de six semaines à cinq jours</h3><p>Avec le CEO et le CTO, nous avons fixé une cible : <strong>ramener de 8 semaines à 2 semaines le délai entre la signature et la disponibilité du formulaire électronique de collecte, ou eCRF</strong>.</p><p>Cet objectif repose sur quatre leviers conçus ensemble : la réutilisation des formulaires, la configuration du calendrier de l’étude, l’intégration du parcours de revue et d’approbation, et le déploiement automatique de l’interface de collecte.</p><p><strong>Il s’agit d’un objectif cible validé avec la direction, et non d’un gain mesuré en usage.</strong></p><h3>Des livrables pour soutenir cette ambition</h3><ul><li><p><strong>Une architecture produit explicitée</strong> : les responsabilités de chaque application et leurs dépendances sont définies.</p></li><li><p><strong>Des parcours de conception détaillés</strong> : création de projet, construction des formulaires, préparation des centres et gestion des déploiements.</p></li><li><p><strong>Un socle UI réutilisable</strong> : composants, design tokens et comportements documentés pour accompagner les évolutions.</p></li><li><p><strong>Des spécifications de transmission</strong> : les décisions validées sont formalisées pour les équipes techniques et la reprise interne.</p></li></ul><p>La réduction du développement sur mesure, l’allègement de la charge des chefs de projet et l’accès à de nouveaux marchés restent les bénéfices recherchés.</p><h1>L’équipe</h1><ul><li><p><strong>1 CEO</strong>, porteur de la vision stratégique.</p></li><li><p><strong>1 CTO</strong>, décideur technique, avec une équipe de développement de 3 à 8 personnes.</p></li><li><p><strong>2 responsables réglementaires</strong>.</p></li><li><p><strong>1 Senior Product Designer (moi-même)</strong>, chargé du cadrage, de la conception et des spécifications.</p></li><li><p><strong>1 PM</strong>, principalement impliqué dans la suite du projet, après l’établissement de la conception.</p></li></ul><p>J’ai travaillé en continu avec les chefs de projet clinique, les Data Managers et les développeurs. J’ai également accompagné des designers dans la passation interne.</p><p>Pendant la phase de conception, mon rôle a inclus des responsabilités de cadrage produit : évaluer les besoins, organiser le backlog, estimer la charge design et préparer les arbitrages de périmètre.</p><h1>Méthodologie</h1><h2>1. Discovery</h2><p>Je me suis appuyé sur une recherche utilisateur menée avant mon arrivée auprès d’environ dix personnes sur site. J’ai poursuivi ce travail par des échanges réguliers avec les Data Managers et les équipes métier.</p><p>En parallèle, j’ai étudié la littérature du domaine, les référentiels utilisés par l’équipe réglementaire et les solutions existantes. Les ateliers thématiques réunissaient métier, technique et réglementaire ; lorsqu’un point bloquait une décision, j’organisais un échange ciblé avec les responsables concernés.</p><p>Cette immersion a permis de relier les besoins à une chaîne cohérente : <strong>protocole → visites → formulaires → règles → vérification → déploiement</strong>.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt7pws81iv84kjc7dh0dd1b.png"><div class="image-overlay"></div></div></div></div><p><em>Légende : Cartographie des séquences réglementaires et des besoins métiers / Etude documentaire avec usage de manuels destinés aux étudiants médecins</em></p><h2>2. Fondations UI / Design System : donner une cohérence à l’écosystème</h2><p>J’ai formalisé la séparation entre trois applications :</p><ul><li><p><strong>Admin Hub</strong> : administrer les organisations, les équipes et les accès, sans exposer les données cliniques.</p></li><li><p><strong>Builder</strong> : définir l’étude, ses formulaires, ses règles et les configurations à déployer.</p></li><li><p><strong>EDC Runtime</strong> : exécuter l’étude et collecter les données. Son rôle et ses interfaces avec le Builder ont été cadrés architecturalement ; sa conception détaillée était hors du périmètre de cette itération.</p></li></ul><p>Sur cette base, j’ai construit un design system pour harmoniser les interactions : formulaires complexes, grandes tables, navigation, états et retours système.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt7qryk1j2q4klj67dr3y94.png"><div class="image-overlay"></div></div></div></div><h2>3. Design Sprints : utiliser les maquettes pour préciser le besoin</h2><p>Les spécifications n’existaient pas au démarrage. <strong>La maquette servait d’hypothèse de travail</strong> : elle rendait une proposition concrète, permettait aux experts de la challenger et faisait émerger les règles manquantes.</p><p>J’ai organisé les besoins en lots, estimé la charge design et positionné les ateliers sur la roadmap. Chaque lot passait par des boucles de conception et de revue avec les interlocuteurs métier, techniques et réglementaires.</p><p>Les spécifications étaient rédigées après validation des choix. Elles documentaient les comportements, les états et les dépendances pour transmettre aux développeurs le raisonnement derrière les écrans.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt7r3zk1l9j4kjp8zap4tro.png"><div class="image-overlay"></div></div></div></div><h1>Décisions &amp; arbitrages</h1><p>Trois tensions ont guidé la conception :</p><p>Tension Choix de conception Compromis assumé Accessibilité pour les novices / contrôle pour les experts Une structure commune, avec des réglages avancés révélés progressivement. Organiser la complexité demande davantage de travail que multiplier les écrans ou masquer les options. Réutilisation / stabilité d’une étude Copier les ressources d’une bibliothèque dans l’étude, sans lien de mise à jour automatique. Une amélioration du modèle partagé doit être reprise explicitement dans les études concernées. Rapidité de modification / maîtrise des conséquences Distinguer le travail en brouillon des changements après déploiement. Une modification d’étude impose une revue de ses impacts avant approbation.</p><h1>Réalisations clés</h1><h2>1. Form Editor : rendre un modèle de données expert manipulable</h2><p>Le créateur de formulaires doit servir deux profils : une personne qui veut reproduire son protocole et un Data Manager qui veut contrôler les variables, les valeurs stockées et les règles de vérification.</p><p><strong>J’ai retenu une structure commune avec une divulgation progressive des paramètres avancés.</strong> L’utilisateur construit son formulaire ; il accède au détail du modèle de données lorsque sa tâche l’exige.</p><p>Un exemple révèle l’enjeu : une date médicale peut être connue seulement à l’année ou au mois. La conception prévoit ces niveaux de précision, afin de représenter l’information disponible sans forcer une date complète.</p><p>Le modèle intègre aussi des identifiants stables, la distinction entre libellé affiché et valeur stockée, ainsi que des listes de valeurs contrôlées. Cette approche, appelée « CDASH / SDTM Lite » pendant le projet, reprend certaines fondations des standards de données cliniques sans en faire un prérequis pour utiliser l’interface.</p><p>Enfin, les bibliothèques permettent de réutiliser des formulaires et des éléments. <strong>Chaque ressource est copiée dans l’étude</strong> : une modification ultérieure de la bibliothèque ne doit pas modifier silencieusement une étude en cours.</p><p></p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt7rjxf1jfj4kkdewzn9uw3.png"><div class="image-overlay"></div></div></div></div><p><em>Légende : Une même structure pour construire simplement et garder le contrôle sur les données collectées.</em></p><h2>2. Review &amp; Deployment : comprendre un changement avant de l’approuver</h2><p>La vérification d’un formulaire isolé ne suffit pas : son comportement peut dépendre d’autres formulaires, de visites ou de règles transverses. La conception distingue donc une revue au niveau du formulaire et une revue dans le contexte de l’étude.</p><p>Le même raisonnement a transformé le déploiement. Modifier une configuration déjà utilisée peut affecter la collecte future ou l’interprétation de données existantes. Le parcours doit rendre ces conséquences examinables.</p><p>J’ai structuré le cycle <strong>brouillon → environnement de test → version approuvée et déployée → amendement</strong>. La conception du <em>Delta &amp; Impact Viewer</em> répond aux questions du responsable de validation : qu’est-ce qui a changé, pourquoi et avec quels impacts ?</p><p>L’approbation porte sur une version identifiée de la configuration. Le retour à un état antérieur est lui aussi encadré : il doit conserver la chaîne des changements et l’historique de ce qui a été utilisé.</p><p><strong>Ce travail a fait du déploiement une décision explicite, avec un contexte et une trace.</strong></p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt7s4rz1hv84kj78ytj7v1z.png"><div class="image-overlay"></div></div></div></div><p><em>Légende : Schéma expliquant le cycle de vie d'un projet d'étude clinique comprenant le déploiement d'environnement de test et de mise à jour de version publique.</em></p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt7s99h1lje4jix0k62fjb2.png"><div class="image-overlay"></div></div></div></div><p><em>Légende : Donner au responsable de validation le contexte nécessaire pour approuver une version précise.</em></p><h2>3. Site Activation : rendre visibles les conditions de préparation d’un centre</h2><p>Le statut « Active » semblait pouvoir résumer la disponibilité d’un centre de recherche. En approfondissant le modèle, il est apparu qu’un centre pouvait être prêt pour certaines activités et pas pour d’autres.</p><p><strong>L’activation a donc été repensée comme l’aboutissement d’une préparation vérifiable.</strong> La conception rassemble les prérequis, les formations, les justificatifs, les responsabilités et les accès nécessaires.</p><p>La fiche du centre doit permettre de comprendre ce qui est prêt, ce qui manque et qui doit agir. Elle distingue également le centre médical, entité durable, de sa participation à une étude précise.</p><p>Cette distinction permet de réutiliser les informations du centre tout en conservant les conditions et responsabilités propres à chaque étude.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmtt7v2bh1jvr4kkd8cz6gtpd.png"><div class="image-overlay"></div></div></div></div><p><em>Légende : Passer d’un statut global à une préparation lisible et actionnable.</em></p><h1>Enseignements clés</h1><h3>Étudier les changements dès la conception du modèle</h3><p>J’ai sous-estimé au départ les conséquences du paramétrage sur une étude déjà déployée. Modifier un domaine de données peut produire des effets en cascade ; traiter ce sujet tardivement a conduit à revoir des écrans validés.</p><p>Pour un prochain produit comparable, je cadrerais plus tôt la modification et les dépendances, au même titre que la création initiale.</p><h3>Formaliser le mandat produit au démarrage</h3><p>La latitude donnée par le CEO m’a permis de structurer le projet. Elle m’a aussi amené à porter des arbitrages de périmètre en parallèle du design, sans mandat produit explicite.</p><p>Je clarifierais désormais dès le kick-off qui prépare les priorités, qui les tranche et comment les évolutions de périmètre sont décidées.</p><h3>Garder une architecture extensible et un périmètre ciblé</h3><p>Le projet a progressivement intégré des sujets de monitoring, d’alertes et d’analyse avancée. J’ai dû recentrer le cœur du travail sur la chaîne <strong>protocole → construction → validation → déploiement</strong>, en distinguant les extensions stratégiques.</p><p>Prévoir l’évolution du produit demande aussi de décider ce qui peut attendre.</p><h3>Simplifier l’accès à la complexité métier</h3><p>Une distinction métier peut sembler superflue à l’écran et devenir essentielle dès qu’on examine ses conséquences. Ce projet m’a appris à interroger les simplifications proposées : quelle information disparaît, quel contrôle est perdu et qui en a besoin ?</p><p>Mon rôle a consisté à placer les informations et les contrôles au moment où ils permettent de décider, avec un niveau de détail adapté à la tâche.</p><h3>Limites &amp; hypothèses</h3><p>La conception s’appuie sur trois niveaux de connaissance :</p><ul><li><p><strong>La recherche documentaire et réglementaire</strong>, qui a nourri les modèles de données, de traçabilité et de cycle de vie.</p></li><li><p><strong>La recherche utilisateur existante et les échanges métier pendant la mission</strong>, qui ont alimenté les parcours et les revues de conception. Les Data Managers ont été particulièrement impliqués ; tous les rôles n’ont pas été étudiés au même niveau.</p></li><li><p><strong>Les hypothèses de conception</strong>, notamment l’autonomie des novices, la compréhension des impacts et les gains de temps attendus. Leur efficacité reste à établir par des tests d’usage et des mesures dédiées.</p></li></ul><p>Les revues métier, techniques et réglementaires ont permis de confronter les propositions aux contraintes du projet. Elles ne constituent pas, à elles seules, une mesure d’utilisabilité ou une attestation de conformité.</p>

Du cadrage aux spécifications, concevoir un outil qui permet de construire une étude, d’en vérifier la configuration et d’en maîtriser les évolutions.

UI Designer

Concevoir une plateforme d’études cliniques à la hauteur de la complexité métier

Groupe Laposte

<h3><strong>Mon étude de cas complet </strong><a href="https://cometandeaudemarsac.notion.site/Am-lioration-d-une-Marque-Blanche-dans-le-secteur-de-l-nergie-14579cc15e248069b913f8c183964e4c" rel="noopener noreferrer nofollow" target="_blank"><strong>ici</strong></a></h3><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cm56zg1qt2wqa68hj0rtv81dd.png"><div class="image-overlay"></div></div></div></div><h1><strong>Contexte</strong></h1><p>Économie d'Énergie, filiale du Groupe La Poste, accompagne les <strong>distributeurs d’énergie</strong> (gaz, électricité, carburant…) dans la gestion de leurs <strong>Certificats d'Économie d'Énergie</strong> (CEE).</p><p>Ce marché - fortement encadré - subit des <strong>évolutions réglementaires erratiques</strong>.</p><p>Historiquement, chaque client disposait de sa propre plateforme, créant des <strong>redondances de développement</strong> et des <strong>coûts de maintenance élevés</strong>.</p><p>Pour résoudre ce problème, l'entreprise a développé <strong>une solution en marque blanche</strong>.</p><p>Après les premières migrations de plateformes réussies, j'interviens pour <strong>superviser l'évolution de la marque blanche à travers la migration d'une plateforme plus complexe : Auchan Énergies</strong>.</p><p></p><h1>Quelques chiffres</h1><ul><li><p>165k+ de <strong>primes versées</strong> via la plateforme Auchan Énergies</p></li><li><p>1100 pages ou PDF de contenu sur la plateforme initiale (guides, FAQs, réglementaire)</p></li><li><p>6 mois pour concevoir un nouveau site de bout en bout</p></li><li><p>8 autres plateformes impactées pour chaque amélioration passée en marque blanche</p></li></ul><p></p><h1>Le constat</h1><p>La plateforme CEE d'Auchan Énergies permet aux particuliers de demander des primes pour leurs travaux de rénovation énergétique. Cependant, <strong>plusieurs problèmes majeurs</strong> ont émergé :</p><ul><li><p>La multiplication de correctifs court-terme ont créé <strong>une dette technique importante</strong></p></li><li><p><strong>L'expérience mobile est dégradée</strong> par une approche desktop-first</p></li><li><p>En raison d’un cadre réglementaire instable et d’une profusion de contenu écrit, la <strong>maintenance est devenue très coûteuse</strong></p></li></ul><p></p><h1>Le défi</h1><p>L'objectif était de migrer la plateforme vers la solution en marque blanche tout en assurant les points suivants :</p><ul><li><p><strong>Préserver les spécificités</strong> d'Auchan Énergies (contenu, programme CEE et identité visuelle qui leur sont propres)</p></li><li><p><strong>Identifier les leviers d’évolution communs aux autres plateformes</strong> afin de faire de certaines briques, un nouveau standard pour la marque blanche</p></li><li><p>Garantir une <strong>maintenance viable</strong> face aux évolutions réglementaires incessantes</p></li><li><p>Changer d’approche en adoptant une méthodologie <strong>mobile first</strong></p></li></ul><p></p><h1>Impact &amp; Résultats</h1><ul><li><p>74% de réduction des pages de contenu pour revenir à un volume d’information digeste et viable en maintenance (passage de 82 pages &amp; PDF à 22 pages)</p></li><li><p>26 fonctionnalités poussées en marque blanche (simulation multi travaux, amélioration des résultats de primes, RGDP, accessibilité…)</p></li><li><p>12 design sprints (1 par semaine) réalisés dans les temps impartis. Oui, on a bu beaucoup de café</p></li><li><p>0 fonctionnalité perdue malgré les écarts du projet avec la marque blanche initiale. La non régression était un aspect fondamental du projet</p></li></ul><p></p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cm56y71kz2vo068hjdte73p5q.png"><div class="image-overlay"></div></div></div></div><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cm56y7qy42vpb68hjhar3co0c.png"><div class="image-overlay"></div></div></div></div><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cm56zeuex2wpj68hjawdy6rno.png"><div class="image-overlay"></div></div></div></div><h3><strong>Mon étude de cas complet </strong><a href="https://cometandeaudemarsac.notion.site/Am-lioration-d-une-Marque-Blanche-dans-le-secteur-de-l-nergie-14579cc15e248069b913f8c183964e4c" rel="noopener noreferrer nofollow" target="_blank"><strong>ici</strong></a></h3>

Product Strategy

UX Product Design

UI Product Design

“Côme a joué un rôle important dans la préparation et  l'animation d'ateliers de co-création avec le client sur un planning en sprints agile. Dans la conception des  parcours utilisateurs avec le réglementaire, le métier et les développeurs ainsi que la production des maquettes et du Design System.
Côme a exécuté ses missions avec un engagement et une motivation reconnue.”

Amélioration d’une Marque Blanche dans le secteur de l'Énergie

Portfolio

Senior Product Designer Freelance

Accompagnement de clients dans le secteur de l’énergie (Auchan Énergie, EDF, ENGIE, Rexel)

Senior Product Designer

Amélioration du produit CATIA, une suite de logiciels de conception industrielle 3D leader du marché (Airbus, Boeing, Peugeot...)

Conseil pour de grand comptes du CAC40 (banque & assurance, énergie, construction) ou acteurs du secteur publique (Assurance Maladie)

-Veille & prototypage autour des technologies immersives (VR/AR/MR) : programmation en C# sous Unity, appropriation de SDK (SteamVR, VRTK, Leap Motion, DAQRI...), manipulation d'objet 3D, UX/UI 
-Identification de la valeur potentielle de l'AR/VR pour les métiers de Veolia
-Communication des résultats de mes recherches en interne et en externe (animation d'atelier lors de séminaires, exposant à VivaTech, présentation internes...)

Côme Tandeau de Marsac

Senior Product Designer Freelance

About me

Work experience

Senior Product Designer

Senior Product Designer

Product Designer

Product Designer / Developpeur C#

Education

CY Tech

Portfolio

Designing a clinical study platform that meets the complexity of the domain

ClinSearch

Concevoir une plateforme d’études cliniques à la hauteur de la complexité métier

ClinSearch

Amélioration d’une Marque Blanche dans le secteur de l'Énergie

Groupe Laposte

Talents

Recruiters

About