Guiding Better Field Execution

Business Context

InfoQuest is an enterprise retail intelligence platform: brands commission field research, and Research Associates collect that data inside stores as client-specific jobs called Quests. Every Quest has its own instructions and success criteria - and completing the work isn't enough. The quality of the data depends on understanding exactly what the client expected to be captured.

The Challenge

Build an internal Learning Management System.

That was the request - and it seemed straightforward. But the business already had one: a third-party platform, desktop-only, disconnected from the field application. The real problem wasn't a missing product; it was guidance living outside the workflow where Research Associates actually work:

• Training was skipped or delayed before unfamiliar Quests
• Client-specific expectations were harder to reference when work began
• Inconsistent execution led to poor-quality data, rework, and client dissatisfaction

What looked like a product request was a workflow problem - and understanding that distinction became the turning point of the project.

Discovery

The brief: replace the third-party LMS with an internal one. Before designing anything, I mapped the existing training workflow with the Product Manager, Business Analyst, Engineering team, and Field Operations Managers - and kept asking one question:

Why does this training exist in the first place?

The answer reframed everything. Research Associates weren't training to learn their jobs - they were preparing for client-specific Quests. The platform wasn't failing because it lacked learning features; it was failing because guidance was disconnected from the work itself.

The Shift in Perspective

"Build an LMS" carries assumptions - courses, assessments, certificates, pass percentages. None of them addressed the actual need: preparing someone for unfamiliar work. The question changed:

How do we deliver the right guidance at the exact moment someone is about to perform unfamiliar work?

Once reframed, certifications, pass thresholds, and training expiry were deprioritized. Every decision was measured against a simpler principle:

Will this help a Research Associate perform their next Quest with greater confidence?

"Designing the Right Product"

The reframed problem changed what we needed to build: not a traditional LMS, but operational guidance delivered at the moment of need. Three decisions shaped the MVP.

The first: the business wasn't trying to evaluate Research Associates - it needed to reduce uncertainty before someone entered the field. So training became an operational guidance experience rather than an assessment tool: certifications, pass thresholds, and training expiry were intentionally excluded, while instructional videos, contextual questions, and reinforcing feedback stayed.

The result measures nothing and prepares everything.

Managers author guidance on the web; Research Associates consume it on mobile, moments before a Quest. Designed independently, they'd become two disconnected products - so I built them as one ecosystem: a single content model and information architecture, where everything created on the web translates into the mobile experience without duplicated effort.

Discovery surfaced a much larger vision - Quest-based assignments, workflow enforcement, dashboards - and the real challenge was deciding what the first release needed to prove. The MVP covers creating, publishing, and delivering guidance inside the existing field workflow; everything else was deferred.

Even small wins were cut. Video thumbnails in the training library were a nice idea that added effort without serving the core objective - and protecting the clarity of the first release mattered more than scope.