Project overview
The signer information webform was created for J.P. Morgan's MMBSI to untangle complex loan workflows, helping bankers serve mid-market clients faster and with fewer errors + quicker loan completion from start to finish.
The problem
In the final stages of the loan process, bankers often struggled to collect accurate authorized signer information. Without a digital workflow, this information was gathered through back-and-forth emails, leading to confusion, delays, and frequent errors—especially for larger companies with complex signer structures.
The solution
We are digitizing the way our internal teams collect signer information form.
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
The users main pain points
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
Next steps from synthesized test results
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.
