IDX Self‑Serve: Turning a specialist‑gated platform into a developer‑ready workflow
Project Timeline: 6 Months
My Role
Team
Project Brief
Impact:
Reduced document onboarding time by 83% (30 days to under 5) and drove a reported 10x efficiency gain across product teams
The IDX Self‑Serve Platform is Intuit's internal solution for document comprehension — enabling teams to extract and infer structured information from documents and media at high precision and recall, without any dependency on the IDX team.
From identity documents and tax forms to purchase contracts and timesheets, structured data locked in documents underpins some of Intuit's most critical workflows. But getting that data out reliably required deep platform expertise and significant IDX involvement. Every new document type meant filing tickets, waiting on prioritization, and spending weeks in back‑and‑forth.
This project set out to change that — putting document comprehension in every team's hands.
Three personas shaped design decisions throughout this project. Two are direct users of the platform; one is the customer who feels the impact indirectly.
Five stages, and every one had friction
Through discovery, we mapped how a team typically onboards a new document type today. The process spans five stages — and at almost every stage, there's friction that slows teams down and pulls IDX into work that shouldn't require their involvement.
Mapping this lifecycle made the opportunity clear: every stage was a potential self‑serve moment, but none of them had the tooling to support it.
Where teams got stuck and why IDX stayed in the loop
Every team building their own comprehension solution
The goal: give every team at Intuit the ability to build their own document comprehension solution — extracting and inferring structured information from documents and media — at high precision and recall, without any dependency on the IDX team and with minimal effort.
The reframe: one unified platform, regardless of document type
This user flow was defined after mapping the current lifecycle and conducting sessions with developers across multiple Business Units. A consistent insight emerged: teams were navigating completely different tools and processes depending on the document type they were onboarding — no standardized path, no single place to go, and no way to make progress without IDX involvement.
Self‑Serve Maturity Levels
The reframe named the destination, but not the pace. To make sequencing explicit, we defined three levels of self‑serve maturity — a shared vocabulary for what "done" means at each stage, so the team could ship the base of the platform without over‑promising the top of it.
FY26 scope targets Level 1 across the core document onboarding workflow.
Document onboarding on the self‑serve platform
The flow begins when a developer uploads one or more documents. The system runs automated classification to determine whether the document type already exists in the platform.
Underneath both paths sits a single design principle: the system absorbs everything that is redundant, deterministic, or scaffolding — classification, ground‑truth generation, de‑identification, auto‑labeling, model execution, precision / recall computation. Control surfaces only where a developer's judgment actually matters — accepting a generated schema, confirming ground truth, choosing which model to promote, approving a deploy. That's the whole ergonomic bar: nothing asked that doesn't need asking; nothing hidden that a power user needs to steer.
What "working" looks like
Three metrics were defined to track whether the self‑serve transformation was working. A use case is counted as self‑serve once any developer can complete the full onboarding flow — schema definition through deployment — independently, without requiring IDX intervention.
Two directions — dense vs. guided
With a clear problem space and defined metrics, the next step was exploring what the platform experience could look like. Two directions were considered.
With the approach decided, detailed mocks were created covering the end‑to‑end flow — from a user's first entry into the platform through to deploying a document type in production.
What internal users told us and where the design changed
Initial flows were tested with internal users across multiple Business Unit teams to gather early feedback before finalizing the design. The sessions surfaced two categories of insight — UX‑level themes and technical signals for the engineering team.
These insights were incorporated into the revised flows before finalization.
The shipped experience, step by step
Upload → classify → schema (reuse or create) → evaluate → refine (prompt or model) → deploy. Each screen below pairs the step the user is on with what the system is doing behind it.
What the platform has unlocked so far
Since launch, the platform has seen meaningful adoption across Intuit — validating that the self‑serve model works across very different document types and team contexts.
Adoption spans HR identity extraction, Finance procurement workflows, QuickBooks inventory and AP automation, QB Time payroll automation, and IBOSS compliance — with teams across Business Platform, IBOSS, QB Time, HR, and Finance already building independently.
What teams shipping with the platform had to say
What the project taught me
The judgment call I'd defend: choosing a guided, step‑by‑step flow over a single dense dashboard — even though senior engineers on the team advocated for the dashboard. The dashboard optimizes for the developer who already knows how the platform works. The whole point of self‑serve is to move that developer off the critical path so anyone can onboard. Designing for the audience you're trying to create, not the one you already have, was the load‑bearing decision.
What this taught me about platform design: the hard part isn't building the tooling — it's picking a boundary between "the platform handles this" and "you handle this," and holding it. Every "just let power users do X" request is a request to reintroduce the exact fragmentation the platform was meant to remove.
What I'd do differently: get real teams shipping on it earlier, with rough tooling, rather than waiting for the flow to be polished. The Business Platform team's 10× efficiency win came from a use case we hadn't specifically designed for — a signal that would have arrived weeks sooner if we'd opened the platform to early builders with more explicit "we're still figuring this out" scaffolding.
How it changed my approach: I now treat "who is currently on the critical path?" as the first question on any platform project. The answer names the constraint every design decision needs to solve for — and often, it's not the persona anyone would list first.