# Building a product from A to Z
SaaS · 2022 · Lead Product Designer
Launching an automation solution to generate documents to sign

**Methods** : problem interviews, solution interviews, mockups, prototyping, usability tests

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

## Problem

Problem we are trying to solve
The document to be signed journey does not necessarily start when the content has already been approved. Prior to reaching this milestone, there is a long way to align multiple stakeholders on a document content.
Why is it a problem?
Drafting a document to be signed comes with 2 main challenges:
* it is time consuming as it takes a lot of back and forth between stakeholders to approve a document content,
* data collection (to be integrated in the document to sign) is a source of errors, especially if there are multiple data entries.
Who are we designing for?
Companies with « basic » business use cases:
* Legal NDAs, partnership agreements, etc.),
* HR (employment agreement, HR policies).
We deliberately decided to leave aside the sales use cases
Constraints
1. Resources:
* we acquired Canyon, a company which offered an automation solution to generate documents to sign. This meant collaborating with newly integrated employees (former co-founders of the company),
* we were operating with limited resources (one of the co-founders was acting as Engineering manager and PM). We also temporary collaborated with few consultant developers,
* a rudimentary design system. At that time me recently switched from Sketch to Figma. We had to recreate or adjust existing components.
2. Organisation
The whole product team switched to a squads model where product designers now work on specific part of the product. This also meant defining new work rituals to get the job done.
3. Timeline
From the discovery to the delivery we launched a product in 6 months only. This forced us to make choices and define what would be our MMP (Minimum Marketable Product).
Why this is the hardest project I have led
Four things compounded here. The subject itself was intricate — document automation pulls templating, data collection, validation and signature into a single flow. Technical limitations weighed on the design more than I would have liked: several interactions had to be redrawn around what the existing product could actually support. The number of stakeholders was unusually high for one feature. And the team was small — the former co-founders of Canyon, the Belgian company we had acquired for their expertise on exactly this problem.
That acquisition is also what makes the project easy to misread from the outside. It was never a matter of transposing Canyon's product into ours. Their interfaces and their dependencies differed enough that we had to rethink the whole thing almost from scratch, inside the Youtrust product.
What were the expected impacts?
* on users: save time, less errors, more compliance,
* on Youtrust: better upsell, win-rate, retention (stickiness).

## Context

• ✅ Product launched in 6 months — from discovery to delivery, shipped June 2022 on time despite resource constraints and a squad reorganisation
• ✅ 100% usability test success — 22 hypotheses tested, all passed in round 2 with only 4 design edits needed between rounds
• ⚠️ Q2 2022 commercial target missed — milestone reached 5 months later due to missing self-serve and marketing positioning
• 💡 Foundation for a follow-up initiative — gaps identified at launch directly shaped the companion adoption case study
Youtrust is a French B2B SaaS offering an e-signature solution. As a Series A company and the leading DocuSign alternative in Europe, Youtrust was focused on expanding beyond core e-signature. So far the company was only concentrating on the core business of this industry meaning:
* on the signer requester end, adding signature fields on the document and send it to recipients for signature,
* on the recipient end, signing the document.
As part of the company strategy to go beyond e-signature, Youtrust decided to launch a new major feature named Workflows: an automation solution that generates pre-filled documents for signature from reusable templates — removing the manual data collection and copy-paste work that slowed down recurring document flows.
This feature aims to speed up the content preparation of recurring documents to sign.
How it works?
The Workflow creator inserts variables (blank area) in the source document. From these variables a form is automatically created. Each variable is linked to a form question. To make data collection smoother, it is possible to rephrase each variable into questions. Finally, the Workflow creation ends by adding signature fields (define who will have to sign the document).
The magic happens when the form is submitted. A document including collected form data is automatically generated and sent for signature to final recipients. Thanks to variables, data are properly inserted within the document.
Why did we decide to go that way?
* provide more value to customers before the signature act,
* differentiate our product from competitors,
* accelerate MRR growth with a new product line.

## Process

To give Youtrust all chances to succeed in this major project, we ran a discovery phase involving multiple teams from product, design, engineering, finance to marketing. I'll be only focusing here on the initiative which helped me shape the product design.
Problem / solution interviews
When I joined the project, most interviews had already been run. I attended some as a note taker. It helped me to get into the automation topic.
Interview details:
* Duration: 25 minutes,
* Interview type: Remote moderated via Google Meet,
* Objectives:
* define customer segments,
* understand user pain points,
* rank most critical ones,
* list out customer toolsets (competitive solutions),
* get feedback on the existing Canyon solution (an automation solution to generate documents to sign),
* evaluate the willingness to pay,
* Targets: Youtrust customers producing a high volume of signature requests (excluding for various reasons these personas: sales, real estate, digital agencies, small accounts, non Youtrust customers)
[read the script](https://docs.google.com/document/d/1Fx03TqyN2VH4uwyFFniyvsN6Qgjbd1D79hkcMtYAsuY/edit?usp=sharing)
Interviews learnings:
Results based after conducting 9 interviews (ou of 10 initially scheduled).
* data collection came as number one problem for 5 interviewees,
* other problems mentioned once each were: document filling, document approval/review, lack of connectivity between existing tools,
* the problem with doc collection & doc filing is that they take time and are mind-numbing at scale,
* legal and HR personas encounter the same set of problems, except for doc archiving & doc compliance (specific to legal) and multiple data entry (specific to HR),
* automated doc creation is only relevant when there's a high volume of standard documents coming from the company (employment contracts & offers, NDAs, DPAs, freelance agreements, work orders, letters). Data collection and approval/edition workflows are relevant for outbound and for inbound documents coming from third parties (supplier contracts, NDAs received from third parties, etc.),
* another problem specific to the legal use case appeared: business people use outdated document versions or use the wrong doc templates (doc compliance),
* it has been confirmed that legal and HR people are not tech savvy. All interviewees stated they were « not at ease » or « not at all at ease » with technology,
* willingness to pay is best asked as a multiple of what a customer currently pays for eSignature (and not as a fixed amount per month). Some interviewees don't know how much they are paying for Youtrust,
The number of signed contracts is a very good indicator of the relevance for the doc workflows solution.
* all interviewees understand the value of the doc workflows solution and what it aimed at achieving. They deem every step of the workflow as a essential (form filling, automated doc creation, doc review, doc/fields edition, doc approval/rejection, automated signature, contracts library). No step is deemed as a nice-to-have or a mere « gadget ». No interviewee had a « waw » effect on a particular feature. The workflow is considered logical and functional,
* 3 interviewees insist that the document workflows solution must have other features. 1 interviewee wants the ability to inject employee data into HRMS (HR use case). 2 interviewees want the mass publication of contracts (HR and legal use cases),
* All interviewees use Word (desktop version) as text editor. 7 interviewees are on the Microsoft Office suite of tools. 2 interviewees are on Google Workspace,
* Enterprise companies and traditional SMBs are more likely to use Microsoft Office (whether the online 365 version or on their own local servers) while startups and modern SMBs are more likely to use Google Workspace,
* Building your own text editor sounds like a good idea. You have more control over template building, doc versioning and inline collaboration. Yet it's actually a bad idea because it's virtually impossible not to break documents (layouts, fonts, inline changes, comments) when they're exported in and out (whether .docx or PDF), it takes ages to setup, is difficult to adopt internally (i.e. it's not intuitive) and third parties won't use it to negotiate (see bad reviews for tools that have built their own text editor like Pandadoc, GetAccept, Ironclad).
Alternatives / competition
* 6 interviewees have no alternative dedicated product: they all follow a manual process for doc workflows:
* email/phone to collect data,
* Word editor to input data into doc template (copy-pasting),
* manual retrieving of signed document into document management system.
* Examples of tool set used by our interviewees:
* interviewee #1: a mix of Typeform / Google sheets / Google Doc / Payfit form,
* interviewee #2: Notion (ticketing) / Leeway (contract library),
* interviewee #3: French contracts library solution (only for vendor contracts and only as a contracts library).
* certain HRMS offer document generation & signature workflows. Note: features are limited to in-app doc generation & signature (no approval workflow, no external data collection form).
Customer profile:
Ideal customer profile for doc workflows solution for:
* HR: company of 500 employees signing 10+ employment contracts each month,
* legal: legal counsel signing 50+ standard contracts each month.
Willingness to pay:
* all interviewees, except one agreed to test the doc workflows solution. An interviewee even pressured for a quick follow-up call to create a proof of concept for a particular use case,
* 7 interviewees are ready to pay for the solution:
* highest: around 2X what they currently pay for Youtrust,
* lowest: between 1.2X and 1.5x of what they currently pay for Youtrust,
* 2 interviewees are not ready to pay for the solution,
* we did not test out the solution to non Youtrust customers. Yet current Canyon customers were living proof that companies are willing to buy Youtrust and/or shift from their existing eSignature provider to Youtrust at 3X and 20X the price they are currently paying.

## Solution

Nourished by these learnings, I then closely worked with the former Canyon founders to design a first iteration of the product. Initial specifications were based on:
* the problem interviews learnings,
* the knowledge of Canyon co-founders (research made before getting acquired by Youtrust),
* the market launch date (MMP approach).
To materialise this first iteration we decided to focus on the legal customer profile (one of the 2 profiles identified from our research phase). From there we imagined 2 scenarios, one focused on creating a Workflow, the other on executing the Workflow.
You are working for Youtrust as a legal counsel who frequently has to prepare Non Disclosure Agreements documents (NDA). From one NDA to another, the only changing elements are company information details (company name, company address, company representative name…). In addition to these information, each NDA must include the CEO signature and the counter signer signature. Finally, to make sure generated NDAs don't include any data glitches, you want to review every document before sending them to their recipients. Your goal is to create a Workflow including the previously mentioned details.
You are working for Youtrust as sales development representative. Before starting business relationships with other companies, you first need to make them sign a NDA. You are about to do business with another company. Before making it official, you need your future business partner to sign a NDA. You goal is to collect company details using the Workflow created by the Youtrust legal counsel.
Here were the first design version we aligned on:
Challenges encountered
Building this first design iteration came up with various challenges. The main ones where concentred on the Workflow creation flow:
1. Find the right steps order:
What came first? The chicken or the egg? That's pretty much the question I asked myself when I started to think about the Workflow creation flow. In my case the question was to define what the user should see after uploading the source document: Customizing the form, linked to the document or adding signature fields over the document?
When I started to work on the creation flow I did not have a strong opinion regarding steps order. This is after doing design explorations I realized that starting with the form customisation could lead to a less intuitive creation flow. To understand why, here are some context elements:
* at Youtrust, documents to sign are sent via email to recipients thanks to a signature field. A signature field includes signer contact information:
* first name,
* last name,
* email,
* mobile phone.
* with Workflows, we were introducing the placeholder signer field. It allows the Workflow creator to add a signer without knowing its identity yet. To send the document to this type of recipient, the signer email as well as the other contact information are collected while the form respondent is filling out the form.
With these elements in mind, here is what the user flow would look like, if we decided to start with the form customization versus the document preparation:
Option 1: Starting with the form customization
With these elements in mind, here is what the user flow would look like, if we decided to start with the form customization versus the document preparation:
Option 2: Starting with the document preparation
To me offering a clear form preview during the creation flow was essential to build an intuitive experience. Choosing option 1 over option 2 would create a non essential back and forth around the form customization. Post document upload, the user starts the form customization then goes through the document preparation to finally get back again to the form customization. This is because it is impossible to get an accurate preview at the « Form customization – part 1 » step. At this point, we don't know yet if the Workflow will include or not a placeholder signer. As a reminder if a placeholder signer is added to the document, signer information (first name, last name, email and mobile phone) will be collected via the form. To me, it would generate confusion as the user sees another time a step dedicated to the form.
For this reason, I decided to go with option 2. Here is what the design looked like:
2. Define how far we go in the document preparation:
Contrary to our core experience where the user uploads a document whose content is finalised (approved), a Workflow aims to build reusable documents. This means creating within the document content, variables (blank areas), where data will be injected.
To make this happens, 2 main avenues stood out:
* integrating within our app, a text editor,
* outsource the text edition (via tools such as Microsoft Word or Google Docs).
For time and resources reasons we quickly chose to outsource the text edition. It had an important impact on the creation flow:
* explaining to the user that adding variables to the document must be done outside of the Youtrust app. To create a variable, the user has to put word / expression between brackets: [variable name],
* reusing as much as I can existing design patterns, I started the design work of this educational / upload document page.
Inspired by the upload page from our current signature request creation flow, I came up with this design:
Refining before testing
At this point of the design user journey, our goal was to start refining the Workflow v1 features set before running user tests.
To do so, we shared the flows to key internal stakeholders to collect feedback. We also contacted again customers we interviewed during our research phase and conducted solution interviews. While we walked them through the flows, our objective was to get their feedback and evaluate the initial features set we had in mind.
To keep things short I won't disclose all edits we made prior to running user tests. However, here are 2 key elements we changed:
1. The Workflow creation steps order:
Even if option 1 did not create this back and forth feeling around the form customization part, we decided to go with option 2. Rationales were:
* option 1 has been perceived less intuitive than option 2. To key stakeholders, the « expected » step after uploading the document was the form customisation,
* breaking down the form customization in 2 steps allows to lighten the information density per page. Thus, it reduces the mental workload for the user.
2. The document upload page:
The upload page has been enriched with:
* a video explaining how to add variables within a document,
* a larger illustration surfacing a fake text including variables.
With these new elements, the objective was to make the document preparation crystal clear for users.
User tests
From the version 1.0, I then prepared user tests from drafting the script, contacting users to creating prototypes.
User test details:
* Duration: 60 minutes
* Method: remote moderated via Google Meet
* Objective: identify user pain points (view hypotheses we wanted to verify during the user tests)
* Testers panel: 11 users – 7 existing customers + 4 prospects (there was 1 no-show)
* Targets:
* french users,
* current Youtrust app customers with min. 100 FTEs (no API, no One plans),
* prospects with min. 100 FTEs,
* current Youtrust app customers that signed up to the workflows product waiting list,
* Tested scenarios:
* Scenario 1 – create a NDA from an existing workflow – execution side,
* Scenario 2 – review a NDA and send it for signature – execution side,
* Scenario 3 – publish an updated document version and send it for signature – execution side,
* Scenario 4 – create a workflow – creation side.
[read the script](https://docs.google.com/document/d/1dUG2CELzf8tHgR0jblN2p3Sh4VWS2YXn27DBM6HY9dI/edit?tab=t.0#heading=h.an7ptilmlcam)
For context, we initially planned to only run one round of tests. Finally, after running 6 user tests, we observed recurring pain points and decided to implement design improvements to fix them. Thanks to those first user feedback we made a second design iteration of our flows and resumed our user tests.
### Round 1
User tests learnings - round 1
6 users tested — 2 positive findings, 2 elements to improve. Recurring pain points led us to pause and implement design changes before resuming.
[View 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}
All users understand they need to use imposed markers to tag words/expressions on the local desktop in the Word editor. Yet some users didn't catch the nuance between using curly braces and square brackets.
👉 3 out of 6 users understood they need to use square brackets [ ] versus curly braces { } to tag words/expressions.
Recommendation(s):
Keep design as is
All users understand why form answers are displayed within the notification email. For some of them, it was a “waw” effect.
👉 4 out of 6 users said they found really useful to get form answers within the notification email.
Recommendation(s):
Keep design as is
Most users did not understand the form visibility options. Workflows have two form visibility options. The form is either public (anyone with the link to it can access it) or « private » meaning only accessible for Youtrust account owners. Users were instructed to make the form/workflow accessible to all employees at Acme. Since presumably only a few employees have a Youtrust account, users must put the form as public. Yet most users struggled to understand that.
👉 4 out of 6 users did not understand the form visibility options.
Recommendation(s):
* improve the question wording,
* explicit the 2 options wording,
* specify in the instructions that only 3 employees at Acme have a Youtrust account (on a total of 50 employees).
When a workflow has multiple document versions, users struggle to understand which version is going to be prepared for signature.
👉 3 out of 6 users did not understand that the green area highlight refers to the document version to be prepared for signature. This is critical, as this could lead to sending the wrong document version for signature.
Recommendation(s):
* remove the “tag” treatment for document name,
* in the document version area, add a tag mentioning that this version is the one to be prepared for signature,
* add an accent colour on the document title background to make it more visible (left part of the screen).
### Round 2
User tests learnings - round 2
5 users tested on the updated design — 3 positive findings, 1 element to improve. All critical issues from round 1 were resolved.
[View 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}
Using square brackets to tag words/expressions is clear. As surprisingly as it sounds, this second batch of user tests produced very positive results even though we did not make any design edits on this point.
👉 4 out of 5 users understood they need to use square brackets to tag words/expressions in order to prepare their document.
Recommendation:
Keep design as is
All users understand the form visibility options (i.e. who can use a workflow). In the first round, most users struggled to understand that they had to set the form as “accessible to everyone” in order to make it accessible by all Acme employees, even those who don't have a Youtrust account. With this new design, we improved the wording (e.g. using “private” and “public” mentions) and the icons. This clearly paid off.
👉 5 out of 5 users understood the form visibility options.
Recommendation:
Keep design as is
When a workflow has multiple document versions, most users now understand which version is going to be prepared for signature. In the first round, most users were confused about which document version would eventually be sent for signature. This second design iteration, with improved information architecture and visual hierarchy, paid off.
👉 4 out of 5 users now clearly understood which document version is going to be prepared for signature when there are multiple uploaded versions.
Recommendation:
Keep design as is
The creation flow creates a back and forth between the field mapping step and the form question customisation step.
👉 2 out of 5 users did not seem to expect returning to a question customisation step after already mapping form fields at the beginning of the flow. Some expected to land on the settings page. A tester even thought this was a “live” form popping out and wanted to fill it to test it out. Testers were however not surprised by the signer box questions — they understood where it came from and how to use it.
Recommendations:
* No immediate initiative to start — it is not a blocker and does not represent a significant group of users.
* However, it would be worth exploring post v1 a design solution combining these 2 steps into one screen.
User test synthesis
• ✅ Main objective achieved — the design of the user journey just works
• ✅ 100% success rate after round 2 — all 22 hypotheses passed. 4 medium-risk hypotheses failed round 1 (81%) and were successfully remediated.
• ✅ Users understood the product — they grasped the value proposition and kept high interest and energy throughout the tests
• ✅ 11 interviews conducted out of a target of 10 — testers were happy to participate and enjoyed the experience
• 💡 High confidence level built on usability — we're reassured the shipped product will be understood and used
• 💡 17 user insights captured for future product improvements
• 💡 Only 4 design edits needed after round 2 — a very limited set of changes before launch
Final design
Based on the recommendations from the user test learnings round 2, here is the final version of the product we shipped in June 2022:

## Results

• ✅ Product launched in 6 months — from discovery to delivery, Workflows shipped in June 2022 — on time despite resource constraints and a squad reorganisation.
• ✅ 22 hypotheses tested, 100% passed in round 2 — only 4 design edits were needed between rounds 1 and 2.
• ✅ Users understood and valued the product — high engagement throughout tests, 17 user insights captured for future improvements.
• ⚠️ Q2 2022 commercial target missed — the milestone was reached 5 months later in November 2022, due to missing self-serve, key features and marketing positioning.
• 💡 Foundation for the adoption initiative — the gaps identified at launch directly shaped the follow-up research effort detailed in the companion case study.
I made a few extra edits after running the second round of user tests but nothing major blocking the Workflows launch.
Business wise, we did not reach our goal of having X Workflows customers by the end of Q2 2022 (again, I cannot disclose what was the figure). For the record, we reached this milestone late November 2022.
As a team we tried to understand the reasons explaining this result. Several emerged:
* the product was not sold in self serve yet (Sales team had to make product demos to sell Workflows),
* some must have features had not been implemented yet,
* The new positioning, pricing and Workflows presentation had not been implemented yet.
My takeaways
While I really enjoyed being part of this exciting adventure, I feel frustrated by the initial business results. On top of the reasons I just shared, I have the feeling we touched the limit of the MMP approach. The initial product features set was probably too limited at launch making Workflows not relevant for some customer profiles. Also, not offering any self-serve onboarding was probably a mistake as the product comes up with some concepts which can be complicated to understand.
A year later, other key reasons stood out. The 2 main ones were that the value proposition was not clearly understood. Also the document preparation aka adding variables, seemed to be a blocker: users did not seem to understand how to add variables within their documents. Even if it has never been a blocker while we conducted the initial user test, several users clearly said they expected to be able to edit the document directly into Youtrust.
Since then, we have run several major initiatives to make the product richer and more intuitive to use. I detail these in this other [case study](#cs:youtrust-adoption).
Looking back, this project taught me two things I carry with every launch since. First, an MMP that is too minimal can undermine commercial traction just as much as a late product — scope decisions have a business cost that isn't always visible until after launch. Second, user test success on a prototype does not guarantee real-world adoption: the document preparation step passed every test round, yet became the number one adoption blocker in the wild. Closing the gap between lab conditions and actual use is a problem I've been deliberately working on ever since.

## Impact

Launched an automation solution to generate documents to sign