Rocket Pro Originate

Loan stages and types

Before we start on the work I did, we have to understand the existing information architecture of the list of clients on Rocket Pro Originate. Prior to this work, there were three stages a loan could be in:

1. Pending submission: These are loans that haven’t been submitted by the user yet. The application (for all mortgages in the U.S., the application is derived from form 1003) is only partially finished and therefore saved in our system for completion.

2. Submitted: These are clients that have had their applications submitted to Rocket’s processing team. These may also be referrals, which means the user is giving the client’s contact info to Rocket’s team to take the application.

3. Archived: These are clients who are no longer moving forward on a mortgage.

In addition to these stages, there are 4 different ways a loan can enter our system. I’ll be using some internal jargon used to differentiate these loans, however in the product these aren’t documented:

1. Start new loan: This method is when the user finds a client and starts the 1003 form for the first time using the RPO product.

2. Boomerang: The user sends a link to the client to start the 1003 on their own. Once the client is done with their portion, it “boomerangs” back to the user to finish the application by performing a credit pull and going through the home loan options generated.

3. Refer: The user gives Rocket the client’s name and contact info to take the application instead of themselves.

4. Follow: A user enters in their client’s existing loan number with Rocket to track their loan progress, even though they didn’t start the loan or refer them. This is useful for real estate agents.

5. Lead gen: A user gets a client’s contact info from Rocket and is responsible for converting them and starting a loan.

Diagramming

My first attempt at diagramming this only took the loan type into consideration. It helped me get down my thoughts on the different ways we could remove which include:

• Reassign: Give the client and their loan to a different banker. Users might choose this if their bandwidth is not compatible or if they are having issues with the client.

• Cancel inquiry: The client’s application has been started, but they are no longer interested in a loan at all and want their mortgage inquiry canceled.

• Call us: In cases where credit check has already been run for the client, there are no self-service options available for the user to remove the loan. In this case, they must call us to comply with regulatory standards.

• Remove: In cases where no loan application has been started, the client can simply be removed from our system.

• Commandeer: This option exists solely for “boomerang” loans. Sometimes clients like to start their own applications but then have questions and need help before the credit check. In these cases, the user can “commandeer” the loan and finish filling out the application for the client.

• Unfollow: For loans that were followed, the user can’t remove the client from the system since they were not responsible for entering them in. In this case, we simply remove the user’s access to the loan and remove it from their list of clients.

After meeting with our legal team, I refined the diagram to include documentation of whether the client has given consent to have their loan followed, and also incorporated the loan stages for clarity:

Prototyping

Once this diagram had sign off from the product manager, banking and legal, it was time to begin prototyping. I used Adobe XD for this prototype. I used Rocket’s design system at the time, following the team’s component usage guidance for most of the project.

I liked to set up my files like diagrams so that they make sense whether you are in the prototype or looking at the artboards. I used desktop to create the hi-fidelity prototype, but also recreated each component in the style of responsive web since our design system did not have responsive components.

I laid out my art boards and annotated them with the loan stages so that the file also served as an information architecture document. My philosophy is that, when time permits, to create hi-fidelity prototypes so that engineers can work as efficiently as possible and reduce the need for them to come back and ask question. Although I believe communication with engineers is always needed!

Impact

When this launched, it reduced the need for users to call our internal bankers to remove these loans. It also strengthened our compliance as we could now show regulators that we built ways for our users to directly remove clients from the system without delay, ensuring that clients who did not want to continue with the mortgage process weren’t receiving unwanted calls and emails in a time range that was more in line with client expectations.

Naming and information architecture

Because this feature was primarily a digital entry point to an offline process, there wasn’t as much to consider for the UI. However, to ensure that this feature had the best chance at success, I did a lot of work to name the feature and place it in the navigation.

First, I ran a card sort with the capabilities available in RPO. I included the main value prop of Prospect Assist as “Ask an internal banker to call the client to screen them before taking their app.”. When the card sort came back, it grouped together features like starting a new loan, using a rate calculator, checking rates and Prospect Assist under a category called “prospecting” (named by participants). This informed me to place this action with other similar actions, which led to it’s placement as a button on the Clients page.

I also ran 20 unmoderated user interviews to ask participants how they felt about various names for the feature. First I asked participants to name the feature based on a description of it’s capabilities, and then asked them to evaluate a specific name for the feature. Based on these interviews, we ended up choosing Prospect Assist.

Impact

Since rates were moving fast, we had to as well. This was scoped to be a very low-tech lift to see if there was any interest at all in a solution like this before creating a more complex solution. Ultimately, while it had a net positive impact on the number of loans that came in, it was decided that the juice wasn’t worth the squeeze moving forward. Thus, this low tech solution became the end-state.