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. For a real workload with five to ten document variants, this created a significant and repetitive 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 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).
Two to 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.
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, followed by the alias editing and source location enhancements.
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.
Qualitative outcomes:
- Users could see the extraction state across all documents simultaneously for the first time, described by testers as having a clear "source of truth" during configuration
- The alias editing flow, previously a multi-step process that required leaving the screen, was completed inline without interruption
- Configuration time for multi-document setups reduced significantly, though formal time-on-task metrics were not captured post-ship due to timeline constraints
- 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 had a strong SUS score pre-ship, but formal post-ship metrics weren't captured. For a feature this operationally significant, affecting configuration time across potentially hundreds of document setups, even lightweight time-on-task tracking would have produced a compelling before/after story. I'd prioritise agreeing on success metrics with the PM before design begins, not after.
Next Steps
- Formal post-ship usability review with live users (planned)
- Explore AI-suggested aliases: where the model proactively identifies likely field name variants based on document corpus patterns