AI-powered data collection
2026
How I designed the steps before full AI Automation
Before you can automate a system, someone has to unify it. Nobody had. I did.
I unified 30+ disconnected tools, designed the human-in-the-loop layer and one structure future automation could actually build on.
Problem area
The first time I sat with a DataOps contractor, she had 6 browser tabs open. She was moving values between them with keyboard shortcuts. No validation. No confirmation. Just copy, paste, switch tab, paste again.
When I asked if she double-checked her entries, she said: "I check if I have time."
She never had time.
The moment I understood what was actually broken
The Challenge
Everyone wanted automation.
No one asked if we had the foundation for it.
30+ tools. 0 common language
"You can't automate chaos. You can't scale what isn't unified. The business was asking for a ceiling, but I realized we were missing the floor."
The moment I understood what was actually broken
The Solution I proposed
Most people waited for better AI. I built what makes AI better.
I proposed Review Mode built into the collection flow. The AI pre-fills. The human reviews.
Pattern 01 — The Inversion
Every tool before this started here — blank table, no context, no errors surfaced. Submit available from the first second.
Pattern 02 — The Sequence
The researcher always knows exactly what's left.
Pattern 04 — Arrival State
The Architecture
A loop that teaches itself to need less of manual work.
Here's what I never said in any meeting: every improvement I made brought the full automation scenario closer. Every schema I standardized, every correction loop I built — all of it was teaching the model to need less human input over time. The researchers who helped me understand this workflow were, in doing so, helping me build the thing that would eventually reduce their role.
I resolved this by being honest. Not in a deck. In individual conversations. I showed them what the AI kept getting wrong. I made the case that their judgment, made systematic, was more valuable than their data entry — that the future version of their job was more interesting than the current one. Some believed me. Some didn't. I still don't know if I was right.
Every resolved error is structured, logged, and fed back into the model.
Researchers wouldn't be replaced. They'd be integrated — their judgment made systematic, at scale, feeding the model that would one day need less of it.
The Complexity
I designed for two states of AI maturity
AI Confidence score determines which mode
Mode When it triggers What the user sees Human role
Review
High confidence, non-sensitive Streamlined queue, AI-resolved items, undo available Spot-check only — minimal friction
Quality Check
Medium confidence, AI flag
raised AI suggestion + confidence rationale + accept/override Confirm or correct — one decision per flag
Edit
Low confidence or sensitive data Full data surface, source docs, AI rationale inline Full ownership — researcher takes
the wheel
Before I touched a single screen, I had to map what "unification" actually required. None of this was in the brief. I found it by asking one question at a time.
AI Confidence score determines which mode
The primary complexity lies in volume and variability of rows, not multi-period comparison
Design should prioritize:
speed
clarity
and low interaction cost per row
Design decision 02
Enforced Quality Check before submission
Business users often sent or approved payments in a hurry. The confirmation page missed key details they didn’t always check, leading to errors and rework. I redesigned it to clearly show account, amount, and recipient, and added a final double-check screen to save time and prevent costly mistakes.
Design decision 01
Three concepts.
Two were wrong for the same reason.
Review Mode had one job: help researchers resolve errors without losing context. That single constraint eliminated two of three directions immediately.
What I Created
4 things I built that will outlast this project.
The Resistance
The hardest work wasn't the data. Five people who thought this was a bad idea.
I expected structural complexity. I didn't expect how much of my energy would go into the people around the work.
Retrospective
The platform that needed
a trust layer became
the company's data spine.
Business owners spent less time managing transfer and felt more confident using mobile banking on the go. The new flow became one of the main reasons users upgraded to premium plans.
“Before the update, I used to double-check every transfer on desktop because I didn’t trust the app. Now it’s the opposite. I send everything from my phone. It’s fast, clear, and I know exactly what’s happening.”
Impact
The last time I watched someone use the platform we shipped,
they had one tab open.
I still think about the contractor who asked if we were going to replace her. The platform made her faster. It also made her more replaceable — which was always the point, even when nobody said it out loud. I made peace with that by believing the honest version of the work is better than the dishonest version. You design for what's coming. You try to make the transition humane. You don't always get to know if you succeeded.
What I'd do differently, and what I'd
defend
End with what this taught you about designing AI-assisted operational systems at scale.
What I'd do differently
Push for structured contractor sessions
earlier — not on the UI, but on where the
confidence threshold actually felt
trustworthy in practice. The threshold was
validated against Data Ops accuracy
numbers. The subjective experience of
"this feels safe enough to auto-process" is
a different question I could have tested
with real users before locking the model.
What I'd defend
Insisting on the undo + re-queue logic
under timeline pressure. It reads like a
nice-to-have. It's the mechanism that
makes the quality model honest — the
system acknowledges when the AI was
wrong, and routes it back to a human,
without breaking the workflow. I'm most
confident about that decision in retrospect.