Forms are an indispensable element for sharing information on the internet today. As an integral part of our Consumer Portal build, it was critical to give users a delightful experience at this phase of their shopping journey to minimize drop-offs. I’ll concentrate on 3 parts in the design process that helped enhance our application flow to be more intuitive and convert applicants into borrowers.

The problem

I was assigned to design a more efficient and streamlined application form for our loan borrowers in accordance to the URLA 1003’s requirements.

My role

I spearheaded the UX direction on this Enterprise Consumer Portal feature in order to create a consistent experience for our users.

To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of CU Direct.

Part 1: Linear vs. non-linear navigation

One of the business objectives of the mortgage application was to create flexibility for applicants to either navigate in a linear order, or freely if they chose to momentarily skip sections. For instance, if the user did not know their previous employment history, they would still be able to proceed and fill out the required information at a later time. Based on early research interviews, an added benefit to this functionality created a more transparent and open platform; allowing users to poke around and scan pages.

Before starting to wireframe the navigation, I relied on data that we had collected through competitive analysis and stake holder interviews that helped define the feature set. I sat down with the product manager to find all the different types of required fields we needed to collect and sorted them to formulate a few linear user flows. As a next step I boiled down these fields into groups that would outline our application pages and design patterns. These would become the navigation elements for out design. The final list came out of reinforcing contextual groups based on similar question types and balancing how many questions to ask before user fatigue set in.

The side navigation worked to improve the user’s journey in multiple ways:

1. Set expectation: It allowed them to get a gist of each section, and also see what documents they might be required to submit.
2. Chipping away: Our early interviews revealed that mortgage applicants usually set a dedicated time to ceremoniously fill out the extensive document. Enabling them to skip and work on sections they were ready for meant they could later return to resume a saved state.
3. Section status: It also provided status’ by using visual cues. For instance the use of color or animation to indicate whether the section has been completed, left incomplete, integrations were working in the background, or if a particular page needed their attention. On mobile, the navigation was also accessible to freely jump around between sections.

To address the use-case of an applicant moving forward in a non-linear fashion with errors on required information, we leveraged in-line and server-side validation on the form fields. If a user tried to click “Next” to go to the following page with a required field in error, we would prompt them with an alert and indicated the field in helpful language (i.e. “Your email address appears to be formatted incorrectly”). However, in keeping true to offering a non-linear flow, we would still allow them to jump to another page via the side navigation but indicate via status that the page they just left still had errors that needed attention. This offered flexibility to the user in working through the application but also helped to hold their hand in a non-intrusive way.

Results

The side navigation performed very well in testing. Virtually all users in our sessions recognized it as a representation of navigation and inherently, progress for the application. They understood the site was auto-saving inputs as they worked, and had no issue with going back and forth between pages. They noticed and liked the green checkmarks as they went through the process because it gave them a sense of progression which helped in motivating their completion. One of the participants was quoted as saying:

“I like it. I like how it checks off as you go. It turns green so you know you’ve filled everything out correctly and you know you’re on the next step.”

Part 2: Designing for co-borrowers

An existing requirement on the 1003 URLA form is the ability to add additional applicants, or co-borrowers. In the manual process, borrowers will typically attach additional 1003 forms for each additional applicant, but on our product we needed a clean and intuitive way to replicate the process that was coherent and scaleable. For each applicant, the primary borrower has the ability to add an infinite amount of co-borrowers. Typically it’s a spouse who gets added on, but it can also include business partners who may, in turn, want to add their own spouses to the application. Once adding everybody, the objective was to automate the distribution of applications designated by the primary applicant. So I had a few sprint sessions on a whiteboard to try and solve this a number of ways.

One of the approaches I started with was to have co-borrowers added incrementally using a stepper. Then, for each applicant, the UI would produce corresponding cards asking for name, email and a checkbox to indicate if this person was a spouse or not. The resulting cards would lead to an interstitial work-flow on the following page to match the co-applicants to their spouses if they had indicated one. The initial feedback resulted in a lot of confusion from product teammates. Not only would this create a huge toll on development to work around the technical limitations, but it was completely outside our library of design patterns and interactions.

After several rounds of feedback, product and I continued to work with static designs and came up with a more elegant solution based on simple logic. We would approach each additional co-borrower progressively to prevent any confusion.

After indicating there would be a co-borrower by the primary applicant via binary actions (radio buttons), the recipients could be accounted for via decision tree logic consisting of decisions and end nodes. Thankfully, this method would eliminate extraneous load on the user to think about mapping the all applicants simultaneously.

Results

This pattern was well received by our group of testers, and feedback showed no increase in frustrations from the original interaction issues highlighted in early iterations.

Interact with the resulting desktop experience (external link to Figma prototype)

Part 3: Incorporating required vs. optional fields

A common question for form design is how to mark the required fields in a form. If most fields in the form are required, we should mark them; even at the risk of being repetitive, ugly, or taking too much space. The user experience should never be compromised for the sake of aesthetic subjectivity

Like most other financial documents, our mortgage application contains a majority of required fields. Instead of adopting such strategies as showing instructions at the top of the form saying “All fields are required” or only marking the optional fields, I opted to mark each field to address problems with these approaches:

• People don’t read instructions at the top of forms.
• Even if people read instructions, they may forget them.
• People have to scan the form to determine if the field is required.

The apparent solution was to mark all the required fields. Be as explicit and transparent as possible: for every single field that must be completed, mark it as required.

How to mark required fields?

There are at least two options for our application: an asterisk (whether red or not) and the word “required”.

The asterisk has become very common on the web and users are familiar with its meaning. Its main advantage is that it does not take up much space and looks different enough from the label’s text. Although the asterisk can be considered ubiquitous, I added a hover interaction to those fields to be explicit about the meaning. This subtle interaction gives both a visual confirmation and helps those with screen readers to announce its placement.

What I learned

The primary goal of our mortgage application was completion rate. We worked at minimizing complexity for user by giving the ability to scan the form in its entirety. Along with the parts outlined in this project, we paid close attention to taxonomy, field masking options, in-line validation methodologies to reduce errors, accessibility guidelines and other best practices to help conversion rates.