How we helped reducing the document processing time by 83%
The mortgage banking process spans various departments, each requiring document processing and data input into Excel for macro-driven computations to progress. The business aim was to replace the manual process with an ML model to streamline operations, aiming to reduce document processing time from 90 minutes to just 15 minutes as part of a larger strategic objective.
The challenge?
We faced the challenge of determining who would initially train these documents for automation, especially because different departments used various document formats. This approach wasn't scalable.
Planning the sprint
This was the stage where I was introduced into the product to conduct the user research and gather more understanding from different departments and see where we could improve.
Following this, we decided to develop a quick MVP product to launch within three months. I needed one month to learn, define, design, and test my approach.
Week 1
User Research
Week 2
Market research
Week 3
Design
Week 4
Usability test
Week 1
Understand the ground-zero’s perspective
I reached out to analysts and managers to delve into their manual processes, aiming to grasp the intricacies of their workflow devoid of automation. My objective was to identify the pain points triggered by various documents in their operational cycle. Conducting interviews across different departments and observing analysts in action, I meticulously documented my observations.
Week 2
Competitor analysis
As a newcomer to this concept, I sought out existing products that tackled similar challenges.
RedIQ emerged as a notable contender, having already established a presence in the market, albeit on a different platform.
The challenge?
We faced the challenge of determining who would initially train these documents for automation, especially because different departments used various document formats. This approach wasn't scalable.
How we helped reducing the document processing time by 83%
The mortgage banking process spans various departments, each requiring document processing and data input into Excel for macro-driven computations to progress. The business aim was to replace the manual process with an ML model to streamline operations, aiming to reduce document processing time from 90 minutes to just 15 minutes as part of a larger strategic objective.
The challenge?
We faced the challenge of determining who would initially train these documents for automation, especially because different departments used various document formats. This approach wasn't scalable.
Planning the sprint
This was the stage where I was introduced into the product to conduct the user research and gather more understanding from different departments and see where we could improve.
Following this, we decided to develop a quick MVP product to launch within three months. I needed one month to learn, define, design, and test my approach.
Week 1
User Research
Week 2
Market research
Week 3
Design
Week 4
Usability test
Week 1
Understand the ground-zero’s perspective
I reached out to analysts and managers to delve into their manual processes, aiming to grasp the intricacies of their workflow devoid of automation. My objective was to identify the pain points triggered by various documents in their operational cycle. Conducting interviews across different departments and observing analysts in action, I meticulously documented my observations.
Week 2
Competitor analysis
As a newcomer to this concept, I sought out existing products that tackled similar challenges.
RedIQ emerged as a notable contender, having already established a presence in the market, albeit on a different platform.
The challenge?
We faced the challenge of determining who would initially train these documents for automation, especially because different departments used various document formats. This approach wasn't scalable.
How we helped reducing the document processing time by 83%
The mortgage banking process spans various departments, each requiring document processing and data input into Excel for macro-driven computations to progress. The business aim was to replace the manual process with automation to streamline operations, aiming to reduce document processing time from 90 minutes to just 15 minutes as part of a larger strategic objective.
The challenge?
We faced the challenge of determining who would initially train these documents for automation, especially because different departments used various document formats. This approach wasn't scalable.
Planning the sprint
This was the stage where I was introduced into the product to conduct the user research and gather more understanding from different departments and see where we could improve.
Following this, we decided to develop a quick MVP product to launch within three months. I needed one month to learn, define, design, and test my approach.
Week 1
User Research
Week 2
Market research
Week 3
Design
Week 4
Usability test
Week 1
Understand the ground-zero’s perspective
I reached out to analysts and managers to delve into their manual processes, aiming to grasp the intricacies of their workflow devoid of automation. My objective was to identify the pain points triggered by various documents in their operational cycle. Conducting interviews across different departments and observing analysts in action, I meticulously documented my observations.
Week 2
Competitor analysis
As a newcomer to this concept, I sought out existing products that tackled similar challenges.
RedIQ emerged as a notable contender, having already established a presence in the market, albeit on a different platform.
The challenge?
We faced the challenge of determining who would initially train these documents for automation, especially because different departments used various document formats. This approach wasn't scalable.
How we helped reducing the document processing time by 83%
The mortgage banking process spans various departments, each requiring document processing and data input into Excel for macro-driven computations to progress. The business aim was to replace the manual process with an ML model to streamline operations, aiming to reduce document processing time from 90 minutes to just 15 minutes as part of a larger strategic objective.
The challenge?
We faced the challenge of determining who would initially train these documents for automation, especially because different departments used various document formats. This approach wasn't scalable.
Planning the sprint
This was the stage where I was introduced into the product to conduct the user research and gather more understanding from different departments and see where we could improve.
Following this, we decided to develop a quick MVP product to launch within three months. I needed one month to learn, define, design, and test my approach.
Week 1
User Research
Week 2
Market research
Week 3
Design
Week 4
Usability test
Week 1
Understand the ground-zero’s perspective
I reached out to analysts and managers to delve into their manual processes, aiming to grasp the intricacies of their workflow devoid of automation. My objective was to identify the pain points triggered by various documents in their operational cycle. Conducting interviews across different departments and observing analysts in action, I meticulously documented my observations.
Week 2
Competitor analysis
As a newcomer to this concept, I sought out existing products that tackled similar challenges.
RedIQ emerged as a notable contender, having already established a presence in the market, albeit on a different platform.
The challenge?
We faced the challenge of determining who would initially train these documents for automation, especially because different departments used various document formats. This approach wasn't scalable.
Planning the sprint
This was the stage where I was introduced into the product to conduct the user research and gather more understanding from different departments and see where we could improve.
Following this, we decided to develop a quick MVP product to launch within three months. I needed one month to learn, define, design, and test my approach.
Week 1
User Research
Week 2
Market research
Week 3
Design
Week 4
Usability test
Planning the sprint
This was the stage where I was introduced into the product to conduct the user research and gather more understanding from different departments and see where we could improve.
Following this, we decided to develop a quick MVP product to launch within three months. I needed one month to learn, define, design, and test my approach.
Week 1
User Research
Week 2
Market research
Week 3
Design
Week 4
Usability test
What we learned
Through this I was able to establish a base structure for myself as to how it works.To work on the enhancements, however, a decent technical knowledge was required too
😍
What users loved
Each coded segment was highlighted making it easier to recognise
Once trained the document goes through another user to recheck before going live
🫤
What frustrated users
Each It could only process rent-roll document format
Training a doc is cell specific. If a text is placed in next cell it's wouldn't be recognized
App had a bigger learning curve
Week 3
Learning what goes behind the curtains..
Learning what goes behind the curtains..
Learning what goes behind the curtains..
I shared my findings with the development team and we discussed the best way to solve the problem. We decided to rely on hints provided by users instead of marking specific cells. This approach made it easier to scale the solution. I spent a lot of time trying to understand how logic works and how to use it in different situations. I made some test cases to check if I understood it correctly, and I kept working with my team until I was confident that I had a good understanding of it.
Week 3.5
How can a user mark elements effectively?
As soon as I had a clear understanding of the product, I noted down the basic things I needed to take into account when designing wireframes.
Create a checklist for the user to define the elements
Add coach mark initially to have a seamless onboarding experience
Add An option to define the ‘Unique Identifiers’ in the doc
Go easy with product terminologies as non-coder may not resonate with it
A quick prototype
Given my constraints on time, I prioritized crafting high-fid designs with existing design system. Concurrently, I consistently sought feedback from diverse teams, ensuring efficiency by avoiding duplicated efforts and facilitating rapid adjustments when needed.
Week 4
Testing the usability
Although this was a success in our internal discussion we urged to test this out with real users to see how if we were able to achieve our Success metrics.
User should be able to perform a standard training within 5 minutes
He shouldn't require a training or get doubts more that 3-4 times in a process
App should be able to run most document formats
What we learned
There were definite hiccups while defining a cue/hint to identify.
Issues arose due to multiple interaction points. Users needed to first select the items on the document. Next, they had to interact with the action pane on the right to define.
Even after completing these steps, users were unsure if the correct result would be generated.
Week 4.5
Iterating the obvious
The changes were subtle but significant from a user's perspective.
We moved the action pane to left as primary inaction section on screen
Document section was still visible but non interactable
User wouldn't have to select anything on document in order to define it. he would just provide hints on left panel and it would dynamically update on doc section. When user is satisfied he would simply save the hints
This would help in validating weather the hints are working or not
Results?
The average time to train a documents was reduced to 6 minutes
With this model it would only reduce the efforts as more documents were trained.