ADI
Designing the handoff between AI and human judgment.
Investment teams need the right information from dense financial documents. ADI uses AI to extract and map it into iLEVEL. I redesigned the core mapping workflow that turns those findings into usable financial data, with analysts in control of what makes it into the system.
ADI 1.0 reduced data entry. It left the cognitive work intact.
I audited the ADI 1.0 Mapper and mapped the decisions analysts had to make to create a mapping. The workflow began with extracted tables. Users compared source values with iLEVEL data, decided what to include, and moved rows between Excluded and Included.
AutoMatch could suggest a destination, but analysts still had to keep their target iLEVEL items in mind while searching through the document. The system had found data; the user still had to work out what mattered and why a match made sense.
The system organized around what it found.
Clients organized around what they needed.
Large datasets. Many periods. Long documents. Repeated onboarding.
Users arrived with a dataset in mind.
I paired a flow audit with client interviews and workflow walkthroughs, tracing the work from target iLEVEL item to source value, proposed match, and inclusion decision. The walkthroughs made the reorientation visible: analysts moved between the document and iLEVEL, kept their target list in memory, and repeated that work across assets and periods.
Three patterns shaped the design direction: users started from known data needs, still had to verify AI output, and wanted their attention directed to uncertain mappings.
Client interviews · workflow walkthroughs · product review · stakeholder conversations · prototype feedback
“I already know which financial fields I need. I'm really looking through the document to find those values.”
5 of 6 users approached the work with known financial data points in mind. The product started with everything in the source; users started with what they needed to collect.
“Even if it finds the value for me, I still need to know where it came from.”
Automation reduced entry, not verification. Trust depended on seeing the AI proposal with its source evidence—and having a way to correct it.
“If these are obvious, I don't want to spend time checking every one. Show me the ones that actually need me.”
Users spent disproportionate effort on uncertain or structurally unusual mappings. Review needed to focus attention, not put every result on equal footing.
Research note: quotes and counts reflect the research activities described here. The workflow diagram is a synthesis of the observed pattern.
The research changed the Mapper—and surfaced a related need.
I proposed organizing the Mapper around the data users were trying to collect: let AI make a first pass, keep source evidence close, and reserve human review for decisions that needed expertise.
The research also surfaced a need beyond my scope. Clients wanted to save curated lists of iLEVEL data items and reuse them across assets, requests, and periods. I opened the conversation that led to Dataset Management being created and explored; a colleague owned and designed that capability.
The first shift reached production.
ADI 3.0 shipped the dataset-driven Mapper alongside unstructured-data extraction. Analysts could begin with the data items they needed, review them beside the source document, then validate before ingestion.
The release established the first part of the larger workflow: Extract → Map → Review → Validate → Ingest. I presented the work across senior Product, UX, iLEVEL, Commercial Strategy, Client Engagement, and Engineering stakeholders.
Structured review around the data items users needed.
Expanded the source material ADI could help organize.
Some existing users were initially confused, then described the flow as smoother after adjustment. No verified time, accuracy, or adoption metric is available.
Clients said the upfront work of setting up a dataset paid off across repeated workflows. One described removing the Include / Exclude step as the best thing you could’ve done for ADI.
After 3.0, the question changed: where should AI stop?
With the Mapper shipped, continued design work focused on the boundary between an AI proposal and a human decision. Client feedback raised a related concern: users wanted to know not only what the system mapped, but how confident it was and what that confidence meant.
The aim was to make AI work quick to scan, uncertainty possible to investigate, and errors possible to correct.
The deeper we went, the less “edge case” fit.
Ambiguity appeared in repeated instances, calculations, rollups, missing information, and column operations. Extraction alone could not determine which interpretation was right or what the analyst intended.
For example, “Revenue” could be a duplicate value—or several legitimate period instances. The interaction needed to preserve that distinction, keep each instance traceable to its source, and let the analyst add another when appropriate.
I documented each pattern by tracing where the ambiguity began, the reasoning needed to resolve it, and the interaction decision that followed. Some problems originated earlier in ingestion, so simplifying the Mapper alone would have hidden the symptom without addressing its source.
Keep instances distinct, show their source, and support “Revenue · Add instance.”
Keep contributing values inspectable so analysts can follow the result.
Make gaps and structural changes visible at the point they affect mapping.
The architecture changed. The principles still mattered.
For the next phase, I proposed a data-first architecture. The team later aligned on a table-driven technical direction, changing the structure of the mapping experience. I shifted from proposing how the product should be organized to designing within the system the team had committed to.
The design questions remained: how to present AI output clearly, surface uncertainty, and keep human judgment central. I carried those principles into the new constraint.
Don’t make analysts reconstruct the target list from extracted tables.
A new review surface and technical structure for the work after 3.0.
Make the data item, evidence, and review state understandable together.
Scope note: ADI 3.0 had shipped. The architecture shown here describes the later direction, which was still in design when I moved off the project.
3.0 shipped. The next phase was still in design when I moved off.
The shipped Mapper gave the team a dataset-driven review experience. The continuation explored how to make AI reasoning, uncertainty, and human intervention clearer within a changing architecture.
Structured review connected target data with source evidence.
Research connected user behavior to the architecture proposal and roadmap conversation.
Keep evidence near, surface uncertainty, and spend human attention where judgment matters.
A repeatable way to connect a data problem to a design decision.
The next-phase architecture and review concepts were proposals and explorations; they had not shipped when I moved off the project.
I’d make the reasoning easier to carry forward.
I’d pressure-test the architecture proposal earlier, while the team still had more room to compare directions. I’d also document design decisions and handoff artifacts as the work evolved, so the reasoning was easier for others to build on.
AI can do more of the work.
People still need to see why.
The question became less “What can AI automate?” and more “Where should the system act, where should uncertainty become visible, and where does human judgment add value?”
UX / Product Designer for the Mapper · flow audit and research synthesis · data-first workflow direction · shipped review experience · continued AI-review and architecture explorations · cross-functional product influence
The ADI 3.0 screen shows the shipped Mapper. Other product screens and diagrams are illustrative explorations.