A Foundation to Build On
The solution was deliberately scoped as a starting point. The architecture was designed so that new states, new courts, and additional processes could be added incrementally — making future improvements far cheaper to build.
Building the Training Manual Into the Product
A major financial institution's small claims team was drowning in onboarding complexity. State-specific rules, court-specific formats, and a fragile system of external manuals made training new hires expensive and error-prone.
Background
Onboarding New Hires to Complexity
A well-known financial institution had an internal platform used to manage loan-related processes. A specialised small claims team's job was to prepare legal documents, submit them to court, and serve notices to the relevant parties.
The platform's complexity was entrenched: each state—and often individual judges—imposed unique document requirements, formatting standards, and procedural rules. Veteran employees mastered these nuances over years, while new hires faced stacks of manuals yet still struggled and made errors.
The goal: reduce the time and effort needed for training, and explore ways to streamline the process itself.
Our Approach
Fast Scoping, Focused Discovery
With a tight deadline and a team spread across states and roles, I built a compressed but rigorous process — optimising for learning quickly and making decisions with confidence.
Step 01
Understand the Landscape
I met with the supervisor to gain a high-level overview of the workflow and clarify the team's objectives. Collected existing training materials and mapped the current user journey, highlighting points of confusion and identifying gaps where processes occurred outside the platform.
Step 02
Narrow the Scope
Rather than trying to fix everything, we agreed to focus on 2 states with the highest volume and 3 primary processes (the happy path). This gave us maximum impact within the deadline — and a proof-of-concept that could expand later.
Step 03
Talk to the People
Conducted 6 user interviews — 1 person per process per state. I spoke to a mix of newer staff and longer-tenured employees used to older tools. A notable gap: I couldn't reach anyone brand new to the role, which I kept in mind throughout the solution design.
Step 04
Design & Validate
Mapped a flowchart of the moving parts, identified what was static vs. what needed to flex by state and situation, then built high-level screens using the existing design system — enough fidelity to prototype a buildable solution.
-
Finding 01
Fragmented data sources create calculation risk
Transaction history is hardest to deal with — the calculation requires you to look very carefully to ensure they are not overcharging or undercharging the user.
-
Finding 02
Document assembly is entirely manual
Make sure you get the most recent SCRA. There can be more than one suit package — get the most recent. Rearrange in the right order.
-
Finding 03
The memopad is the only source of critical context
Check memopad for items that could prevent filing. Check legal review, 100% double check, supervisor legal review, any promise to pay.
-
Finding 04
Post-filing steps happen entirely outside the product
Once efiled, get the case number and save the final doc. Update the spreadsheet. A separate team tracks case numbers for mail and adds them to CATS later.
Insights
The Complexity Wasn't in the Steps. It Was in the Variables.
-
A Common Skeleton
Despite different names and contexts, all three processes followed the same arc: prep documents → notarise → send to court → update status in CATS. The skeleton was consistent. The flesh was not.
-
State & Court-Level Variance
What documents to include, which formats were accepted, whether a calculation needed to be adjusted — all of this could differ by state, by court, or even by the presiding judge. This variation lived in people's heads or scattered manuals, not in the product.
-
External Processes Were the Real Gap
Much of the complexity happened outside CATS entirely — cross-referencing guidance documents, making judgment calls, checking parallel sources. The product didn't support this.
The Pivots
Two Layers. One Coherent System.
Visualising the full process as a flowchart helped the supervisor articulate their own process more clearly — and helped me structure a solution with two distinct but connected parts.
The training manual becomes part of the product itself. Each step in a process is surfaced in sequence — no external reference needed. New hires follow the product; veterans move faster.
A separate management interface lets supervisors update which documents are needed, what calculations apply, and what rules are in effect — by state, by court. When rules change, the product reflects it immediately.
Wireframes and UI
Building the Key Screens
With the structure in place, I built a handful of high-fidelity screens using the institution's existing design system — enough to communicate the vision clearly and give the development team something concrete to build from.
Outcomes & Big Wins
What We Delivered
By end of the engagement, we'd established a two-layer solution designed to grow incrementally — a proof-of-concept that showed how embedded guidance could transform a complex, manual-dependent process into something product-native.
Training Time Reduced
By embedding guidance directly into the product flow, new hires could operate without needing extensive training and access to manuals that needed hours of work to create and maintain.
Get in Touch
Let's work on something
worth building
Whether you're launching a new product, rethinking an existing one, or need a design partner who can move fast without losing quality—I'd like to hear about it.
- /in/divya-vasudevan