Digitizing a Loan Application Process

In Fall of 2018 I joined East West Labs as a UX Designer. I worked on a project for our client, Builder's Capital, to design a web app where users can fill out and submit loan applications, create loan draw requests, and review their construction projects.
Role: UX Designer
Tools: Figma, Zeplin
Methods: Wireframing, prototyping
Duration: 3 months (September 2018 - December 2019)

The Problem

To apply for loans and draw requests, Builder's Capital (BC) clients must follow a lengthy process that consists of:

  1. Filling out a digital PDF form and emailing it to BC
  2. Printing the digital form and courier mailing it to BC
  3. Connecting with BC staff over a phone call to complete finishing touches on the application and resolve any issues encountered during the process
  4. Waiting for BC staff to manually input the information into a back-end system for follow up processing

In this process, there are multiple points of friction where clients must send information through mail and wait for BC staff to manually enter the information into the back-end system.

To solve this problem, I was tasked to design a web app that centralizes the loan application process for clients, allowing them to fill out and submit their applications and draw requests directly to the back-end system for BC staff to review.

As the UX designer, I worked closely with the lead UX designer and the project manager on this project.


I joined this project at a point where the project manager and leadership team had already settled on the spec and deadline for our first minimum viable product (MVP). Due to strict budget and timing deadlines, user research and testing did not fit within the project timeline and was instead to be conducted after completing our first iteration of the MVP.

The three main features that BC wanted me to include in the Web Platform were:

  • Loan Application: A digitized version of the current loan application form. Users can save their progress within the application and can continue it at any time.
  • Loan Draw Request: A feature that allows users to submit draw requests for their active loans directly, instead of having to fill out and email draw request spreadsheets to the Draw Administrator.
  • Home Page: A centralized location for users to start a new loan application or draw request, continue from a previously saved one, check the status of their applications and requests, and see detailed overviews of their projects.

In this write-up, I will be detailing my work on the Loan Application feature.

Loan Application

For the loan application feature, I created an online experience to replace the PDF loan app form that clients currently used. To start, I conducted secondary research and read articles about form field design (linked below) written by UX design professionals Nielsen Norman Group, Nick Babich, and Julie Grundy, among others.

I then reviewed BC's current loan application form to determine which findings could be appropriately applied to the application form in translating it into an online experience.

A page from the loan application PDF form.

I decided that I wanted to incorporate these main findings into my loan application design:

  • Order the form logically
  • Visually group related labels and fields
  • Distinguish optional and required fields
  • Show form completion progress
  • Provide highly visible and specific error messages

Ordering the Form Logically

I met with the lead UX designer to discuss the current order of the loan application questions. We listed the form fields on a whiteboard and experimented with reordering them in a more logical manner. Our first approach was asking personal information questions at the beginning and having applicants "introduce themselves" before asking about their project details.

We also identified subgroups of related form fields, which could be opportunities to include additional visual breaks in the application. At this point, we invited the PM in to provide her input on our work. After a few minor tweaks, we were ready to proceed.

white board with proposed loan app question grouping

Aftermath of a meeting with the Lead UX Designer on how to reorganize the loan app questions.

Low-Fidelity Mockup

With the order and grouping of the loan application questions settled on, it was time for me to start designing the online application form itself. After sketching some ideas, I took to Figma to create a low-fidelity mockup of the first loan application page. This mockup included two key features: the Section Overview Sidebar and the Section Progress bar.

Low-fidelity mockup of the first loan application page.

After presenting my design for feedback, my mentor asked to me explore some additional sidebar designs as it was not particularly mobile-friendly in its current state. This was important because we wanted to keep the web and mobile designs as similar as possible to prevent users from having to re-learn the layout of the loan application if they were to switch devices when working on the loan app.

Mid-Fidelity Mockup

In my next iterations of the loan application, I tried to simplify the sidebar while still retaining the amount of information provided to users on their overall loan application progress.

I decided to move the Loan App Section List from the sidebar to a header bar above all other elements on the page. The placement of the Loan App Section List at the top was to illustrate that it is a high-level representation of the user's progress.

Below are various iterations of the new Section header bar that I created.

My iterations of the Section Header Bar

While potentially helpful, the details in some of these iterations such as the section progress percentages and error indicators ultimately made the header bars too busy visually. That is why I narrowed it down to the two designs at the bottom.

The two section bar designs that I moved forward with

While potentially helpful, the details in some of these iterations such as the section progress percentages and error indicators ultimately made the header bars too busy visually. That is why I narrowed it down to the last two designs marked with a red box.

The first of these two designs uses color-coding to indicate completed sections (Loan Request and Borrower), incomplete sections (Guarantor and Final Questions), and the current section (Real Estate Schedule). It also includes icons that mark which sections have incomplete form fields or errors. The second design uses a similar but simpler color coding scheme, indicating sections that the user has started, the current section, and sections that have yet to be started.

Because I was not able to test these designs with users, I consulted the lead UX designer who preferred the second of the two header bar designs, citing its simplicity as its advantage. With that decided, I incorporated this Section header bar design into my mid-fidelity mockup.

Mid-fidelity mockup of the Loan Application.

High-Fidelity Mockups

After receiving another round of feedback, I was ready to begin creating a high-fidelity mockup of the loan application page. In this iteration, I wanted to focus on how to separate the subsections of questions that my mentor and I had grouped earlier. I came up with three different ways of approaching this problem:

1. Displaying all of the section questions on a single page and separating question subgroups with lines or a similar visual divider.

2. Dividing sections by placing each subgroup of form fields on a separate page.

3. Displaying every form field on the same page and dividing them into subsections that expand/collapse as the user advances.

I was partial to the 3rd option of displaying every form field in a loan section on the same page but grouping them into collapsible subsections. After discussing with my mentor, I found that we both agreed. We felt that this type of progressive disclosure would reduce information overload, but also maintain the unified appearance of being a single section within the loan app.

However, because we had no means of user testing this design and validating our assumptions, we decided to consult the development team to find out which design would be more feasible for them with respect to their current workload. For the sake of simplicity and meeting the deadline for our MVP, we decided to go with the 1st option of separating subsections with a line.

Despite this, I decided to create high-fidelity mockups of the 1st and 3rd options in case we wanted to try out an alternative design down the road. Below are screenshots of my high-fidelity screens for both versions.

Chosen Design: Line Divided Subgroups

Alternate Design: Progressive Disclosure Subsections

Additional High-Fidelity Mockups


This was my first UX Design job after graduating from university, and it's safe to say that I learned a lot from it. I came across an assortment of challenges during my time on this project that taught me a lot about myself and how I work. Here a few takeaways after reflecting upon my work:

  1. Nothing is ever "done."
    Throughout this project, there were instances where I had to backtrack and edit designs that had already been "finalized" in my mind due to last-minute changes to the spec, timeline, or someone's opinion. These edits ranged from minor tweaks to substantial revisions. This taught me to not get too attached to my designs, and to keep my mind open to revisions. No matter how "final" you think your design is, treat it as a work in progress as there are always other options to explore. That being said...

  2. Don't be afraid to stand your ground.
    When receiving peer feedback on my designs, there were moments when I disagreed with the feedback given but yielded without discussion because my peers had more experience. Looking back on it, it's hard to say if either of us were objectively right but I now realize that I shouldn't have been afraid to voice my opinion. Pushback is not always a bad thing and can often lead to constructive conversations.

    This also applies to how I handled the lack of user research in this project, which I took at face-value. To make up for the absence of research insights, I searched the web for best-practices and design problems related to my work to back up my design decisions. However, I should have also explored alternatives to official user research such as interviewing other Builders Web Platform stakeholders and conducting internal user testing on my designs.
  3. Include your team and the people around you. This is something that I thought I was doing, but it turned out I was actually not doing it enough! During my time at East West Labs, I often reached out to the lead UX designer and my PM to clarify the project spec or to get their opinions on my designs.

    Late into the project, I got a chance to talk with the person who manages loan draw requests at BC, and get her feedback on my Draw Request feature designs. This proved to be very educational and led to the revision of the design requirements. I realized that I should have also been reaching out to people outside of my immediate team. Moving forward, I will definitely be more proactive in connecting to different departments and including as many people as I can into my design process.

Coming out of this project, I feel much more aware of my strengths and weaknesses as a designer. I'm excited to apply what I learned at East West Labs to my next endeavor and to continue growing!