Home

JPMorgan
Outside Counsel

Role:

Lead UX Designer

Timeline:

5 Months

Deliverable:

Enterprise Web App

Overview

Reimagining Tecovas' Digital Storefront

Background

Outside Counsel is a platform within JPMorgan Chase's Commercial & Investment Bank that enables external law firms to submit, track, and manage closing documents required to finalize commercial loans. Prior to OC, this process relied on email and physical mail. The MVP digitized it, but a year post-launch, satisfaction was low and the platform was creating more friction than it resolved.

I joined to lead a research-driven improvement cycle, partnering with a PM, research quant, and engineering team to identify where the experience was breaking down and design targeted solutions within the constraints of a complex, regulated, multi-stakeholder environment.

Inside a complex legal and financial workflow

The primary users of Outside Counsel are attorneys and paralegals at external law firms who bill JPMorgan for their time. These are expensive professionals, and every minute spent navigating a portal is a minute billed to the bank.

Their primary job responsibilities in OC is to upload and classify the closing documents required to finalize a loan (anywhere from 10 on a simple deal to 50+ on a complex one) and ensure each is reviewed and accepted by JPMC's internal document review team before the deal closes.

OC sits inside a broader ecosystem of teams with competing priorities:

1

Banking client (external)

Engages JPMorgan for financing and relies on deal coordinators and lawyers to manage the closing process on their behalf. Delays in OC directly impact the client relationship and the speed of the deal.

2

Deal coordinator (internal)

Kicks off a new deal in OC and sets the closing date, giving lawyers the information they need to begin document submission. Managing OC is one of many tasks in their broader workflow.

3

OC lawyer (external)

Attorneys oversee the deal while paralegals handle the day-to-day work in OC, collecting finalized documents, uploading, classifying, and submitting them to the review team.

4

Document reviewer (internal)

Rigorously reviews every document submitted through OC, verifying it is correctly classified, properly signed, and legally valid. A deal is not complete until this team has reviewed and accepted all documents.

Most pain points weren't pure UI problems. They were business process problems with a UI surface, which meant figuring out where in the system a problem actually lived before deciding how to solve it.

User research insights

Reimagining Tecovas' Digital Storefront

Digitized, but not streamlined

When I inherited OC post-MVP, my first priority was understanding how users were actually experiencing the platform. I worked with our research team to run a satisfaction survey, and the results were surprising:

  • 42% of users were satisfied with OC overall

  • 42% of users saved time compared to their previous workflow

  • 50% of users were satisfied with the upload document experience

  • 36% of users were satisfied with notifications

The numbers revealed a clear gap between what OC was supposed to do and what users were actually experiencing. What used to be "upload everything and let the bank sort it out" had become a process that required lawyers to classify every document against 30–40 standardized title types and upload each one individually.

We had digitized the process but added significant complexity on the people least equipped to absorb it.

What the lawyers had to say

The survey told us where the pain was. To understand why, we ran qualitative interviews with attorneys and paralegals across partner law firms. Three patterns emerged clearly:

1

The upload experience was genuinely tedious

Users described the one-at-a-time flow as exhausting for complex deals. At closing, when pressure is highest and time is tightest, lawyers were spending significant time just clicking through the interface.

"I have to click on 40 different things. It takes a fair amount of time to create buckets before I can finally upload the executed documents. In other portals, I can just upload the entire closing set."

2

Document classification caused constant back-and-forth

Lawyers and the document review team didn't share a common understanding of how documents should be categorized. The result was repeated rejections and multiple revision cycles.

"I don't know who created these categories. They do not connect with the way we have things structured, so we spend a lot of time figuring out where to put things. We got a 50/50 shot of being wrong."

3

Notification noise was creating operational risk

Coordinators rarely kept the closing date in OC updated, so lawyers were receiving constant reminders tied to inaccurate deadlines. Ignoring emails wasn't an option given the importance of the JPMorgan partnership, but sifting through the noise was costing them valuable time.

"Our firms 3,400 emails every day. I want these deals finished, but we're having to deal with the email notifications asking us to do things, many of which we can't do because the documents are not ready."

S O L U T I O N 1

Turning 50 repetitive actions into one

Problem

The original upload flow was sequential and repetitive. For each document, users had to add a document title from 30 to 40 standardized options, then upload the corresponding file individually via the actions menu. For a deal with 50 documents, that meant 50 separate cycles. The interface treated every document as an isolated action, with no way to work in batch.

What I designed

I restructured the flow into two distinct phases by separating what documents are needed from uploading the actual files:

  1. Title setup: Users select and add all their document titles at once from a dialog, which establishes the complete closing list for a deal.

  2. Bulk upload: Users upload all their files at once, then assign each file to a document title from the list they just built.

This turned a linear, repetitive loop into a batch action, and matched the mental model users actually had. By closing, most lawyers already know exactly which documents they're submitting. The new flow let them work the way they already think, processing everything all at once rather than one document at a time.

In usability testing sessions, the bulk upload was the most unanimously praised change, with all 5 users confirming it would save them significant time at closing.

What I'd do differently

The shipped version was an improvement, but friction remained. Each file still requires a dropdown selection to assign it to a title, and for 50 documents, that adds up. Given more time and resources, I would have explored a drag-and-drop interaction where you dump all your files and drag each one to its title, or a guided wizard that walks users through the pairing step by step.

The bulk upload was a valuable improvement, but the deeper issue of making document classification feel effortless remained unsolved. That brought us to the next challenge).

S O L U T I O N 2

Streamlining document classification

Document classification with AI

Problem

The upload experience surfaced a deeper tension: why do lawyers have to classify documents at all? Every document in OC must be assigned a standardized title, and misclassification is one of the most common causes of rejection, sending documents back to lawyers for correction and resubmission. Given that the review team examines every document anyway, we questioned whether classification should be their responsibility instead.

The operations team pushed back. Lawyers are the subject-matter experts in these transactions, and their classifications are valuable data the bank wants collected from the people who know these documents best.

The upload experience connected to a deeper tension my PM and I spent significant time working through: why do lawyers have to classify documents at all?

Every document submitted to OC has to be assigned a standardized title. Misclassification is one of the most common causes of rejection. When a document is flagged, it's sent back to the lawyer to correct and resubmit. The review team looks at every document anyway, so why not let them handle classification?

The operations team had a clear answer. Lawyers are the subject-matter experts in these financing transactions. Their classifications aren't just metadata. They're data the bank wants to collect from the people who know these documents best.

What I designed
Alternative solutions

We pushed hard for two alternative approaches:

  1. AI-assisted classification: Users would upload a document, receive a suggested title, and confirm or override the suggestion. Conceptually, this was the strongest solution. However, AI resources at JPMorgan are prioritized and allocated centrally, and our team didn't have access. Integrating another team's AI module would have introduced fragmentation into a flow that already had enough complexity.

  2. Pre-populated document checklists: Users would receive a pre-populated document list based on deal type, so they wouldn't be building from scratch. The challenge was that deal variation is enormous. There wasn't enough clean historical data to predict reliably, and building that foundation would have required a separate data effort outside our scope.

  1. AI-assisted classification: Users would upload a document, receive a suggested title, and confirm or override the suggestion. Conceptually, this was the strongest solution. However, AI resources at JPMorgan are prioritized, and our team didn't have access. Integrating another team's AI module would have introduced fragmentation into a flow that already had enough complexity.

  2. Pre-populated document checklists: Users would receive a pre-populated document list based on deal type, so they aren't building from scratch. The challenge was that deal variation is enormous. There wasn't enough clean historical data to predict reliably, and building that foundation would have required a separate data effort outside our scope.

This is one of the realities of designing inside a large financial institution. You often know what the ideal solution looks like. The work is figuring out what's actually buildable now, and what to do in the meantime.

Interim solution
Alternative solutions

Neither solution was viable within our current constraints, so we took a different approach. Rather than sending misclassified documents back to the lawyer to correct, the review team would update the classification themselves. It doesn't eliminate the friction of initial classification, but it removes the rejection round-trip, one of the most frustrating parts of the experience, without requiring any change to the underlying system.

This is one of the realities of designing inside a large financial institution. You often know what the ideal solution looks like, but the work is figuring out what's actually buildable now. The AI classification and pre-populated checklist concepts stayed in our future-state documentation. Keeping the ideal solution visible ensures that when resources shift, there's already a design direction to move toward.

Rather than sending misclassified documents back to the lawyer to fix, the review team would correct the classification themselves. It's not elegant. It doesn't remove the friction of initial classification. But it eliminates the rejection round-trip, one of the most frustrating parts of the experience, without requiring any change to the underlying system.

The AI classification and pre-populated checklist concepts stayed in our future-state documentation. Part of working this way is keeping the ideal solution visible so that when resources shift or priorities change, there's already a design direction to move toward.

Rejection handling

Even with the review team correcting misclassified documents, rejections still occur due to various circumstances. The rejection reason was hidden or missing entirely, and leaving lawyers with no understanding of what went wrong or how to fix it.

I designed an error resolution flow to address this:

  1. Users click an error status to view the rejection reason and are routed directly to the appropriate fix.

  2. Error indicators appear at multiple levels, including a page banner, so users are aware when errors arise.

The upload experience connected to a deeper tension my PM and I spent significant time working through: why do lawyers have to classify documents at all?

Every document submitted to OC has to be assigned a standardized title. Misclassification is one of the most common causes of rejection. When a document is flagged, it's sent back to the lawyer to correct and resubmit. The review team looks at every document anyway, so why not let them handle classification?

The operations team had a clear answer. Lawyers are the subject-matter experts in these financing transactions. Their classifications aren't just metadata. They're data the bank wants to collect from the people who know these documents best.

S O L U T I O N 3

Reducing notification overload

Document classification with AI

Problem

When I first looked at the notification complaint, my instinct was to explore notification settings. However, these emails can't be turned off due to legal and compliance requirements.

The user interviews reframed the problem. The issue wasn't the notifications themselves. It was that they were tied to a closing date that was almost never current. In OC, every document title entered into the system is assigned a due date of one day before closing. Reminder emails then go out 1, 3, and 5 days before each document's due date. On a deal with 30+ documents, that was a significant volume of emails, all tied to a closing date that coordinators rarely updated.

Lawyers at large firms already receive thousands of emails daily. Dozens of irrelevant reminders from OC on top of that made it nearly impossible to distinguish urgent notifications from noise. Given the importance of the JPMorgan partnership, ignoring emails wasn't an option, but filtering through irrelevant ones was costing valuable time.

The upload experience connected to a deeper tension my PM and I spent significant time working through: why do lawyers have to classify documents at all?

Every document submitted to OC has to be assigned a standardized title. Misclassification is one of the most common causes of rejection. When a document is flagged, it's sent back to the lawyer to correct and resubmit. The review team looks at every document anyway, so why not let them handle classification?

The operations team had a clear answer. Lawyers are the subject-matter experts in these financing transactions. Their classifications aren't just metadata. They're data the bank wants to collect from the people who know these documents best.

What I designed

Since coordinators weren't going to update the closing date consistently, I introduced a soft closing date field that lets OC users set or update the date themselves, overriding the coordinator's date for notification purposes. Lawyers have the best visibility into their deal's actual timeline, making them the right owners of this information.

The key stakeholder question was whether coordinators would be comfortable with external users overriding their date. They agreed, on the condition that they'd be notified when it changed. I designed an automated email to coordinators whenever the soft closing date is updated, keeping the override visible and maintaining trust across teams.

Rather than sending misclassified documents back to the lawyer to fix, the review team would correct the classification themselves. It's not elegant. It doesn't remove the friction of initial classification. But it eliminates the rejection round-trip, one of the most frustrating parts of the experience, without requiring any change to the underlying system.

The AI classification and pre-populated checklist concepts stayed in our future-state documentation. Part of working this way is keeping the ideal solution visible so that when resources shift or priorities change, there's already a design direction to move toward.

Takeaways

Reimagining Tecovas' Digital Storefront

Outcome

By the end of 2025, the platform saw significant growth in adoption, with a substantial increase in enrolled law firms, deals supported, and overall loan volume processed through OC. The design enhancements described here were part of a broader improvement cycle that contributed to continued platform growth and increased confidence from the business in investing further in the product.

Learnings

The most common instinct in product design, especially in enterprise, is to reach for complexity (e.g., a more elaborate UI, a more sophisticated interaction, a bigger feature). This project reminded me that's often the wrong instinct.

The solutions here weren't technically complex. A bulk upload. A date field. A dialog with a rejection reason. What made them valuable wasn't their sophistication. It was the precision of the diagnosis. When you understand the actual root cause of a problem clearly enough, the solution often feels almost obvious. The hard work is getting there.

What I've learned from designing inside a large financial institution is that you always have to hold two things at once: the ideal state, and the buildable state. You document the future vision because when resources shift, you want a direction ready to move toward. You also design the best possible interim solution that fits the organizational, technical, regulatory, and human constraints.

The lawyers who tested these designs told us the changes would save them real time and reduce real frustration. In a workflow where professional time is measured and billed, that's not a small thing.

My PM, Jeremy Galvez (VP Product Manager, JPMorgan CIB), put it this way.

"Gina does not operate at the surface level of design. She thinks deeply about the full end-to-end user experience across the broader business process. In a highly complex, regulated environment, she was able to take fragmented workflows across legal, operational, and financial domains and translate them into experiences that were intuitive, scalable, and aligned to how the business actually operates."