Enter password to view case study
From Pinned Notes to Active Issues
Turning underwriting notes into a clearer operational context layer
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
The request
The project started with a small request from underwriting:
Allow users to pin an important note so it stays visible at the top of the application.
Critical information — manual review requirements, compliance concerns, and borrower follow-ups — was getting buried in the Notes history.
Instead of moving directly into a Pin / Unpin interaction, I wanted to understand why certain notes needed to remain visible in the first place.
Before
Calls, reviews, requests, decisions, and follow-ups were all stored as free-form notes in one continuous list.
What was actually happening
The Notes page looked like a comment feed, but underwriters were using it for much more.
• Underwriting reviews
• Document requests
• Calls and follow-ups
• Compliance concerns
• Decision rationale
• Decision rationale
• As the history grew, users had to read through individual entries to understand:
What matters now?
What has already been done?
What still requires action?
The information existed, but the interface did not expose its structure.
Research changed the problem
I joined a workflow session with underwriters and the Product Manager to understand how Notes were used in practice.
Different issues — income verification, property concerns, calls, compliance, follow-ups — accumulated in the same feed. It became difficult to tell which issue was still relevant or which later update belonged to an earlier note.
Their mental model was closer to:
goal → main update → follow-up
That led to the first reframing:
Notes were not just comments. They were how operational context moved between people working on the same application.
Real underwriting notes revealed the hidden structure
After the session, I analyzed real underwriting notes.
I found that underwriters were already consistently documenting three layers of information:
What was reviewed
Documents, accounts, calls, or other evidence.
/01
What was learned
A finding, verification result, exception, or underwriting judgment.
/02
What needs to happen next
A missing document, follow-up, or another required action.
/03
The problem was that all three were buried inside the same free-form text.
A single income-verification note could contain source review, calculations, excluded evidence, underwriting judgment, decision rationale, and a next action. Anyone picking up the application had to read the entire note to reconstruct what mattered.
Underwriters were already structuring their thinking. The interface just wasn’t exposing that structure.
Reframing the problem
The original question was:
How might we keep an important note visible?
After research, I reframed it as:
How might we help anyone working on an application quickly understand what matters now, what has already happened, and what should happen next — without asking underwriters to change how they work?
Pinned Notes became Active Issues
A pinned note was not really a bookmark. It represented something that was still important right now.
More than one issue could also be active at the same time — for example, an underwriting concern and a separate compliance concern.
So I reframed Pinned Notes as Active Issues. The section answers one question:
What should everyone working on this application know about right now?
Pin a note → it appears as an Active Issue.
Unpin it → it is removed from Active Issues.
There is no separate task, owner, or additional workflow to maintain.
Why application-level?
During the interview, I specifically asked where this information was needed. Underwriters said it mattered most during Manual Review, but compliance or complaint issues could surface at other stages as well.
That changed the placement. Instead of keeping Active Issues inside the Notes tab, I surfaced them at the application level, accessible from whichever tab the user is working in.
Exposing the meaning inside a note
Because findings and next actions were already present in the note content, I did not want to create a new documentation workflow.
I added two lightweight, optional fields.
Key Finding
No additional income could be verified from the reviewed account. The most important conclusion another person should understand.
Next Steps
Request additional bank statements. What should happen after this note.
Full Note
Detailed evidence, calculations, and reasoning remain available.
Scan for meaning → read for evidence
Both fields are optional, so existing behavior still works when additional structure is unnecessary.
I wasn’t asking underwriters to document more. I was separating what they already documented so the next person could understand it faster.
Key Finding
Next Step
Connecting follow-ups to earlier notes
Follow-up notes often relate to earlier work, but a flat feed left readers to infer that connection from the text.
Instead of introducing full threaded conversations, I designed a lightweight Reply pattern.
A follow-up can reference the note it responds to, preserving context without turning Notes into a messaging system.
Making long histories easier to scan
Underwriters also described chronology as difficult to follow on applications with many notes.
Instead of one uninterrupted feed, I grouped Notes by day, creating clear visual anchors and reducing the amount of chronology users have to reconstruct mentally.
This was intentionally not an activity log — the product already has one. The goal was simply to make human underwriting context easier to navigate.
Before / After
The information was always there. What changed was how much work it takes to find it.
Before
Important context buried in the feed
Findings buried in paragraphs
Next action buried in text
Follow-up relationship inferred
After
Active Issues
Key Finding
Next Step
Reply reference
Design decisions and trade-offs
Supportive, not prescriptive
No owners, deadlines, or separate task workflow.
Optional structure
Key Finding and Next Step remain optional to avoid documentation overhead.
Replies, not threads
Enough traceability without introducing conversation complexity.
Designed to evolve
The model can later support issue duration and resolution analysis.
My contribution
• Challenged the initial Pin solution before moving into UI.
• Used the underwriting session to understand where, when, and why critical notes were needed.
• Analyzed real notes and identified the structure already present in underwriters’ work.
• Reframed Pinned Notes into application-level Active Issues.
• Introduced optional Key Finding and Next Step structure.
• Designed lightweight Reply relationships and day-based grouping.
• Kept the solution deliberately incremental rather than introducing a new workflow system.
My core contribution was identifying the larger workflow problem behind a small feature request and designing the smallest set of changes that matched how underwriters already worked.
Reflection
This project started with a request to pin a note.
Research revealed a broader need:
A note can carry evidence, underwriting judgment, unresolved requirements, and instructions for the next person working on the application. When that context is hard to find, every handoff costs time because someone has to reconstruct information that already exists in the system.
The final design keeps the flexibility of free-form notes and the simplicity of pinning while making critical information easier to find, scan, and continue.
The visible changes are small. The larger change is in how the information is structured.
© 2026 tetyana.voronova