"As a consumer, I want to provide my mortgage lender with my previous employment history, so that I can purchase a home."


Prior to working on this project the stakeholders had already solidified wireframes from the UX Lead. My role then was to create a high fidelity prototype in sketch and then provide HTML/CSS for the frontend developers. I began my research by studying the wireframes. Afterwards, I began to look at the wireframes with accessibility in mind.

Requests were made that the buttons be aligned right and disabled until all input requirements were met. However, research showed that due to the nature of form fields being left justified, buttons were also to be left justified. Additionally, low vision users prefer having buttons left justified because it increases findability.

Wireframes for verification exchange

Additional changes that were made to the designs were color adjustments. Prior colors used did not meet the recommended 4.5:1 contrast ratio.

Lastly, I pursuaded the product owner into not using disabled buttons. Providing evidence that it would be a stumbling block because of it's low contrast, and that screen reader users would need the validation from the submission in order to fix any additional changes (Read Why Disabled Buttons Suck(Opens in New Window)).

Below is the first high fidelity interation. As you will see it has changed drastically due to several factors related to specific business requirements.

New Screenshot of the Bank X Bill Pay Screen New Screenshot of the Bank X Bill Pay Screen

Usability Test

I performed one internal usability test with a screen reader. The results showed that the password requirement section was only helpful to visual users, but screen reader-only users would not be able to access that same information. I found the best solution was to use the aria-describedby="" attribute. Now, screen reader users were able to focus on the password input and hear the requirements.

However, after validating the password flow with a screen reader user, I was informed that listening to the password requirements was too overwhelming for users who already have a pre-existing password in mind. The user suggested simply including a link to where one could listen to the requirements.

Final Product

As stated, the final product turned out very different because of business requirements. However, the usability for the most part stayed the same.

Apart from the overall design, I was also responsible for creating the high fidelity and animations in HTML/CSS. Here is an example of the animated success icon.