INTUIT QUICKBOOKS
Role
Senior Product Designer
(E2E across IDX + QuickBooks)
Discipline
UI/UX Design
Prototyping
Interaction Design
Design System
Team
2 Designer
6 Developers
3 PM's
Timeline
August 2025 – May 2026 (and ongoing)
// INTRODUCTION
Multi-Account Line Item Extraction lets accountants upload a consolidated PDF bank statement and import transactions directly into QuickBooks — replacing Adobe, Dext, and manual data entry.
// INTRODUCTION
Multi-Account Line Item Extraction lets accountants upload a consolidated PDF bank statement and import transactions directly into QuickBooks — replacing Adobe, Dext, and manual data entry.
// Design Problem
Single-account Statement Extraction launched in July 2025 and worked. But real-world statements are rarely single-account and between Aug–Sep 2025, multi-account PDFs made up 27% of all HITL rejections. Every rejection meant 30+ minutes in a third-party tool, often billed back to clients.
// Context
Where did we start our journey
Statement Extraction is one of Intuit's most strategic AI bets, it was the No. 1 request from accountants, and it's a flagship example of "done for you" accounting.
What existed before this project. Intuit launched Statement Extraction (single-account) to 100% of US customers. It worked beautifully — 98% accuracy on PDFs, ~20-second extraction, bounding boxes that customers called "like using a ruler" — and validated the bet.
The problem the MVP couldn't solve. Real-world bank statements often contain multiple accounts on one PDF. Chase, BMO, Wells Fargo, BofA — all routinely send consolidated statements (checking + savings, or credit card with parent-child sub-accounts). The MVP rejected these or extracted them poorly.
Why it mattered. ~27% of all HITL (Human in the loop) rejections were multi-account statements. Every rejection meant a customer falling back to Adobe Acrobat, Dext, AutoEntry, or manual copy-paste — typically 30+ minutes per statement, often charged back to clients. The single-account experience was delightful for the cases it covered; multi-account was the dark hole the highest-value customers (accountants managing many clients, large firms doing cleanups) fell into.
Two distinct user worlds, one extraction system.
Correctors — internal/external HITL workers using the IDX widget inside SageMaker / Ground Truth, fixing extraction errors at speed
End customers — accountants and SMBs in the QuickBooks Review & Verify widget, importing transactions or running multi-account reconciliation
// The problem
Why this problem was genuinely hard
The customer's words
The source data is wildly inconsistent. Some statements label accounts with full names; some show only the last 4 digits; some bury account info in headers that span multiple pages; some use parent-child credit card structures (one balance, many sub-accounts).
AI extraction is good but not perfect. 94% precision / 93% recall means roughly 1 in 15 transactions needs human attention. The recovery experience is the experience.
One widget serves two goals. Transaction Creation (importing into bank feeds) and Reconciliation (matching books against the source of truth) need different end-states from the same flow.
Mapping between two worlds. Extracted account names rarely match a customer's Quickbooks naming. We can fuzzy-match — but we can't decide for the customer.
Edge cases everywhere. 0-transaction accounts that still need reconciliation. Customers who want only someaccounts from a statement. Statements where account numbers were never extracted. Customers who add a missing account mid-flow.
Hard technical constraints. Existing schema, performance limits with hundreds of transactions per page, bounding-box zoom behaviour, page-by-page PDF scroll, and shipping inside a widget that was already in production for the single-account case.
How I framed the design problem
How do we give customers the confidence to verify and import transactions from a multi-account statement with enough control to shape the data their way, and a clear path to recover when the AI gets it wrong without exposing them to the complexity underneath?
// Design
Design considerations
Persistent context over modals
Multi-account already has high cognitive load (which account am I in, which Qucikbook account does it map to, did I review every transaction). Hiding state behind modals makes that worse. The PDF, the account cards, the active account's transactions, the totals, and the Qucikbook account mapping all stay visible. Modals appear only for bulk actions that genuinely need confirmation.
The user confirms AI mappings — always
We fuzzy-match extracted accounts to Chart of Accounts entries and show that suggestion with a clear sparkle/AI marker. But the customer is the one who confirms — bank account associations are too consequential to auto-apply silently.
Design forward of the schema and forward of the scope.
For schema: We designed the UI states (e.g., "account number not extracted," "user adds new account") before the schema supported them, so engineering built the data model to match the experience. For scope: I designed Phase 1 (single-statement multi-account) so Phase 2 (multi-statement multi-account) is a wrapper around the same account-card system. No redraw, no re-research.
The recovery experience is the experience.
Most AI-product design writing focuses on the magic moment. The harder design work is the unlinked-transactions queue, the bulk-move flow, the "check accuracy" hints, the corrector's red-flag badges. Those are where customer trust is actually built or broken.
// Process
Design principles I followed
Existing schema, performance limits with hundreds of transactions per page, bounding-box zoom behaviour, page-by-page PDF scroll, and shipping inside a widget that was already in production for the single-account case.
Act 1 — The Reset
The first design. We extended the existing single-account widget into a multi-account direction. The first navigation pattern we designed was a dropdown account selector pragmatic, low-real-estate, easy to extend. It cleared early reviews. The schema work began. The Add Account feature was finalised with the team.
Then customer research happened.
📌 PLACEHOLDER — RESET STORY (to fill in review) Stream-of-consciousness OK. Things to cover:
What did the Oct/Nov design board sessions with QB customers actually surface?
Was the dropdown navigation specifically what failed, or was it the broader mental model?
Who flagged it first — you, Haruka, research? What was the moment you saw it?
Was there pushback when you proposed redesigning? From whom?
Any specific customer quote or moment from those sessions that stuck with you?
How long was the reset — weeks? A full month?
Was there a moment you remember thinking "this is the right call" or "this might be career-limiting"?
What changed in V2. The dropdown selector became a horizontal carousel of account cards (Image 1 — customer R&V widget). The change wasn't cosmetic. It surfaced four things the dropdown hid:
Which accounts exist in this statement — at a glance, before the customer has to interact
The state of each account — transaction count, "for review" count, error count, all visible per card
The Qucikbook account mapping — shown inline under each account name, with the AI suggestion (sparkle marker) and a path to confirm or edit
The customer's focus of control — clicking a card moves the entire right pane (transactions, totals, edit drawer) and the PDF preview's active page in lockstep
Act 2 — Designing within constraints
1. Tech debt in the existing widget. The single-account widget was already in production with real customers. Rewriting it wasn't on the table. So we designed Multi-Account as a progressive extension of the same widget — Account cards designed to show Single account and multiple as extracted from the statement.
2. Schema and data structure. The original schema had one transaction array; account info lived at the top level. Mapping multiple extracted accounts to multiple Quickbook Accounts entries required schema work that only landed in E2E (End to end). I designed the UI forward of the schema — including states for "account number not extracted," "user adds missing account," and "0-transaction account needs reconciliation" — so the schema was built to match the experience, not the reverse. This worked because PD partners were brought in early and treated the design as the spec.
3. Performance with 100s of transactions. Some real statements have 300+ transactions across multiple accounts. Rendering all of them at once wasn't feasible. The tab/segment pattern (active account's transactions only) wasn't just a clarity choice — it kept render counts manageable.
4. Limited screen real estate. The right-hand panel had to hold account cards, Quickbook account mapping affordances, filter tabs, a dense transaction table, validation totals, and the import CTA — all in a side panel. The IDS (Intuit Design System) Card component didn't fully cover the use case we needed.
5. IDS component coverage. The IDS (Intuit Design System) Card component didn't fully cover the use case we needed, we explored proposing a new IDS component purpose-built for this use case. It was the right idealistic call — a clean, system-native component would have been the better long-term answer. But the new-component path would have added weeks of design system work for a use case that, at the time, was limited to this one product. So we drove a different decision with the IDS team: customise the existing Card component to fit our needs. We got 90% of the design intent at 20% of the system cost, kept the launch on track, and documented the gap as a future IDS opportunity if other products needed it later.
What changed when real people used it
HITL rejection rate for multi-account statements
of accountant time saved across the Statement Extraction program
extraction accuracy on US launch, CA underway; GB and AU next
// What I learned
AI features live or die on the "what happens when it's wrong" path. The magic moment — here are your 980 transactions extracted in 20 seconds — is the easy design problem. The hard one is the unlinked-transactions queue, the bulk-move modal, the corrector's red-flag badges, the COA mapping confirmation, the 0-balance edge case. Trust isn't built on the happy path; it's built on what the product does when the AI is uncertain. Senior designers know to spend more time on the second one.
Language is the hardest design problem I encountered on this project - The "Unlinked Account" terminology confusion was entirely invisible until a real user hit it. The word "account" meant something different in our widget than it did in QuickBooks — and that collision caused fear, hesitation, and errors. I now treat every label, CTA, and error message as a first-class design surface, not a writing task I'll get to after the visual design is settled.
"Not yet". The reset costed weeks. It was the right call — but only because it came with research, an alternative, and a clear path to "yes."
Launch is the start of the design phase, not the end. The FMH process surfaced things no amount of pre-launch research could have. The "Unlinked" wording problem, the 0-transaction account use case, the single-account auto-association ask — these were knowable only after real customers met real statements. Building the design–PD–PM cadence to act on FMH learnings fast is what made the launch hold. The first 6 weeks post-launch are where the most leveraged design work lives.
What I'm still figuring out. After multiple FMH cohorts we have found many points where we can improve. Even this works and it's a much needed feature and solves main cause but experience still feels complex. We are actively working on new version with improved user experience with less learning curves.
