.png)
I completed this project during my internship at ZSuite Technologies, a FinTech startup based in Massachusetts.
UX Designer
UX Researcher
Jan-May 2021
Me (Design)
+ 5 Engineers
+ 1 PM
Figma
React
Escrow is the use of a third party to hold funds before they're transferred from one party to another. An example 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.
The current state of escrow is antiquated. ZEscrow was born out of the realization that the tedious process bankers must undergo in order to manage various escrow accounts can be automated.
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.
ZEscrow is a responsive web app for digital commercial escrow and sub-accounting.
The organization dashboard contains the latest information about all the accounts under a user's management. This view will look different depending on the role of the user, reflecting different levels of permissions and security.
The trustee dashboard contains the latest information about a specific trustee. Using this page, users can create folders and sub-folders to manage their various accounts. They can also complete transactions through this page for the given account.
-1.png)
How'd we get there?
After developing a better understanding of escrow, my PM provided a comprehensive overview of the product requirements he had gathered prior to my internship. 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 helpful in anchoring conversations I had with my PM and engineers since it was so easy to get lost among the different terms used within the space of escrow and banking.
I mapped out the information architecture to help wrap my head around the space.
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.
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. 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 usability 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.
I created initially grayscale mocks to make sure feedback I received was at the level of detail we were ready for.
The organization dashboard initially only contained a card view of account information.
The transfer funds flow was largely focused on getting content on the page in the beginning. We only later decided to put this flow in a modal instead of opening a new page.
For this first iteration, the trustee dashboard contained information about sub-accounts, folders, and transactions. I also explored what a left-bar navigation might look on this page.
Final prototypes
The first round of usability studies with the mid-fidelity wireframes generated a lot of helpful feedback. For the second round, I iterated my designs based on feedback and created high fidelity prototypes.
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.
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.
I redesigned so the user would only be able to start the flow once they clicked on a notification in their dashboard. This was a success, feedback from participants was that they didn't have to do too much thinking around how this process works.
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.
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.
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.
Content really helped improve this flow and ensure full transparency in an interaction that should feel secure, 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 our participants felt confident in the process.
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.
Usability studies are incredibly valuable 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.
Some kind words from the engineer I worked closely with for this project!
