User problem

From research uncovered in past interviews, the Measuring design impact project, and feedback from ProductBoard, we identified a group of issues relating to the problem of “having to click too much” in the application if users wanted to modify details. A lot of this feedback is due to Finmo being different experience wise than software that mortgage brokers are currently used to.

The main cause of this is that each section within a Finmo application toggles between a view and edit mode. This means the user needs to click “edit details” for each section in order to modify the information and then click “save” to complete the task. This action was a huge pain point because it affected their efficiency when time is of the essence. Most applications that come through for mortgage brokers are on a time crunch and many other factors drive its need to be completed efficiently.

Additionally, we also wanted to investigate a related issue of users having to scroll too much in an application. This feedback was also heard as a part of the research uncovered from the above.

Business goals

We worked with product management and development to discuss the priorities for the quarter. Since we knew from an OKR that UX improvements would be an item on their list, we discussed, organized, and put together the biggest pain points our users were facing in Finmo.

We settled on a prioritized list of issues that if solved, would provide the biggest impact with the smallest amount of effort. Impact was measured by the number of mentions in ProductBoard. The higher the number of requests, the more impact it would provide. Effort was measured by the amount of time it would take the development team to fix it and release the changes. We want a balance of high impact with a small amount of development effort.

Not all issues can be balanced this way though. Some of the issues on our list were highly impactful but required a good deal of development effort. We debated with our teammates before starting any design work as some issues may not be worth the energy at the moment. After some discussion, the problem of editing details would land as priority number two on the list (with editing liabilities  faster being the first).

Research

To start the project, I collected all relevant user feedback into a single document. I wanted to provide focus on the feedback that we would eventually action on. I then shared the document with the product designers so that they could also understand the problem at hand.

After reviewing and discussing the user feedback as a group, we landed on a simplified theme of “Easy detail edit” to summarize the problems at hand. We did this to ensure that whatever solutions we came up with later would be measured against this statement. If she solution didn’t make “editing details easy”, then we would try something else.

Whiteboarding

I worked with the product designers to white board and understand the current Finno UI along with all the different ways we could make “Easy detail edit” a possibility. As mentioned above, we also wanted to figure out solutions to reduce the amount of scrolling a user needs to do on the application.

After some individual brainstorming, discussions and debates we landed on three ways we could solve problem this without too much effort from our development teammates:

1. Remove the “view” mode so that the “edit” mode was present at all times
2. Create separate pages for each part of the application
3. Re-organize the pages so that it better reflected existing software users were used to

Additionally, we also found ways we could provide better clarity for the application section users were on and a small change so that would reduce the amount of scrolling.

1. Section headings that stuck to the top of the screen as you progressed through the application
2. Simplifying address inputs to text with a link until they need to modify it

Usability test plan

After deciding on the three ways to solve the user problems, we set out to create a usability test plan. We needed to determine which solution would be the most impactful for our users. The plan would also include our goals, how we would test, the questions we would ask, and a simple script to ensure we stayed consistent and on track with who we interviewed.

Ideally, we would work with development to create some simple A/B tests for our ideas. Unfortunately, they were all busy and working on other high priority issues at the time. We also determined that a simple click through design prototype wouldn’t work here as we had too many interactions to test with these ideas. One of my design teammates took it upon themselves to create three functioning prototypes based on the directions we set above. These prototypes wouldn’t actually save information but it was enough to get our ideas across to our test participants as they played with each one.

Project impact and metrics

After testing our prototypes with five users, we landed on the following results:

• 100% agreed for remove the current “view” mode so that the “edit” mode was present at all times
• 100% responded positively to the headers that stuck to the top of the screen as you progressed through the application
• 80% responded positively to shortening the height of addresses to just text until they needed to modify it
• 0% agreed for creating separate pages for each part of the application
• 20% agreed that re-organizing the pages so that it better reflected incumbent software users were used to

In summary, removing the “view” mode so that the “edit” mode was present at all times was the clear winner here. We also found that section headings that stuck to the top of the screen as you progressed through the application was a great way to let the user know which part of the application they were on. A high degree of test participants liked simplifying address inputs to text with a link until they need to modify it so we’re also choosing to go with the solution.

These test results were shared with product management, development, and later with the whole company in an all-hands meeting. The test results created created a path forward for how to solve the “Easy detail edit” problem. We’re currently waiting for development help before we embark on making this change.

Visual design

To wrap up the project, we created high fidelity designs of solution that would create the most impact for our users. These would be stored in Zeplin until our development teammates could pick up the work.