Summary
I led product design process in a 3-month project to implement two-factor authentication (2FA) on Contractbook.
The goal was to enhance user security without sacrificing UX. To achieve this, we chose email 2FA for a faster
implementation and quicker value delivery to users.
The ChallengeI was part of a crucial team tasked with closing the gap between our competition and us
for Contractbook, a cloud-based contract lifecycle management software for small to medium-sized businesses.
As the Product Designer, I led the product design process for adding a two-factor authentication (2FA) feature to the platform.
Our challenge was to enhance security while improving user experience and reducing friction during the login process.
The challenge
Contractbook is an end-to-end, cloud-based contract management software that enables small and medium-sized businesses to manage their contract lifecycle in a fully automated flow.
As part of a crucial team formed to bridge the gap between our competitors, I led the design process for this project to improve the PDF signing experience.
Initially, Contractbook's 'Sign a PDF' feature had limited functionality, allowing users to upload a PDF but not specify where the signature should be placed. As a result, the signature would appear at the end of the document instead of in a designated signature field.
Due to these limitations, many of our users were still paying for other eSignature tools to deal with PDFs, which posed a significant churn risk for us. Therefore, our design questions were, 'How might we help Contractbook users sign on the dotted line?' and 'How might we help Contractbook users fill out simple information on PDFs?
Defining the Problem
Early Ideation
After establishing a solid foundation, I started designing the PDF signing interface. My primary goal was to create a user-centric interface that would guide users through the process of adding signees and sending PDFs out for signatures.
Design Review & Iterate
I organized a design review with five other designers to gather feedback on the prototype before showing it to users. This review helped me gather new ideas, engage in discussions, and obtain a fresh perspective on the problems, scope, research findings, and design decisions. It also served as a sanity check to ensure that my design aligned with our design system and patterns.
Challenges and Compromises
During testing, the engineers informed me that their initial estimation of implementation time may have been too optimistic. To deliver minimal value to users, we decided to change the MVP to handle only a single signee. Although not the optimal choice, it was the best option to launch within the original time frame, avoid prolonging development, and get feedback early on.
While the MVP only handles a single signee, I continued testing the flow for multiple signees, which would bring the most value to users and the company. I conducted an overview of the design and potential usability issues to ensure the best possible user experience.
UX Improvements - Single Signee Flow
The single signee flow was built during the testing sessions due to time constraints. I made some improvements based on feedback from usability testing to improve the user experience. However, I was unable to complete all the improvements before being laid off.
Choose signing methodWe need to maintain both the original "Sign a PDF" (which places the eSignature at the end of the document) and the one I'm developing as a separate signing method until this feature is fully developed. The reasons for doing this are:I wanted to experiment with removing unnecessary features from the editor.It's easier to use a feature flag and slowly roll out these new PDF signing features to users in this way.This helps manage user expectations before they invest time and effort, in case this isn't what they need.
Learnings
The single signee flow was built during the testing sessions due to time constraints. I made some improvements based on feedback from usability testing to improve the user experience. However, I was unable to complete all the improvements before being laid off.
Choose signing methodWe need to maintain both the original "Sign a PDF" (which places the eSignature at the end of the document) and the one I'm developing as a separate signing method until this feature is fully developed. The reasons for doing this are:I wanted to experiment with removing unnecessary features from the editor.It's easier to use a feature flag and slowly roll out these new PDF signing features to users in this way.This helps manage user expectations before they invest time and effort, in case this isn't what they need.