ZEscrow

Digitizing the escrow process.

During the last two quarters of my senior year, I worked part-time as a UX Designer at ZSuite Technologies, a FinTech startup. As the only designer in the company of around 25 people, I led the design process from research to production. Over the span of five months, I worked in a team of one product manager and five engineers to beta launch our new product: ZEscrow.

What is escrow? 

Escrow is the use of a third party, which holds an asset or funds before they're transferred from one party to another – in other words, money in a state of limbo while waiting for a new owner. A common use case of this is when someone decides to purchase a house, they put their money in escrow first to make sure that the buyer and seller are in complete agreement before completing the transaction. 

Who is this for?

Although future homeowners commonly use escrow, the target user group for ZEscrow was attorneys and municipalities. Attorneys and municipalities both use escrow in a similar way – allocating money to a third party before ensuring that specific agreements are met. Both attorneys and municipalities need a way to separate and organize funds with different interest rates, and that is where ZEscrow comes in.

So, what are we solving?

The current state of escrow is antiquated and has not really improved from the days of paper documentation, faxing, and many rows of Excel. ZEscrow was born out of the realization that the tedious process bankers must undergo in order to manage various escrow accounts can be automated through technology, which would make their job more efficient to allow for more clients.

I mapped out the information architecture to help wrap my head around the space.

After developing a better understanding of escrow, my PM provided a comprehensive overview of the product requirements he had gathered, and the key features the team was hoping to incorporate in their new product. To make sense of all the information given, especially in regards to different levels of permissions within the product, I diagrammed the information architecture of the product. This was super helpful in anchoring conversations I had with my PM and engineers, to make sure we were all on the same page, since it was so easy to get lost among the different terms used within the space of escrow and banking.

Usability Studies

Talking to people to validate my designs

At the end of my first week, I reviewed all the information I’d received and thought of what I could do next to progress our product development process. Thinking back to the usability studies I’d done in university courses, I asked my PM, “Why don’t we validate our design with people before building it out?” Since no one on my team had conducted usability tests in the past, my PM gave me the freedom to lead this initiative.

All the crazy Figma noodles in my initial prototype.

Creating the prototype

With this mission in hand, I started my second week diving straight into Figma, now equipped with a better understanding of what was required within the product. This was my first time working as a design team of one, and my Figma file definitely reflected a bit of the chaos of me trying to produce ideas as rapidly as possible. During this time, I closely referenced the list of product requirements given by my PM as well as the information architecture diagram I had created previously. To gather user participants, I fortunately didn't have to go through the process of finding people to interview for these usability studies, because my PM had developed some relationships with attorneys and municipalities through the customer interviews that they had done initially before I joined and they were all happy to chat again.

Conducting the studies

I worked with my team to define three tasks that we determined would be the most important. I led each 30 minute session, which included two rounds of usability studies with a total of 11 people, while my PM supported and occasionally asked clarifying questions throughout the process.

Some of the initial wireframes I quickly mocked up for the first round of usability studies.

The Scenarios

1. Add a trustee

For the first task, I asked participants to add a trustee, which is the third party agent in an escrow transaction. This task required the opening of a new account within the bank core, which is the core platform where banks perform actions on behalf of clients.  

A really important learning from this first round was that participants didn't realize that this required an external setup on the bank core, which was key to this process even happening. Ultimately, this requirement needed to be more transparent. 

Following discussions with some of the engineers on my team, we decided to rework the entire architecture of the software, just so the task flow would only be initiated once the account was created on the bank core. The user would only be able to start the flow once they clicked on a notification in their dashboard, as shown in this high fidelity version. 

This was a success, and the feedback we got from participants was that it made a lot of sense to them and they didn't have to do too much thinking around how this process works.

2. Create a new sub account

For the second task, I asked participants to create a new sub account, which is an account that would contain information like interest rate, transactions, and account statements. 

The learning from this was that I had to provide a lot of hints since the action buttons were unclear. During sessions, several participants asked, “Where do  I click? Should I click here?” This made me realize the process wasn't super intuitive for our target users. 

Participants informed me some of the confusion was due to the lack of color, so I wanted to make sure that I really made clear the button that started this task flow, as shown below.

3. Transfer funds

For the last task, I asked participants to transfer funds within a sub-account, which is an escrow account that lives under different folders for the purpose of organizing accounts with different interest rates. This was a super key feature of our application, so we wanted to make sure it was as intuitive as possible. 

The main takeaway from our first session was that the wording of the content on each screen was actually pretty unclear. Since this was less of a design issue, and more of a content need, I worked with my PM to improve the copy on each screen to improve concision and clarity. 

The precision of language really helped improve this flow and made sure that there was full transparency in an interaction that should feel super safe and secure, especially given that it involves the transfer of sensitive information. Once we made those improvements and had the participants from the second round go through this, the feedback was that it made a lot of sense, and that our participants felt confident in that process.

Outcome

Partnerships Secured

This resulted in a successful beta launch on our goal date. We received great feedback from our beta customers, some of whom were participants in my usability studies. The sales team also used my mockups to pitch to potential clients, which was super cool to see. By the end of my internship, we were able to secure 19 partnerships with banks of various sizes and revenues.

Learnings

Broader learnings from this experience is that usability studies are really incredibly important in validating designs. 

Although I didn’t have much time on this project, it's also super important to spend more time ideating and exploring for the future. I realized halfway through my internship that I wished I had explored other design ideas earlier in the process, but the time constraint didn’t afford much opportunity for that. 

Another major learning is that design patterns make collaboration easier. Since I wasn’t given a preexisting design system to work with, all of my components were created from scratch and consequently had various inconsistencies throughout that gave engineering a harder time, and the frontend engineer often had to check in with me to confirm details of a design that might have been inconsistent with a different screen – having a design system would have minimized this friction.