Overview
The signer information webform was created for J.P. Morgan's Middle Market Banking & Specialized Industries (MMBSI) group to untangle complex loan workflows, helping bankers serve mid-market clients faster and with fewer errors, plus quicker loan completion from start to finish. The signer information form captures who is authorized to sign on behalf of the borrowing entity for a loan.
The problem
In the final stages of the loan process, bankers often struggled to collect accurate authorized signer information leading to confusion, delays, and frequent errors.
Client specialists collect signer information via email communication with the client and store what they collect in an unstructured way
When Client specialists gather information from clients, the details are often missing information
Cases are put on hold because of the insufficient signer information which frustrates clients
The solution
We are digitizing the way our clients provide authorized signer information for their loans and how internal teams collect that information.
Discovery workshop
After aligning with the product manager, we hosted a workshop with the sales team to uncover pain points around collecting authorized signer information and to capture real client scenarios. Given the complexity of corporate signing structures, we also mapped key workflows, common cases, and critical edge cases before moving into design exploration.
Workshop goals
Understand the current end-to-end experience for both internal and external users and gather main paint points
Identify different signer roles and entity structures
Surface common patterns and high-risk edge cases that cause delays
Workshop results
The workshop helped us align on the core problems and define a clear direction for solving them. Our top priority was reducing the time and back-and-forth required to collect authorized signer information by consolidating everything into a single, guided web form that clients could complete in one submission.
The current process we want to solve
Low Fidelity Wireframes + Concepts
Once I gathered all necessary information, it was time to begin design exploration. I created 4 low-fi wireframes that best solved the user and business problems.
Tree structure
Users enter the webform and enter all the signers for their entity upfront. This shows the exact structure of the signers and who they are signers for.
Table list
The signers are entered in a table format and the structure is seen through the list.
Card list
Begin by adding the first signer and any signing entity; once finished, the user can enter more core signers by clicking the "ADD SIGNER" button below the cards.
Tab list
The list of core signers for the main borrower is added and put in a tab list. The user can then add any underlying entities and switch tabs to complete others. If more core signers are needed, users can click on the "Edit" button to edit existing signers or add missing ones.
User testing
Before A/B testing, we wanted to ensure which of the 4 directions are top 2. After speaking to the core product team, we decided that the tree structure and tab list are the best options to present to the sales team.
Captured quotes from users at testing:
"I like seeing the tree structure and the relationship of each signer to the entity. This gets pretty complex, so this view makes it easy to digest"
Sales team member
"If we can combine these two where we can still see the structure but not have to put all users upfront, this would be extremely helpful"
Sales team member
"These signing orders can get very complex. I like seeing each entity as it's own section and I can switch between other signers. It makes it easier to review.
Sales team member
After hearing what our users feedback, we heard many commonalities that we affinity mapped to find what was really important for them on this first release. There were really 3 main things that they wanted:
Many users wanted the natural flow of how the physical experience of collecting signer information is. Instead of collecting all the signers at once, they always collect the main signers for the entity first. Through that, they would then create documents to collect the signers for the entities signing on behalf of the underlying signers.
Users appreciated the tree structure and how it helped them visually see who the signers are + scan for any errors in the signing structure. This is especially helpful for complex signing structures that have multiple entities under a main entity.
Collecting the guarantor for each borrowing entity should have the same experience as collecting the signer information. The guarantor collections must be added to the webform for efficiency.
Final solution
For the final solution, we targeted to include 4 main features based on user feedback.
Feature 1: Preliminary dialog collecting primary signers
Users wanted to have more semblence to how they usually collect signer information by collecting the main signers first and collecting underlying entities. We included a preliminary dialog before entering the webform to satisfy this user need.
Feature 2: Signer list as tab
The users will have a view of each authorized signer and the corresponsing list of underlying sisgners in a tab list. This ensures that long signing structures are clearly defined and digestable for users.
Feature 3: Signer hierarchy tree
Users can see a clear view of the entire signer structure indicating who is signing for each entity. Entity and individial icons also help distingquish from each other from a birdeye view.
Feature 4: Review all signing structures
To ensure there are no validation errors, the review page allows users to check their inputs. This page also has a signer hierarchy view for both the borrower and guarantor.
Impact + results
After the release of this feature, the internal teams expressed that the efficiency of gathering the signer information for each entity has been a game changer for their workflow. The signer structure feature was a favorite feature for many and was adopted by the design system for other products to use.
