# Construire un produit de A à Z
SaaS · 2022 · Lead Product Designer
Lancer une solution d’automatisation pour générer des documents à signer

**Méthodes** : entretiens problème, entretiens solution, maquettes, prototypage, tests d’utilisabilité

Source : https://albancarmet.com/fr/case-study/youtrust-atoz

## Problème

Le problème que nous cherchons à résoudre
Le parcours d’un document à signer ne commence pas forcément une fois que le contenu a déjà été validé. Avant d’atteindre ce jalon, il y a tout un chemin à parcourir pour aligner de multiples parties prenantes sur le contenu d’un document.
Pourquoi est-ce un problème ?
La rédaction d’un document à signer présente 2 défis principaux :
* c’est chronophage, car il faut de nombreux allers-retours entre parties prenantes pour valider le contenu d’un document,
* la collecte de données (à intégrer dans le document à signer) est une source d’erreurs, surtout en cas de saisies multiples.
Pour qui concevons-nous ?
Des entreprises avec des cas d’usage métier « basiques » :
* Juridique (NDA, accords de partenariat, etc.),
* RH (contrats de travail, politiques RH).
Nous avons délibérément décidé de laisser de côté les cas d’usage commerciaux (sales)
Contraintes
1. Ressources :
* nous avions racheté Canyon, une entreprise qui proposait une solution d’automatisation pour générer des documents à signer. Cela impliquait de collaborer avec des collaborateurs fraîchement intégrés (les anciens cofondateurs de l’entreprise),
* nous fonctionnions avec des ressources limitées (l’un des cofondateurs faisait à la fois office d’Engineering Manager et de PM). Nous avons aussi collaboré ponctuellement avec quelques développeurs consultants,
* un design system rudimentaire. Nous venions alors de passer de Sketch à Figma. Il fallait recréer ou ajuster les composants existants.
2. Organisation
Toute l’équipe produit est passée à un modèle en squads, où les product designers travaillent désormais sur une partie spécifique du produit. Cela impliquait aussi de définir de nouveaux rituels de travail pour avancer.
3. Délais
De la discovery à la livraison, nous avons lancé un produit en 6 mois seulement. Cela nous a forcés à faire des choix et à définir ce que serait notre MMP (Minimum Marketable Product).
Pourquoi c’est le projet le plus difficile que j’ai mené
Quatre facteurs se sont additionnés. Le sujet lui-même était complexe : l’automatisation documentaire réunit dans un même parcours le templating, la collecte de données, la validation et la signature. Les limitations techniques ont pesé sur le design plus que je ne l’aurais voulu — plusieurs interactions ont dû être redessinées autour de ce que le produit existant savait réellement supporter. Le nombre de parties prenantes était inhabituel pour une seule fonctionnalité. Et l’équipe était réduite : les anciens cofondateurs de Canyon, l’entreprise belge que nous avions rachetée pour leur savoir-faire sur ce sujet précis.
C’est aussi ce rachat qui fait mal lire le projet de l’extérieur. Il ne s’est jamais agi de transposer le produit de Canyon dans le nôtre. Leurs interfaces et leurs dépendances étaient suffisamment différentes pour qu’il faille tout repenser, quasiment de zéro, à l’intérieur du produit Youtrust.
Quels impacts attendions-nous ?
* pour les utilisateurs : gagner du temps, moins d’erreurs, plus de conformité,
* pour Youtrust : un meilleur upsell, un meilleur win-rate, une meilleure rétention (stickiness).

## Contexte

• ✅ Produit lancé en 6 mois — de la discovery à la livraison, expédié en juin 2022 dans les temps malgré des contraintes de ressources et une réorganisation en squads
• ✅ 100 % de réussite aux tests d’utilisabilité — 22 hypothèses testées, toutes validées à la 2ᵉ itération avec seulement 4 ajustements de design entre les rounds
• ⚠️ Objectif commercial Q2 2022 manqué — jalon atteint 5 mois plus tard, faute de self-serve et de positionnement marketing
• 💡 Socle pour une initiative de suivi — les manques identifiés au lancement ont directement façonné l’étude de cas sur l’adoption
Youtrust est un SaaS B2B français qui propose une solution de signature électronique. Série A et principale alternative à DocuSign en Europe, Youtrust cherchait à s’étendre au-delà de la signature électronique. Jusque-là, l’entreprise se concentrait uniquement sur le cœur de métier de ce secteur, à savoir :
* côté expéditeur, ajouter des champs de signature sur le document et l’envoyer aux destinataires pour signature,
* côté destinataire, signer le document.
Dans le cadre de sa stratégie pour aller au-delà de la signature électronique, Youtrust a décidé de lancer une nouvelle fonctionnalité majeure baptisée Workflows : une solution d’automatisation qui génère des documents pré-remplis à signer à partir de modèles réutilisables — supprimant la collecte manuelle de données et les copier-coller qui ralentissaient les flux de documents récurrents.
Cette fonctionnalité vise à accélérer la préparation du contenu des documents récurrents à signer.
Comment ça marche ?
Le créateur du Workflow insère des variables (zones vierges) dans le document source. À partir de ces variables, un formulaire est automatiquement créé. Chaque variable est reliée à une question du formulaire. Pour fluidifier la collecte de données, il est possible de reformuler chaque variable en question. Enfin, la création du Workflow se termine par l’ajout des champs de signature (définir qui devra signer le document).
La magie opère au moment où le formulaire est soumis. Un document intégrant les données collectées est automatiquement généré et envoyé pour signature aux destinataires finaux. Grâce aux variables, les données sont correctement insérées dans le document.
Pourquoi avoir choisi cette voie ?
* apporter plus de valeur aux clients avant l’acte de signature,
* différencier notre produit de la concurrence,
* accélérer la croissance du MRR avec une nouvelle ligne de produit.

## Démarche

Pour donner à Youtrust toutes les chances de réussir ce projet majeur, nous avons mené une phase de discovery impliquant plusieurs équipes : produit, design, engineering, finance et marketing. Je me concentrerai ici uniquement sur l’initiative qui m’a aidé à façonner le product design.
Entretiens problème / solution
Quand j’ai rejoint le projet, la plupart des entretiens avaient déjà été menés. J’en ai suivi quelques-uns comme preneur de notes. Cela m’a permis d’entrer dans le sujet de l’automatisation.
Détails des entretiens :
* Durée : 25 minutes,
* Type d’entretien : à distance, modéré via Google Meet,
* Objectifs :
* définir les segments clients,
* comprendre les points de friction des utilisateurs,
* hiérarchiser les plus critiques,
* lister les outils utilisés par les clients (solutions concurrentes),
* recueillir des retours sur la solution Canyon existante (une solution d’automatisation pour générer des documents à signer),
* évaluer la disposition à payer,
* Cibles : clients Youtrust produisant un volume élevé de demandes de signature (en excluant pour diverses raisons ces personas : sales, immobilier, agences digitales, petits comptes, non-clients Youtrust)
[lire le script](https://docs.google.com/document/d/1Fx03TqyN2VH4uwyFFniyvsN6Qgjbd1D79hkcMtYAsuY/edit?usp=sharing)
Enseignements des entretiens :
Résultats obtenus après 9 entretiens (sur les 10 prévus initialement).
* la collecte de données ressort comme problème numéro un pour 5 personnes interrogées,
* les autres problèmes, cités une fois chacun : le remplissage de documents, l’approbation/relecture de documents, le manque de connectivité entre les outils existants,
* le souci avec la collecte et le classement de documents, c’est que ça prend du temps et que c’est abrutissant à grande échelle,
* les personas juridique et RH rencontrent le même ensemble de problèmes, sauf l’archivage et la conformité documentaire (propres au juridique) et les saisies multiples (propres aux RH),
* la création automatisée de documents n’est pertinente que lorsqu’il y a un volume élevé de documents standards émis par l’entreprise (contrats et promesses d’embauche, NDA, DPA, contrats de freelance, bons de commande, courriers). Les workflows de collecte de données et d’approbation/édition sont pertinents pour les documents sortants comme pour les documents entrants provenant de tiers (contrats fournisseurs, NDA reçus de tiers, etc.),
* un autre problème propre au cas d’usage juridique est apparu : les opérationnels utilisent des versions de documents obsolètes ou les mauvais modèles (conformité documentaire),
* il a été confirmé que les profils juridique et RH ne sont pas à l’aise avec la tech. Toutes les personnes interrogées se disaient « peu à l’aise » ou « pas du tout à l’aise » avec la technologie,
* la disposition à payer se demande mieux sous forme de multiple de ce que le client paie actuellement pour la signature électronique (et non comme un montant fixe par mois). Certaines personnes interrogées ne savent pas combien elles paient pour Youtrust,
Le nombre de contrats signés est un très bon indicateur de la pertinence de la solution de workflows documentaires.
* toutes les personnes interrogées comprennent la valeur de la solution de workflows documentaires et ce qu’elle vise. Elles jugent chaque étape du workflow essentielle (remplissage du formulaire, création automatisée du document, relecture, édition du document/des champs, approbation/rejet, signature automatisée, bibliothèque de contrats). Aucune étape n’est perçue comme un « plus » ou un simple « gadget ». Aucune personne interrogée n’a eu d’effet « waw » sur une fonctionnalité en particulier. Le workflow est jugé logique et fonctionnel,
* 3 personnes interrogées insistent sur le fait que la solution de workflows documentaires doit proposer d’autres fonctionnalités. 1 personne veut pouvoir injecter les données des salariés dans le SIRH (cas d’usage RH). 2 personnes veulent la publication en masse de contrats (cas d’usage RH et juridique),
* toutes les personnes interrogées utilisent Word (version desktop) comme éditeur de texte. 7 sont sur la suite Microsoft Office. 2 sont sur Google Workspace,
* les grandes entreprises et les PME traditionnelles ont plus tendance à utiliser Microsoft Office (que ce soit la version 365 en ligne ou sur leurs propres serveurs locaux), tandis que les startups et les PME modernes ont plus tendance à utiliser Google Workspace,
* construire son propre éditeur de texte semble une bonne idée. On a plus de contrôle sur la création de modèles, le versioning des documents et la collaboration inline. Pourtant, c’est en réalité une mauvaise idée : il est quasi impossible de ne pas casser les documents (mises en page, polices, modifications inline, commentaires) quand ils sont exportés dans un sens ou dans l’autre (.docx ou PDF), la mise en place prend un temps fou, l’adoption interne est difficile (ce n’est pas intuitif) et les tiers ne l’utiliseront pas pour négocier (voir les mauvais avis sur les outils ayant développé leur propre éditeur de texte comme Pandadoc, GetAccept, Ironclad).
Alternatives / concurrence
* 6 personnes interrogées n’ont aucun produit dédié en alternative : elles suivent toutes un process manuel pour leurs workflows documentaires :
* e-mail/téléphone pour collecter les données,
* éditeur Word pour saisir les données dans le modèle de document (copier-coller),
* récupération manuelle du document signé dans le système de gestion documentaire.
* Exemples de panoplies d’outils utilisées par nos personnes interrogées :
* personne interrogée n°1 : un mix de Typeform / Google Sheets / Google Doc / formulaire Payfit,
* personne interrogée n°2 : Notion (ticketing) / Leeway (bibliothèque de contrats),
* personne interrogée n°3 : une solution française de bibliothèque de contrats (uniquement pour les contrats fournisseurs et seulement comme bibliothèque de contrats).
* certains SIRH proposent la génération de documents et des workflows de signature. À noter : les fonctionnalités se limitent à la génération et à la signature in-app (pas de workflow d’approbation, pas de formulaire de collecte de données externe).
Profil client :
Profil client idéal pour la solution de workflows documentaires :
* RH : entreprise de 500 salariés signant 10+ contrats de travail par mois,
* Juridique : juriste signant 50+ contrats standards par mois.
Disposition à payer :
* toutes les personnes interrogées, sauf une, ont accepté de tester la solution de workflows documentaires. Une personne a même insisté pour un rappel rapide afin de créer une preuve de concept sur un cas d’usage particulier,
* 7 personnes interrogées sont prêtes à payer pour la solution :
* au plus haut : environ 2X ce qu’elles paient actuellement pour Youtrust,
* au plus bas : entre 1,2X et 1,5X ce qu’elles paient actuellement pour Youtrust,
* 2 personnes interrogées ne sont pas prêtes à payer pour la solution,
* nous n’avons pas testé la solution auprès de non-clients Youtrust. Pour autant, les clients Canyon actuels étaient la preuve vivante que des entreprises sont prêtes à acheter Youtrust et/ou à quitter leur fournisseur de signature électronique existant pour Youtrust, à 3X et 20X le prix qu’elles paient actuellement.

## Solution

Nourri par ces enseignements, j’ai ensuite travaillé étroitement avec les anciens fondateurs de Canyon pour concevoir une première itération du produit. Les spécifications initiales reposaient sur :
* les enseignements des entretiens problème,
* la connaissance des cofondateurs de Canyon (recherche menée avant le rachat par Youtrust),
* la date de mise sur le marché (approche MMP).
Pour concrétiser cette première itération, nous avons décidé de nous concentrer sur le profil client juridique (l’un des 2 profils identifiés lors de notre phase de recherche). À partir de là, nous avons imaginé 2 scénarios : l’un centré sur la création d’un Workflow, l’autre sur son exécution.
Vous travaillez chez Youtrust comme juriste et devez fréquemment préparer des accords de confidentialité (NDA). D’un NDA à l’autre, les seuls éléments qui changent sont les informations sur l’entreprise (nom, adresse, nom du représentant…). En plus de ces informations, chaque NDA doit comporter la signature du CEO et celle du contre-signataire. Enfin, pour vous assurer que les NDA générés ne comportent aucune erreur de données, vous voulez relire chaque document avant de l’envoyer à ses destinataires. Votre objectif est de créer un Workflow incluant les éléments mentionnés ci-dessus.
Vous travaillez chez Youtrust comme sales development representative. Avant de démarrer une relation d’affaires avec d’autres entreprises, vous devez d’abord leur faire signer un NDA. Vous êtes sur le point de travailler avec une autre entreprise. Avant d’officialiser, vous avez besoin que votre futur partenaire signe un NDA. Votre objectif est de collecter les informations de l’entreprise à l’aide du Workflow créé par le juriste de Youtrust.
Voici la première version du design sur laquelle nous nous sommes alignés :
Défis rencontrés
Construire cette première itération de design a soulevé plusieurs défis. Les principaux se concentraient sur le flux de création du Workflow :
1. Trouver le bon ordre des étapes :
Qui vient en premier ? L’œuf ou la poule ? C’est à peu près la question que je me suis posée en commençant à réfléchir au flux de création du Workflow. Dans mon cas, il s’agissait de définir ce que l’utilisateur devait voir après avoir importé le document source : personnaliser le formulaire lié au document, ou ajouter les champs de signature sur le document ?
Quand j’ai commencé à travailler sur le flux de création, je n’avais pas d’avis tranché sur l’ordre des étapes. C’est après avoir mené des explorations de design que j’ai réalisé que commencer par la personnalisation du formulaire pouvait rendre le flux de création moins intuitif. Pour comprendre pourquoi, voici quelques éléments de contexte :
* chez Youtrust, les documents à signer sont envoyés par e-mail aux destinataires grâce à un champ de signature. Un champ de signature inclut les coordonnées du signataire :
* prénom,
* nom,
* e-mail,
* téléphone mobile.
* avec Workflows, nous introduisions le champ signataire « placeholder ». Il permet au créateur du Workflow d’ajouter un signataire sans encore connaître son identité. Pour envoyer le document à ce type de destinataire, l’e-mail du signataire ainsi que ses autres coordonnées sont collectés pendant que le répondant remplit le formulaire.
Avec ces éléments en tête, voici à quoi ressemblerait le user flow selon que l’on démarre par la personnalisation du formulaire ou par la préparation du document :
Option 1 : Démarrer par la personnalisation du formulaire
Avec ces éléments en tête, voici à quoi ressemblerait le user flow selon que l’on démarre par la personnalisation du formulaire ou par la préparation du document :
Option 2 : Démarrer par la préparation du document
Pour moi, offrir un aperçu clair du formulaire pendant le flux de création était essentiel pour construire une expérience intuitive. Choisir l’option 1 plutôt que l’option 2 créerait un aller-retour superflu autour de la personnalisation du formulaire. Après l’import du document, l’utilisateur commence la personnalisation du formulaire, passe par la préparation du document, puis revient encore une fois à la personnalisation du formulaire. Cela parce qu’il est impossible d’obtenir un aperçu fidèle à l’étape « Personnalisation du formulaire – partie 1 ». À ce stade, on ne sait pas encore si le Workflow inclura ou non un signataire placeholder. Pour rappel, si un signataire placeholder est ajouté au document, ses informations (prénom, nom, e-mail et téléphone mobile) seront collectées via le formulaire. Pour moi, cela générerait de la confusion, l’utilisateur voyant une nouvelle fois une étape dédiée au formulaire.
Pour cette raison, j’ai décidé de partir sur l’option 2. Voici à quoi ressemblait le design :
2. Définir jusqu’où aller dans la préparation du document :
Contrairement à notre expérience cœur où l’utilisateur importe un document dont le contenu est finalisé (approuvé), un Workflow vise à construire des documents réutilisables. Cela implique de créer, au sein du contenu du document, des variables (zones vierges) où les données seront injectées.
Pour y parvenir, 2 pistes principales se sont dégagées :
* intégrer un éditeur de texte dans notre app,
* externaliser l’édition de texte (via des outils comme Microsoft Word ou Google Docs).
Pour des raisons de temps et de ressources, nous avons vite choisi d’externaliser l’édition de texte. Cela a eu un impact important sur le flux de création :
* expliquer à l’utilisateur que l’ajout de variables au document doit se faire en dehors de l’app Youtrust. Pour créer une variable, l’utilisateur doit mettre un mot / une expression entre crochets : [nom de la variable],
* en réutilisant autant que possible les patterns de design existants, j’ai démarré le travail de design de cette page pédagogique / d’import de document.
Inspiré par la page d’import de notre flux actuel de création de demande de signature, j’ai abouti à ce design :
Affiner avant de tester
À ce stade du parcours de design, notre objectif était de commencer à affiner l’ensemble de fonctionnalités de la Workflow v1 avant de lancer les tests utilisateurs.
Pour cela, nous avons partagé les flux à des parties prenantes internes clés afin de recueillir des retours. Nous avons aussi recontacté des clients interrogés pendant notre phase de recherche et mené des entretiens solution. Tout en les guidant à travers les flux, notre objectif était d’obtenir leurs retours et d’évaluer l’ensemble de fonctionnalités initial que nous avions en tête.
Pour faire court, je ne détaillerai pas toutes les modifications faites avant de lancer les tests utilisateurs. Voici toutefois 2 éléments clés que nous avons changés :
1. L’ordre des étapes de création du Workflow :
Même si l’option 1 ne créait pas cette sensation d’aller-retour autour de la personnalisation du formulaire, nous avons décidé de partir sur l’option 2. Les raisons :
* l’option 1 a été perçue comme moins intuitive que l’option 2. Pour les parties prenantes clés, l’étape « attendue » après l’import du document était la personnalisation du formulaire,
* découper la personnalisation du formulaire en 2 étapes permet d’alléger la densité d’information par page. Cela réduit donc la charge mentale pour l’utilisateur.
2. La page d’import du document :
La page d’import a été enrichie de :
* une vidéo expliquant comment ajouter des variables dans un document,
* une illustration plus grande faisant apparaître un faux texte incluant des variables.
Avec ces nouveaux éléments, l’objectif était de rendre la préparation du document limpide pour les utilisateurs.
Tests utilisateurs
À partir de la version 1.0, j’ai ensuite préparé les tests utilisateurs : rédaction du script, prise de contact avec les utilisateurs, création des prototypes.
Détails des tests utilisateurs :
* Durée : 60 minutes
* Méthode : à distance, modéré via Google Meet
* Objectif : identifier les points de friction des utilisateurs (voir les hypothèses que nous voulions vérifier pendant les tests)
* Panel de testeurs : 11 utilisateurs – 7 clients existants + 4 prospects (avec 1 no-show)
* Cibles :
* utilisateurs français,
* clients actuels de l’app Youtrust avec min. 100 ETP (hors plans API et One),
* prospects avec min. 100 ETP,
* clients actuels de l’app Youtrust inscrits sur la liste d’attente du produit Workflows,
* Scénarios testés :
* Scénario 1 – créer un NDA à partir d’un workflow existant – côté exécution,
* Scénario 2 – relire un NDA et l’envoyer pour signature – côté exécution,
* Scénario 3 – publier une version de document mise à jour et l’envoyer pour signature – côté exécution,
* Scénario 4 – créer un workflow – côté création.
[lire le script](https://docs.google.com/document/d/1dUG2CELzf8tHgR0jblN2p3Sh4VWS2YXn27DBM6HY9dI/edit?tab=t.0#heading=h.an7ptilmlcam)
Pour le contexte, nous avions initialement prévu de ne mener qu’un seul round de tests. Finalement, après 6 tests utilisateurs, nous avons observé des points de friction récurrents et décidé d’implémenter des améliorations de design pour les corriger. Grâce à ces premiers retours, nous avons réalisé une deuxième itération de design de nos flux et repris nos tests.
### Round 1
Enseignements des tests utilisateurs - round 1
6 utilisateurs testés — 2 constats positifs, 2 éléments à améliorer. Des points de friction récurrents nous ont conduits à faire une pause et à implémenter des changements de design avant de reprendre.
[Voir le prototype](https://www.figma.com/proto/azsK0o9cflVTjjAxzKTQrY/Workflows---Prototypes?page-id=0%3A1&type=design&node-id=301-9915&viewport=2991%2C158%2C0.11&t=rAoSaFEWFzKfLmsj-1&scaling=scale-down&starting-point-node-id=301%3A9915&show-proto-sidebar=1&mode=design){/images/case-studies/cs_youtrust_atoz_step_v0_01.webp}
Tous les utilisateurs comprennent qu’ils doivent utiliser des marqueurs imposés pour baliser des mots/expressions en local, dans l’éditeur Word. Certains, toutefois, n’ont pas saisi la nuance entre accolades et crochets.
👉 3 utilisateurs sur 6 ont compris qu’il faut utiliser des crochets [ ] et non des accolades { } pour baliser les mots/expressions.
Recommandation(s) :
Conserver le design tel quel
Tous les utilisateurs comprennent pourquoi les réponses du formulaire s’affichent dans l’e-mail de notification. Pour certains, c’était un effet « waw ».
👉 4 utilisateurs sur 6 ont trouvé vraiment utile de recevoir les réponses du formulaire dans l’e-mail de notification.
Recommandation(s) :
Conserver le design tel quel
La plupart des utilisateurs n’ont pas compris les options de visibilité du formulaire. Les Workflows ont deux options de visibilité. Le formulaire est soit public (toute personne disposant du lien peut y accéder), soit « privé », c’est-à-dire accessible uniquement aux titulaires d’un compte Youtrust. Les utilisateurs devaient rendre le formulaire/workflow accessible à tous les employés d’Acme. Comme, a priori, seuls quelques employés ont un compte Youtrust, les utilisateurs devaient mettre le formulaire en public. Or la plupart ont eu du mal à le comprendre.
👉 4 utilisateurs sur 6 n’ont pas compris les options de visibilité du formulaire.
Recommandation(s) :
* améliorer la formulation de la question,
* expliciter la formulation des 2 options,
* préciser dans les consignes que seuls 3 employés d’Acme ont un compte Youtrust (sur un total de 50 employés).
Quand un workflow comporte plusieurs versions de document, les utilisateurs peinent à comprendre quelle version va être préparée pour signature.
👉 3 utilisateurs sur 6 n’ont pas compris que la zone surlignée en vert désigne la version du document à préparer pour signature. C’est critique, car cela pourrait conduire à envoyer la mauvaise version pour signature.
Recommandation(s) :
* supprimer le traitement « tag » du nom de document,
* dans la zone de version du document, ajouter un tag indiquant que cette version est celle à préparer pour signature,
* ajouter une couleur d’accent sur le fond du titre du document pour le rendre plus visible (partie gauche de l’écran).
### Round 2
Enseignements des tests utilisateurs - round 2
5 utilisateurs testés sur le design mis à jour — 3 constats positifs, 1 élément à améliorer. Tous les problèmes critiques du round 1 ont été résolus.
[Voir le prototype](https://www.figma.com/proto/azsK0o9cflVTjjAxzKTQrY/Workflows---Prototypes?page-id=301%3A1051&node-id=301-1323&starting-point-node-id=301%3A1323&t=Fbm9t1pXki9bZ0vK-1){/images/case-studies/cs_youtrust_atoz_step_v1_01.webp}
L’usage des crochets pour baliser les mots/expressions est clair. Aussi surprenant que cela paraisse, cette deuxième vague de tests a produit de très bons résultats alors même que nous n’avions fait aucune modification de design sur ce point.
👉 4 utilisateurs sur 5 ont compris qu’il faut utiliser des crochets pour baliser les mots/expressions afin de préparer leur document.
Recommandation :
Conserver le design tel quel
Tous les utilisateurs comprennent les options de visibilité du formulaire (c’est-à-dire qui peut utiliser un workflow). Au premier round, la plupart peinaient à comprendre qu’ils devaient régler le formulaire sur « accessible à tous » pour le rendre accessible à tous les employés d’Acme, même ceux sans compte Youtrust. Avec ce nouveau design, nous avons amélioré la formulation (par ex. les mentions « privé » et « public ») et les icônes. Ça a clairement payé.
👉 5 utilisateurs sur 5 ont compris les options de visibilité du formulaire.
Recommandation :
Conserver le design tel quel
Quand un workflow comporte plusieurs versions de document, la plupart des utilisateurs comprennent désormais quelle version va être préparée pour signature. Au premier round, la plupart étaient perdus quant à la version qui serait finalement envoyée pour signature. Cette deuxième itération de design, avec une architecture de l’information et une hiérarchie visuelle améliorées, a payé.
👉 4 utilisateurs sur 5 ont désormais clairement compris quelle version du document va être préparée pour signature lorsqu’il y a plusieurs versions importées.
Recommandation :
Conserver le design tel quel
Le flux de création crée un aller-retour entre l’étape de mapping des champs et l’étape de personnalisation des questions du formulaire.
👉 2 utilisateurs sur 5 ne semblaient pas s’attendre à revenir sur une étape de personnalisation des questions après avoir déjà mappé les champs du formulaire au début du flux. Certains s’attendaient à arriver sur la page de réglages. Un testeur a même cru qu’il s’agissait d’un formulaire « en direct » qui surgissait et voulait le remplir pour l’essayer. Les testeurs n’ont toutefois pas été surpris par les questions de la box signataire — ils ont compris d’où elles venaient et comment les utiliser.
Recommandations :
* Aucune initiative immédiate à lancer — ce n’est pas bloquant et cela ne représente pas un groupe d’utilisateurs significatif.
* Il vaudrait toutefois la peine d’explorer, après la v1, une solution de design combinant ces 2 étapes en un seul écran.
Synthèse des tests utilisateurs
• ✅ Objectif principal atteint — le design du parcours utilisateur fonctionne, tout simplement
• ✅ 100 % de réussite après le round 2 — les 22 hypothèses validées. 4 hypothèses à risque moyen avaient échoué au round 1 (81 %) et ont été corrigées avec succès.
• ✅ Les utilisateurs ont compris le produit — ils ont saisi la proposition de valeur et gardé un fort intérêt et une belle énergie tout au long des tests
• ✅ 11 entretiens menés sur un objectif de 10 — les testeurs étaient ravis de participer et ont apprécié l’expérience
• 💡 Niveau de confiance élevé sur l’utilisabilité — nous sommes rassurés : le produit livré sera compris et utilisé
• 💡 17 insights utilisateurs captés pour de futures améliorations produit
• 💡 Seulement 4 ajustements de design nécessaires après le round 2 — un ensemble de changements très limité avant le lancement
Design final
Sur la base des recommandations issues du round 2 de tests, voici la version finale du produit que nous avons livrée en juin 2022 :

## Résultats

• ✅ Produit lancé en 6 mois — de la discovery à la livraison, Workflows a été expédié en juin 2022 — dans les temps malgré des contraintes de ressources et une réorganisation en squads.
• ✅ 22 hypothèses testées, 100 % validées au round 2 — seulement 4 ajustements de design nécessaires entre les rounds 1 et 2.
• ✅ Les utilisateurs ont compris et apprécié le produit — fort engagement tout au long des tests, 17 insights utilisateurs captés pour de futures améliorations.
• ⚠️ Objectif commercial Q2 2022 manqué — le jalon a été atteint 5 mois plus tard, en novembre 2022, faute de self-serve, de fonctionnalités clés et de positionnement marketing.
• 💡 Socle pour l’initiative d’adoption — les manques identifiés au lancement ont directement façonné l’effort de recherche de suivi détaillé dans l’étude de cas associée.
J’ai apporté quelques ajustements supplémentaires après le deuxième round de tests, mais rien de bloquant pour le lancement de Workflows.
Côté business, nous n’avons pas atteint notre objectif de X clients Workflows à la fin du Q2 2022 (là encore, je ne peux pas divulguer le chiffre). Pour mémoire, nous avons atteint ce jalon fin novembre 2022.
En équipe, nous avons cherché à comprendre les raisons de ce résultat. Plusieurs sont ressorties :
* le produit n’était pas encore vendu en self-serve (l’équipe Sales devait faire des démos produit pour vendre Workflows),
* certaines fonctionnalités must-have n’avaient pas encore été implémentées,
* le nouveau positionnement, le pricing et la présentation de Workflows n’avaient pas encore été mis en place.
Mes enseignements
Même si j’ai vraiment aimé prendre part à cette aventure passionnante, je reste frustré par les résultats business initiaux. En plus des raisons que je viens de partager, j’ai le sentiment que nous avons touché la limite de l’approche MMP. L’ensemble de fonctionnalités initial était sans doute trop limité au lancement, rendant Workflows peu pertinent pour certains profils clients. De même, ne proposer aucun onboarding en self-serve était probablement une erreur, car le produit repose sur des concepts qui peuvent être compliqués à saisir.
Un an plus tard, d’autres raisons clés se sont imposées. Les 2 principales : la proposition de valeur n’était pas clairement comprise, et la préparation du document — c’est-à-dire l’ajout de variables — semblait être un point bloquant : les utilisateurs ne semblaient pas comprendre comment ajouter des variables dans leurs documents. Même si cela n’a jamais été bloquant pendant nos tests utilisateurs initiaux, plusieurs utilisateurs ont clairement dit qu’ils s’attendaient à pouvoir éditer le document directement dans Youtrust.
Depuis, nous avons mené plusieurs initiatives majeures pour rendre le produit plus riche et plus intuitif. Je les détaille dans cette autre [étude de cas](#cs:youtrust-adoption).
Avec le recul, ce projet m’a appris deux choses que j’emporte à chaque lancement depuis. D’abord, un MMP trop minimal peut miner la traction commerciale autant qu’un produit livré en retard — les décisions de scope ont un coût business qui n’est pas toujours visible avant le lancement. Ensuite, réussir des tests utilisateurs sur un prototype ne garantit pas l’adoption dans le monde réel : l’étape de préparation du document a passé chaque round de tests, mais est devenue le frein n°1 à l’adoption une fois sur le terrain. Réduire l’écart entre les conditions de labo et l’usage réel est un problème sur lequel je travaille délibérément depuis.

## Impact

Lancement d’une solution d’automatisation pour générer des documents à signer