All case studies
To give our users a flexible Contract Signing tool allowing for their own document upload and sharing.
Our team
Julian F.
Product Owner
André Saad
Lead designer
Rafael Soares
Product Designer
Problem statement
Many of our users have their own lease documents and supplemental contracts. Some others are hesitant to use ours because of their perception of legal validity. We also don’t yet have contracts for certain markets that we want to become operational in (or may already be operating in).
Business cases
Some of our most important and largest clients do not use our contracts feature in favour of DocuSign or similar e-signing tools.
Users in the Ontario market (second largest in CA) do not use our contracts feature or have churned because we don’t offer a contracts tool that suits their needs.
Quebec (Montreal is the largest market in CA) residential leases are serialized. It is a very common use case for landlords to buy a paper lease and use e-signing tools to complete it.
Feature goals
Like Paper
Give our users a more familiar paper-document like contract signing tool.
Speed to Market
Increase our speed to market as we roll out in new markets or those we don’t offer contracts in currently.
Capture Ontario
Unblock our Ontario users by allowing them facilitate their complex lease and supplemental document signing flow and prevent additional churn + encourage new sign ups.
Research and understanding
We know many of our current and target users already use or are familiar with DocuSign and similar tools. If we can implement something similar, we will have a faster speed to market for new markets and unblock many current and target users to make our platform more “sticky” for them.
We decided to do deep research on our competitors (DocuSign, Adobe Sign, SignEasy, PandaDoc) to identify pain points and innovation opportunities.
Discovery & Insights
We know many of our current and target users already use or are familiar with DocuSign and similar tools. If we can implement something similar, we will have a faster speed to market for new markets and unblock many current and target users to make our platform more “sticky” for them.
We decided to do deep research on our competitors (DocuSign, Adobe Sign, SignEasy, PandaDoc) to identify pain points and innovation opportunities.
Project Kickoff
The product team had a couple of meetings to decide on the product features, possibilities, and whether everything could be within the scope. The design team decided to have a work session to do rough project sketches. The goal was to show the Dev team and the PO how the design would look and keep the team on the same page.
User types
After the discussion, we started to map the user types that would interact with the feature.
Landlord
The landlord would be responsible for creating the contract inside Liv.Sign and indicate where the tenant would sign.
Tenant with a Liv.rent account
The tenant could be a user of Liv.rent, find the apartment, apply, sign the contract and keep all communication inside the tool.
Tenant without a Liv.rent account
The landlord could use Live. rent to manage their listing and draft contracts to send to tenants outside Live. rent. So, we needed to build a UI allowing non-customers to sign.
Illustrations
I’ve always had a deep appreciation for illustration, and for Durable, I saw an opportunity to push this passion further. I dedicated a significant amount of time to crafting illustrations that not only looked visually appealing but also effectively represented the product. Some were based on real images to add authenticity, while the majority were conceptual representations of key features. The goal was to make the product feel more tangible, helping users quickly grasp its functionality in a way that felt natural and engaging. These illustrations became a core part of the brand’s visual identity, adding personality and depth to the overall experience.
Handoff
We organized the files and met with the dev team to explain each screen's flow, interactions, and small details. The goal was to ensure that the entire team was on the same page regarding all touchpoints.
We separated each screen and connected through the triggers. When a component or flow needs more details, we create a dedicated section to add more information.
