Notarize Mobile Web
Overview
We increased transaction conversion rate and the number of transactions completed per day by implementing a responsive web experience for Signers.
You can read more about it in the Notarize blog post.
Background
Notarize (now rebranded to Proof) is a platform that allows users (referred to as “signers”) to get documents signed or notarized online. The platform caters to enterprise customers that send business and real estate documents to their signers to be signed or notarized, as well as signers that need their own personal docs signed or notarized.
Previously, signers had the option to use desktop web or our mobile app to get their documents notarized or signed. The web pages at the time weren’t responsive, and there was no mobile web experience.
Problem to solve
There were multiple reasons we sought out building a responsive web experience for signers.
Having a mobile web experience is table stakes. More users are searching and completing tasks on the go while on their phone. Having a mobile web experience is expected, and something that all of our competitors’ already had.
We believed that forcing signers to download our mobile app in order to use their phone to sign and notarize documents was hurting our conversion. Our hypothesis was that if signers had the ability to sign or notarize documents on mobile web it would be easier and faster for signers to complete their task by removing the friction of needing to download our app or switch to their computer.
Enterprise customers were requesting that their signers didn’t have to download the Notarize mobile app to use the product on the go, because they felt it was an unnecessary step for a product they don’t expect their signers to use often.
My role
I was the Product Manager on this project. I was responsible for writing product requirements for alignment across the organization, working with UX and Engineers to ensure what we designed and built would meet the product requirements, and QAing the final product. We staggered the release of mobile web to different signer types. I was responsible for coordinating the dates for each release and communicating them internally, writing release notes to support our internal teams on the releases, and reviewing customer communication and Marketing plans to ensure that we were presenting the feature accurately, externally. I was also responsible for working with a Data Analyst to create reports on the metrics we wanted to track, and reporting on the data to internal stakeholders to ensure each release didn’t negatively impact our KPIs.
The rest of the team involved in working on this project was a Product Designer, a UX Engineer, 3 Full Stack Engineers, and a Data Analyst. We also worked with the Product Marketing and Customer Success teams.
What we built
We first built a landing page for signers on their mobile device to choose to use web or app. This allowed us to keep deep linking to the mobile apps if anything went wrong with our release of mobile web and we needed to rollback the release. It also allowed us to segment signer types that saw this page so that we could release to a limited number of users to start.
There were an additional 21 pages that needed to be rebuilt responsively, some of which had to be redesigned as the current UX was not conducive to mobile screen size. It also required working with Design Systems to rebuild components responsively and build new components to support the updated, responsive UX.
Once we successfully rolled out mobile web to all users, and all transaction types, we removed the landing page and had all Signers go through mobile web.
Metrics
We did a pre/post analysis and looked at data from before the release of mobile web as well as after and compared to make sure all KPIs were neutral or positive.
We released mobile web to the signers of 1 enterprise customer to start and monitored the data. After seeing that all KPIs were neutral, we continued to release iteratively based on transaction type and signer type to maintain confidence that we didn’t hurt KPIs by releasing mobile web.
Main KPIs
Transaction conversion - increased by 1.7% by the end of the project
Number of org-initiated transactions completed per day - increased by +50 transactions a day initially. This was by nature because certain orgs were holding back sending transactions until there was a mobile web platform. By the end of the project, transactions completed increased by 100s per day depending on how many transactions orgs were sending.
Number of retail initiated transactions completed per day - increased by ~+80 per day by the end of the project
Secondary KPIs
Percentage of transactions completed per platform - where we previously saw a 60/40 split on transactions completed on desktop vs mobile apps, we saw a shift in mobile web taking over a major portion of the mobile app traffic. Desktop remained at 60%, mobile web took over 30%, and mobile apps rounded out 10% of transactions completed.
Enterprise customers that had a mobile web experience as a requirement - we were able to onboard 4 additional Enterprise customers that were requesting mobile web as an option for their signers
Key takeaways and learnings
We initially had 2 enterprise customers that requested a mobile web experience for their users. After we released the mobile web experience, additional customers had it as a requirement before onboarding with Notarize. The feature turned out to be a great return on investment.
With an intuitive mobile web experience, the mobile apps became used less often. It shifted our strategy of the mobile apps to cater towards the retail signer type, which were still completing transactions at an equal rate on the mobile apps as they were on mobile web, and remove functionalities for other signer types that were no longer using the mobile apps.