Problem
Xceptor's platform uses Azure Document Intelligence to extract structured data points from financial documents: trade confirmations, loan notices, and similar unstructured PDFs. The AI model worked well for a single document, but the configuration experience broke down when users needed to handle multiple documents of the same type from different vendors.
Each vendor formats their documents differently. A field called Quantity in one confirmation might appear as QTY or Units in another. The system had no way to handle these naming variations across documents simultaneously. Configuration users, the people responsible for setting up extraction rules across large document volumes, had to test each document individually, leave the screen to note discrepancies, return to add field aliases manually, then test again. Real workloads, confirmed by both clients and our own delivery and implementation consultants, typically ran five to ten document variants, sometimes as many as thirty. At that scale, a repetitive per-document workaround stopped being a minor annoyance and became a genuine operational burden.
The core issue was not the AI's accuracy. It was the UX around it. Users had no way to see extraction results across multiple documents at once, and no way to fix naming mismatches without leaving the screen they were working in.
Context
Company: Xceptor, a B2B data automation platform for capital markets operations (confirmations, reconciliations, tax processing).
Users: Internal configuration specialists and power users, some of whom also support direct client implementations. They are technically proficient but not developers: they think in terms of data rules and document structures.
Team: Senior UX Designer (me), Product Manager, two Engineers, Principal Engineer.
Timeline: Delivered across two phases, fully shipped. The initiative was highlighted as a key AI capability in Xceptor's blog post.
Constraints: The core ML model (Azure Document Intelligence) was not in scope for change. The solution had to work within the existing document capture screen, which was already dense with functionality.
Research
My first step was working directly with the existing product. I ran through real extraction scenarios: uploading a document, selecting data points, then testing a second document of the same type but from a different vendor. This hands-on exploration let me map the exact points where the experience broke: specifically, the moment when a field alias needed adding and the user had to leave the screen to do it.
I then conducted interviews with ten internal power users who had been using the feature in client implementations. These were the people closest to real-world usage: they reflected both their own pain and patterns they had observed in customers. Key themes that emerged:
- The back-and-forth between screens was the biggest friction point, not the AI itself
- Users wanted to see extraction happening across all documents simultaneously, not one at a time
- When a field wasn't extracted correctly, users had no immediate indication of why. Was it a naming issue? A document quality issue? Something else?
I also facilitated workshops with sales engineers and customer success managers who work directly with clients, which gave additional signal on where configuration complexity was slowing adoption.
Process
North Star first
Before narrowing scope, I mapped a North Star vision for the entire document capture screen: what would the ideal experience look like if we addressed everything? This was deliberate. The North Star gave stakeholders a shared picture of ambition, and it was well received by the team and in client demos. It also revealed which parts of the broader screen experience were lower-priority, which helped focus later decisions.
User story mapping to define scope
With the North Star as a reference point, I facilitated user story mapping with the product manager and engineering lead. This was the session that distilled the work down to its essential core: the multi-document panel. Rather than redesigning the entire document capture screen, we agreed to focus specifically on the experience of configuring extraction across multiple documents within a single session.
This decision significantly reduced scope, and in hindsight, it should have happened earlier (more on this in Reflections).
Three design iterations
I ran multiple rounds of iteration on the multi-document panel specifically:
- Iteration 1: Presented initial concept. Feedback identified confusion around how the panel would scale with many fields and many documents: the visual density was too high.
- Iteration 2: Refined layout with collapsible table rows, clearer field-level status indicators, and an inline alias editing mechanism. Tested internally and demoed to clients. Strong positive response.
- Iteration 3 (pre-ship): Final refinements based on usability testing. Added source location highlighting, a companion improvement where clicking a field shows exactly where in the document the AI found the value.
Phase 1 to Phase 2
Phase 1, the multi-document panel, shipped first. Rather than treating Phase 2 as a fixed follow-on, I ran a structured post-ship session with the same ten power users: an interview about how they were actually using the shipped panel, followed by a short live task where each set up two or three real documents. That combination of stated feedback and hands-on observation is what shaped Phase 2's scope: the inline alias editing and source location highlighting described below.
Design
The shipped solution centred on a multi-document panel integrated into the existing document capture screen. Key interaction patterns:
Simultaneous multi-document extraction
Users upload multiple documents at once. The AI extracts data points across all of them in real time: users can watch extraction happen across the panel simultaneously rather than testing one document at a time.
Inline alias editing
When a field is not recognised in a second document (because the header has a different name), the user can click directly on that field within the panel to open an inline editor. They add the alias (for example, adding "QTY" as an alias for "Quantity"), save it, and the AI immediately re-processes that document to find the value. No screen switching required.
Collapsible table rows
For documents with large tables (10+ rows of extracted values), rows collapse by default with an expand control. This keeps the panel usable at high data density without hiding critical information.
Source location highlighting
A supporting improvement: clicking any extracted field value highlights the exact region of the document where the AI found it. This gives users confidence in the extraction and helps them diagnose mismatches quickly.
Impact
The feature shipped in two phases: the multi-document panel first (Phase 1), followed by the alias editing and source location enhancements (Phase 2), directly informed by the post-ship session described in Process.
Usability testing (pre-ship): Conducted formal usability testing using a Figma prototype with internal power users. The System Usability Scale (SUS) score came in at 86, classified as Excellent, sitting in the top quartile of SUS benchmarks. This was a meaningful result for a feature of this complexity.
Post-ship survey (after Phase 1): A formal survey with the same ten power users, run alongside the live task session described in Process, recorded average scores of 4/5 for satisfaction, 4.5/5 for confidence in the extraction results, and 4.5/5 for perceived efficiency improvement.
Time saved: Implementation Consultants and delivery consultants who worked directly with clients reported that setting up a single document variant dropped from roughly 5-10 minutes to 1-2 minutes. Real workloads sometimes ran to thirty document variants, so at that scale this was the difference between a multi-hour setup and one that fit inside an hour.
Qualitative outcomes:
- Users could see the extraction state across all documents simultaneously for the first time. Several described the panel as functioning like a single source of truth during configuration
- The alias editing flow, previously a multi-step detour (leave the capture screen, open a separate document, note the mismatched field name, find where to add the alias, come back, re-test), was completed inline without interruption once Phase 2 shipped
- Positive feedback received from sales engineers and customer success managers who validated the concept against real client workflows during the design process
External recognition: The improved document capture experience was featured in Xceptor's 2025 product roadmap blog as a key AI capability, described as enabling users to "see model impact across multiple documents at once."
Reflections
Start scope definition earlier. I invested significant time designing a North Star vision for the full document capture screen before narrowing down to the multi-document panel. The North Star was valuable: it aligned stakeholders and surfaced what mattered. But the user story mapping that defined final scope should have happened earlier in the process. Several iterations I ran on broader screen improvements didn't make it to ship. That was time and effort that could have been directed at refining the core panel sooner.
Measure what you intend to measure. We captured strong signal at both ends: an 86 SUS score pre-ship, and a formal post-ship survey plus live task session that directly shaped Phase 2. What we didn't capture was objective time-on-task telemetry: the 5-10 minute to 1-2 minute improvement is real, but it comes from Implementation Consultant and delivery consultant estimates rather than instrumented data. For a feature this operationally significant, even lightweight time-on-task tracking alongside the survey would have made the before/after story fully evidence-backed rather than partly anecdotal. I'd prioritise agreeing on the full measurement plan, subjective and objective, with the PM before design begins, not after.
Formalize the checkpoint between phases. The post-ship session between Phase 1 and Phase 2, an interview plus a live task with the same ten users, wasn't part of the original plan. I added it once Phase 1 had already shipped, because I saw the chance to validate before committing to Phase 2's scope. It worked well enough that it shouldn't have been left to instinct: a structured checkpoint between phases is exactly the kind of thing that should be scoped into a multi-phase roadmap from day one, not improvised when there happens to be time for it.
Next Steps
- Formal post-ship usability review following Phase 2's alias editing and source location highlighting (planned) — the same structure used after Phase 1, not yet repeated
- Explore AI-suggested aliases: where the model proactively identifies likely field name variants based on document corpus patterns