Project background
Four Product Leads in two years — and I was the only designer
The company builds a SaaS platform for banks managing Confidential Invoice Discounting lending. I joined as the sole designer and spent two years shaping both the Bank Staff and Client portals — responsible for 20+ features from discovery through to development handoff.
Alignment ran across 25+ stakeholders on both sides: bank-side SMEs, operations staff, and business analysts, alongside the vendor-side product team. And that team changed significantly over the two years — four Product Leads and two Client Delivery Managers. In the final months before a critical deadline, I stepped into a broader role, covering customer communication, requirements gathering, prototyping, and writing dev specs simultaneously.
The core challenge wasn't scope or timelines. It was the gap between what the customer expected and what the team was building. Closing that gap became my primary focus across the entire project.
How I worked
My approach across the project — including AI
Because the team was lean and timelines were tight, I developed a working process built around speed and alignment rather than traditional research cycles. The core of it was prototype-first: showing something clickable early — at roughly 10% completion — to a focus group of SMEs, real bank workers, and business analysts. This replaced written specs as the primary alignment tool.
AI in my workflow
I use AI tools — primarily Claude — as a thinking partner across the product work, not just for content generation. In practice this means: drafting PRDs and user stories with my domain knowledge and requirements as the input, then refining the output until it reflects exactly what the team needs. I bring the context; the AI helps structure it faster.
This has made me meaningfully faster at the parts of product ownership that used to slow me down — writing, structuring requirements, preparing documentation — without replacing the design thinking or stakeholder judgment that actually drives good outcomes.
About this feature
Service Request — 1 of 20+ features I designed for this product
I'm sharing Service Request as a representative example of my work here because it captures the full range of what I did: defining the problem, making product decisions, designing across two user types, and validating through demos rather than formal testing.
Before this feature existed, communication between clients and bank operations teams happened across email inboxes, phone calls, shared mailboxes, and Excel trackers. There was no single place to see what had been requested, who owned it, or where it stood.
Clients had no visibility into whether the bank had received their request. Operations staff spent time manually triaging emails. Important decisions were scattered across systems — audit trails nearly impossible to reconstruct. The operational cost was real: delays, duplicate requests, and relationship managers spending time on coordination instead of client work.
Users & their needs
Three user types, very different goals
Understanding who would use this feature — and why — shaped every design decision. The same request had to look and behave differently depending on who was viewing it.
Bank Admin — Template Manager
David K.
Senior Operations Analyst · 5–10 users
"We've never had a structured process before. I need to get this right the first time — clients will see it the moment it goes live."
Goal
Build the service request template structure from scratch — translating informal email conversations into clearly routed, structured request types.
Key frustrations
Existing processes undocumented — live only in email threads and people's heads. No way to preview what a client sees before publishing. Changes go live immediately with no staging or rollback.
Needs
Borrower — CID Lending Client
Sarah M.
Treasury Manager · Occasional user
"I sent the limit increase request to my RM on Tuesday. By Friday I still didn't know if anyone had even looked at it."
Goal
Submit requests with confidence they've reached the right person, and track progress without chasing anyone by phone or email.
Key frustrations
No confirmation when a request was received or forwarded. No visibility into who was handling it. Had to re-explain context every time she followed up. No record of past requests to reference.
Needs
Bank Staff — CID Operations & BDM
Two sub-roles, one platform
Internal users · Daily to weekly · Medium technical comfort
"We had a shared mailbox that 12 people watched. Nobody knew who was handling what — requests got actioned twice or just dropped entirely."
Context
High volume, process-driven. Handles day-to-day servicing: limit changes, drawdowns, amendments. Works across a large portfolio of clients simultaneously.
Motivated by
Throughput and accuracy. Zero dropped requests.
"I needed to send the client a request for updated financials. There was no system for it — just an email that sat in their inbox with no way to track if they'd responded."
Context
Relationship-focused, lower volume. Handles onboarding requests, facility setup, early-stage client queries. Needs full client context at a glance before acting.
Motivated by
Client relationship quality. No missed onboarding steps.
Shared frustrations
Shared inboxes with no ownership — requests handled twice or silently dropped. No visibility across the team. Requesting info from clients meant breaking out of the thread into email. Handoffs required forwarding long email chains.
Shared needs
How the workflow is structured
5 flows, 2 portals, 6 lifecycle states
Requests could be initiated by either side. Ownership changed constantly — unassigned, assigned to a team, assigned to a person, reassigned, reopened. Every flow was mapped before prototyping began to ensure the design covered every state, every actor, and every edge case.
Config Studio
Notifications & Comm
Request Template
Portal · Category · Subject · Team · Fields
Live in portal · History log updated
Borrower portal
Service Requests
Create Request
Category · Subject · Fields · Description
New
Bank Staff portal
Team lead assigns to staff member
Review template
In progress
Send to Borrower
ResolvedClosed
Bank Staff portal
Business Profile
Toolbar → Service Req.
Category · Subject · Message · Select client
Awaiting client
Borrower portal
Service Requests
Resolved request
Required: reason for reopening
Reopened
Reopened loops back to In progress — same request, full history preserved
Key decisions
Six decisions that shaped the feature
Clients select a request type before submitting. This enables automatic routing, consistent triage, and SLA tracking — without manual review of every incoming message.
Every request shows the assigned team and individual, in both list and detail views. The biggest operational risk was requests sitting unattended — surfacing ownership directly addressed this.
Bank staff think differently when managing team workload versus their own tasks. Two distinct views: "What does my team have?" and "What am I responsible for?"
Clients don't need to understand internal workflows. A consistent status visible across the portal gives them confidence without exposing operational complexity.
Closed requests can be reopened, not duplicated. Preserves conversation history, maintains the audit trail, and prevents the same issue appearing as multiple separate requests.
The team queue view was built around search, filtering, saved views, sorting, and pagination. A handful of requests can be managed manually — hundreds cannot.
Final design
UI screens — decisions made visible
Each screen below connects to a specific design decision. The core principle throughout: structure over free form. What used to take days to triage now routes automatically from the moment a request is submitted.
Bank Admin builds templates in the Config Studio — defining portal, category, subject, form fields, and the team for auto-assignment. No free-form text: every template produces a structured, routable request. The list on the left shows the full template library already in place.
The Borrower sees a clean, pre-structured form driven by the Admin's template — category, subject, and relevant fields already defined. No ambiguity about what to include. Status is surfaced immediately on submission. The panel opens directly within the Finance Dashboard, keeping the client in full context of their accounts.
Every request shows its category, direction (incoming/outgoing), status, and linked business — ownership visible at a glance. Clients can filter by business, status, and category without needing to contact anyone.
Three tabs in one panel: Details (request metadata and current status), Comments (communication thread — bank and client in the same window), and Activity log (complete audit trail). Reopening a resolved request preserves this entire history.
Bank staff see their personally assigned requests in a structured table alongside Tasks, Approval Requests, and Risks — everything in one place. Direction, category, client, deal, and status visible without opening a single request.
Result
From concept to tested feature in 2 weeks — ready for production
The prototype-first process paid off at every stage. Requirements were aligned before a single line of code was written, which meant the engineering phase moved fast. I ran refinement meetings with the dev team — working through Jira tickets together, clarifying edge cases, and resolving open questions before they became blockers in development.
That close collaboration meant the feature was built end-to-end in roughly 2 weeks. Before releasing to the client, I was involved in testing and ran a 70% demo with the focus group — a final validation pass that gave everyone confidence in what was going out.
Bank workers were genuinely happy with the result. The feature is now in the final stage before production rollout — the next step is enabling it live for the client.
This one worked because the whole team moved together — designers, engineers, QA, and client stakeholders — all aligned from the start. The process made that possible.
Feedback
From the team
"She is amazing at pulling vague requirements out of several people's heads and turning them into something engineers know how to accomplish. She has also been a complete hero in designing prototypes for getting sales over the line or proving out concepts without committing larger engineering efforts."
Anthony Aragues
VP of Engineering
"I especially admire Alina's ability to take vague, messy requirements and turn them into something clear and beautifully structured. She works in tight feedback loops, communicates constantly, and somehow always delivers ahead of schedule."
Emily Lloyd-Penny
Client Success & GTM Leader
"Her input to solution analysis, prototyping and demonstration preparation is invaluable. I would have no hesitation in recommending Alina."
Tony Hurlock
Director of QA
"Alina brought tremendous skill and creativity to the challenge of building complex end-to-end product flows from scratch. She never backed away from complex problems or ambiguity. Instead, she leaned in and delivered thoughtful, well-structured solutions."
Chris Hecht
Former manager
