INTUIT QUICKBOOKS
Role
Senior Product Designer
Discipline
UI/UX Design
Prototyping
Interaction Design
Design System
Team
Solo designer, partnering with 2 PMs and 5+ engineers across 2 work-streams
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.
// Design Problem
Single-account extraction shipped in July 2025 and worked well. But within two months, multi-account PDFs were driving 27% of all extraction failures, and every failure meant 30+ minutes in a third-party tool, often billed back to the accountant's clients.
// Context
What existed, and what it couldn't do
Statement Extraction is a flagship QuickBooks AI workflow and the top request we heard from accountants. The single-account version was already live across 100% of US customers — 98% accuracy, results in ~20 seconds, with bounding-box precision that users called "like using a ruler." It was genuinely good.
But real-world statements are messier. Checking and savings combined. Parent-child credit cards in one file. Those statements were rejected or extracted inconsistently — and there were a lot of them.
Multi-account statements drove 27% of all extraction failures. Each one pushed customers back to Adobe, Dext, or manual workarounds — 30+ minutes of work that could've taken seconds.
Two user groups, one system.
Correctors (internal and vendor reviewers) focused on speed and accuracy
End customers (accountants and SMBs) focused on confidence when verifying and importing
// The problem
Why this wasn't a simple extension
Synthesized from customer research, 2025
“I'm an SMB owner or bookkeeper. I'm trying to import transactions from a PDF bank or credit-card statement into QuickBooks. But QuickBooks doesn't accept PDFs with multiple accounts in them — so I have to use third-party tools, manually clip out sections, or rebuild the data in Excel. I'm spending my time on data entry instead of running my business.”
A few things made this genuinely hard:
Statements don't follow rules. Account identifiers show up as names, last-4 digits, or not at all. They split across pages. Parent-child credit card structures have their own logic. Every edge case was also a common case.
Account names don't match QuickBooks. Extracted labels almost never align neatly to a customer's Chart of Accounts. We could suggest matches — we couldn't choose for them.
1 in 15 transactions still needs a human. At 94% precision / 93% recall, that's not an edge case on a 200-row statement — it's the core experience. The recovery path was the product.
How we framed the design problem
How do we give customers the confidence to verify and import 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 the complexity underneath?
// 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.
We thought we'd solved it.
The first direction extended the existing single-account widget. We tested multiple navigation patterns and landed on a dropdown account selector — low footprint, easy to extend, cleared early reviews. It looked right on paper.
Then we watched users actually use it.
The dropdown tested fine in isolation. Inside the full Review & Verify flow, it collapsed. Users couldn't track where they were across accounts — especially when errors and mapping tasks pulled their attention in multiple directions. Navigation that felt "low footprint" turned out to feel invisible in the worst way.
We went back to the drawing board.
We explored a few more ideas, and after additional user testing we finalized the card design because it delivered strong results. The remaining challenge was that this component did not exist in the IDS library, which became another problem to solve.
We switched to a horizontal carousel of account cards — and it changed how the whole flow felt.
Each card shows the active account, its QuickBooks mapping, and its current state (transactions, items for review, errors) at a glance. Customers could orient themselves before clicking in. Switching accounts became intentional instead of blind. Batch actions got cleaner. The context that the dropdown buried was now always visible.
Designing for error scenarios
With 94% precision and 93% recall, roughly 1 in 15 transactions needs human attention. On a multi-account statement with hundreds of rows, that's not an edge case — it's the core experience.
The design challenge: make the recovery path fast and clear, without introducing new components or blowing up the build timeline.
We split errors into two types: blocking and non-blocking.
Non-blocking became "For review" — low-confidence fields that don't stop the flow. Blocking stayed "Error" — fix this before you can import. The naming was intentional: "review" signals a task, "error" reserves the alarm for when it actually matters. Language shapes how urgent something feels.
Filtering so customers could triage, not hunt - With hundreds of transactions across multiple accounts, finding a flagged row was painful. We added per-account filtering so customers could isolate exactly what needed attention instead of scrolling through everything.
Errors at the right moments - Error counts on every account card gave customers a sense of scope before they even clicked in. The import modal surfaced unresolved items one more time at the final step — a last safety net before anything hit the books.
Global vs account-level - In single-account extraction this distinction didn't exist. In multi-account, mixing global and account-level errors in the same place created real confusion. We separated them — global errors above the cards, account-level errors on the card they belong to. Simple, but it made a big difference.
The constraints that shaped the decisions
Existing widget tech debt
Rewriting the single-account widget from scratch wasn't realistic — it was already live in production. Instead, we designed Multi-Account as a progressive extension: the account card system works for one account or many, so the single-account experience could adopt it too without a separate build.
Persistent context over modals
Multi-account work is cognitively heavy by nature. We added small but meaningful features to ease that, for example, clicking any field takes you directly to that spot in the document, with zoom adjusting automatically based on whether you need a closer look or a row-level overview.
The user confirms AI mappings — always
We fuzzy-match extracted accounts to Chart of Accounts entries and surface that suggestion with a clear AI marker. But the mapping is never applied automatically — bank account associations are too consequential to silently get wrong. The customer always confirms.
Design forward of the schema and forward of the scope
We designed edge-case states — "account number not extracted," "user adds a missing account" — before the schema existed to support them. Engineering built the data model to match the experience, not the other way around.
Phase 2 (multi-statement upload) was also designed in parallel. It wraps the same account-card system with a statement selector. No redraw, no new research — just a layer on top of what already exists.
Limited screen real estate
The right panel had to fit account navigation, COA mapping, filters, a dense table, totals, and the import CTA. Every pixel mattered.
IDS component coverage
The IDS Card component did not fully cover this use case. We considered creating a new component, but that would have added weeks. Instead, we partnered with IDS to customize the existing Card, hit the launch timeline, and documented what a future “true” component could be if the pattern spreads.
Shipping - The descope, and what design owned.
We split the work deliberately. Phase 1 — single-statement, multi-account — shipped first. Phase 2 (multi-statement) was deferred because we were already running four parallel workstreams: the internal reviewer experience, the customer-facing Review & Verify flow, account-to-COA (Quickbooks account) mapping, and the validation model. Shipping everything at once would've meant shipping nothing well.
Launch is the middle, not the end
Once Multi-Account shipped, the work got more real.
The team ran 44 Follow Me Home sessions — watching customers use it in production. We logged 30+ issues and requests and drove design for 12 P0/P1 fixes that were blocking wider rollout.
Key fixes we shipped:
"Unlinked account" copy confused people (it sounded like bank linking), so we renamed it to Map this account and replaced the dead-end state with an actionable CTA.
Mapping a COA from the account card was unclear, so we added an inline CTA and renamed "Add account" to "Add missing account".
"Edit account" sounded risky, so we renamed the primary CTA to "Save".
Reconciliation users were nervous about "import", so we forked the modal copy to "Ready to reconcile?" vs "Ready to import?".
We added deposit and withdrawal totals and made validation non-blocking so 0-balance statements could still be reconciled.
We introduced a mark-as-reviewed pattern so fixed rows did not keep showing up in Review.
For clean single-account statements, we enabled auto-association when the match was unambiguous.
Working with PD. Some asks were genuinely expensive. Continuous scroll, for example, was estimated at 1.5–2 months. We aligned on shipping the highest-impact, lowest-effort improvements first, documented the longer bets in the backlog, and kept the team protected from "everything is P0."
What changed when real people used it
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
1. AI products win on the recovery path. The “980 transactions in 20 seconds” moment is easy; but trust is built in the queue, bulk actions, error flags, mapping confirmation, and edge cases like 0-balance statements.
2. “Not yet” can be the right call. The reset only paid off because we paired it with research, a better alternative, and a clear path back to “yes.”
3. Launch is the start. FMH surfaced issues we could not predict. Moving fast on the first 6 weeks of learnings is where the leverage is.
4. Language is a design surface. “Unlinked Account” failed because “account” meant different things in QuickBooks vs our widget; labels and CTAs can create fear and errors if we treat them as an afterthought.
5. Using AI tools to create faster testing prototypes. We used Cursor to build working prototypes instead of click-throughs. What used to take weeks in Figma took days — sometimes hours. When something behaves like a real product, feedback gets more specific and stakeholder buy-in comes faster.
