Turning Notes Into Case Activity
The project started with a seemingly simple request: allow underwriters to pin an important note so it always stays visible.
Instead of designing the interaction immediately, I investigated why underwriters needed pinned notes in the first place.
The research revealed a larger problem: Notes had become an unstructured activity log for calls, document requests, reviews, decisions, findings, and follow-ups.
I reframed the project from pinning important notes to making the operational history and current state of a loan understandable at a glance.
Domain
Fintech lending, credit decisioning, underwriting operations
Product
PlatAI Loan Origination System
My role
Product Designer and design owner for the initiative
My contribution
User research, problem framing, information architecture, interaction design, product system design
Team
Product Manager, Underwriters, Engineering Lead
The Original Experience
The original page was a chronological list of free-form notes.
Each entry could contain:
• an underwriting review;
• a call attempt;
• a document request;
• an email or other communication;
• calculations;
• decision rationale;
• unresolved requirements;
• next steps.
The original experience treated every activity as the same object: a note.
Before: Calls, reviews, requests, decisions, and follow-ups were all stored as free-form notes in one continuous list.
Next step buried in text
Flat chronological stream
Different activities looking identical
Long unstructured notes
This created several problems:
Different activities looked identical
/ 01
A call, a document review, and a decision were all represented as text blocks.
Users had to read the content before they could understand what had actually happened.
Important information was buried
/ 02
Key findings and next steps often appeared at the end of long notes.
Related work was difficult to follow
/ 03
During interviews, underwriters described situations where several notes about the same issue were mixed with unrelated updates.
They had to reconstruct which note belonged to which problem.
Chronology was difficult to understand
/ 04
Notes and document-related updates were not always presented in a sequence that matched how users expected the case to evolve.
The page did not answer the most important operational question:
What has already happened on this case — and what still needs to happen?
What I Learned From Underwriters
Notes were actually
activities
/ 01
Calls, reviews, requests, and decisions were fundamentally different events stored as the same object.
Underwriters think in
unresolved work
/ 02
They needed to know not only what happened, but what still required action.
Case context has to survive handoffs
/ 03
A new underwriter should not need to reconstruct the case by rereading the entire history.
A single underwriting note often captured multiple layers of decisioning, but none of them were structured for quick scanning.
JT
Jiro Takashima
on
Income Verification
Mar 27, 2026
4:55:00 PM
Manual review for income received bank statements for account ending in #0000. All deposits are transfers from other accounts and previously verified income deposits. Many deposits are from another personal account #0000. No additional income verified with this account.
Unable to use sales summaries provided as income verification. Income on tax documentation is less than previously verified on bank statements.
Accounts that have been reviewed include multiple personal accounts and benefit documentation.
Need additional bank statements.
Evidence reviewed
Underwriting judgment
Key finding
Next action
Hover over
the chips
Reframing the Problem
The original design question was:
How might we keep an important note visible?
After research, I reframed it as:
How might we make the history of a loan understandable as a sequence of meaningful activities — while clearly showing what has already been done and what needs to happen next?
That reframing led to a much broader redesign.
The System Change
The most important decision was changing the conceptual model of the page.
Instead of treating everything as a note, I proposed Case Activity as a dedicated operational history of the application.
For the initial implementation, Case Activity is built around the events already captured by the system:
• note added;
• completed action;
• documents requested.
The key shift is that the architecture no longer assumes every interaction has to be represented as a note. An activity becomes the underlying model, while a note is simply one type of activity.
This creates a foundation that can evolve as the product captures more of the lending workflow. Future activity types could include:
• borrower calls;
• emails and automated communications;
• documents received;
• underwriting reviews and decisions;
• AI or Zoom Agent activity.
The immediate solution works with the data available today, while the model is designed to evolve with the system.
"The information already existed.
The problem was that another person had to read the entire note to understand what mattered."
Grouping Activity by Application Stage
The original experience presented notes as one continuous stream.
During interviews, I learned that users already think about work in the context of where the application was in the lending process.
I therefore grouped activity by application stage, for example:
• Manual Review;
• Pending Stipulation;
• Offer Selected;
• Pre-approved;
• Application Created.
Within each stage, events are then grouped by date.
This creates two levels of context:
Where in the loan lifecycle did this happen?
/ 01
When did it happen?
/ 02
Instead of scanning one long history, users can immediately narrow their attention to the part of the workflow they care about.
Each stage can also be collapsed, reducing visual noise on applications with extensive history.
2. Introducing an Event Model
Before
Previously, the meaning of an activity was only visible inside the note text.
After
Each activity now exposes its type, actor, state, and timestamp before the user opens the underlying note.
This creates a lightweight event model that makes activity scannable without requiring users to read every note.
The underlying detailed note remains available when evidence or rationale is needed.
3. Structuring Event Details
Real underwriting notes often combine several different types of information.
I introduced a structure that separates the most important operational information from the supporting narrative.
Depending on the activity, an event can surface:
Key Finding
What the user learned or concluded.
Next Action
What needs to happen as a result.
Required Documents
What evidence is needed to continue the review.
Full Note
The detailed explanation, calculations, rationale, and historical record.
Each activity now exposes its type, actor, state, and timestamp before the user opens the underlying note.
Scan the event → Understand the implication → Expand the evidence
Importantly, underwriters already write most of this information today.
The design is not asking them to document more. It makes what they already document easier for other people to consume.
RP
Rachel Pull
added note
Income Verification
Blocking
4:55:00 PM
Key Finding
No additional income could be verified from the reviewed account. Sales summaries cannot be used for income verification.
Next Action
Request additional bank statements to complete income verification.
Required Documents
Additional bank statements.
Note: Manual review for income received bank statements for account ending in #0000. All deposits are transfers from other…
Show More
Summarize
Key Finding
Next Action
Required Documents
Full Note
Event Model
Turning Next Steps
Into Visible Work
One of the biggest gaps in the original Notes experience was that next actions were embedded inside text.
A note could end with:
Need additional bank statements.
Operationally, that sentence represents unfinished work.
I introduced a dedicated Next Actions section at the top of Case Activity.
It allows the next person working on the application to immediately understand what still needs attention without rereading the history.
A Next Action can remain connected to the event that created it, preserving context between:
what happened → what was discovered → what needs to happen next
This creates a clearer bridge between historical activity and ongoing work.
Preserving Detailed History Without Overloading the Page
The Case Activity page is designed for fast scanning first.
Most events remain collapsed and communicate only:
• actor;
• activity;
• event state;
• timestamp.
When users need more context, they can expand the event to see:
• the original note;
• related activity;
• findings;
• required documents;
• resulting next actions.
This allows dense applications to remain manageable without hiding the detailed record.
AI-Assisted Case Summaries
Another recurring issue was volume.
Some applications accumulate a large number of notes and follow-ups, making it expensive for a new user to understand the full case history.
I introduced an optional AI Summary action.
Rather than replacing the source activity, AI acts as an assistive layer that can help users quickly understand the case before diving into individual events.
This is particularly valuable for:
• handoffs;
• escalation reviews;
• returning to a case after time away;
• applications with long activity histories.
Because this is a credit decisioning environment, the original activity remains accessible as the source of truth.
AI helps users interpret the history — it does not replace the evidence behind the decision.
Before → After
Before: Notes
The system stored a chronological stream of free-form text.
Users had to read through individual notes to determine:
• what happened;
• why it happened;
• what was concluded;
• which actions were still outstanding.
Different types of work were represented in exactly the same way.
After: Case Activity
The application history becomes a structured operational view.
Users can quickly understand:
• where in the loan lifecycle an activity occurred;
• who performed it;
• what happened;
• what the result was;
• when it happened;
• what still needs to happen next.
The detailed source record remains available when needed.
My Contribution
I led the design direction from the original Pinned Notes request through research, problem reframing, information architecture, and interaction design.
My core contribution was recognizing that the existing Notes model no longer reflected how underwriting teams were actually working — and redefining it around activities, outcomes, and unresolved work.
I designed the architecture to solve the immediate workflow problem while creating a foundation for future communication, automation, and AI-assisted case management.
Expected Impact
Faster case comprehension
/ 01
Reduce the time needed to understand application history and current state.
Clearer handoffs
/ 02
Make findings, unresolved work, and next actions immediately visible across users.
Better traceability
/ 03
Connect activities to findings, evidence, and resulting actions.
Scalable case history
/ 04
Create a foundation for communication events, automation and AI-assisted case management.
The project started with a request for a pin.
The solution became a scalable model for understanding the entire history and current state of a loan.
© 2026 tetyana.voronova