Cambridge Field Tracker

I was working as a Research Assistant on the Smart Food Cities project at Anglia Ruskin University. The research team needed to physically distribute adverts and invitations for an essential survey to food businesses across Cambridge.

The work involved visiting businesses, leaving materials, recording what happened at each visit, returning to businesses when asked, and keeping a sense of overall progress across the campaign.

The operational problem appeared during delivery of the research itself. There was no practical way to see which businesses had already been visited, what happened at each visit, which ones still needed a return or follow-up, and how much of the Cambridge dataset had been covered.

This was not a generic CRM problem. It was a field-operations problem, and the research workflow needed a tool built around how the work is actually done on the street.

• Support a known dataset of 597 Cambridge food businesses.
• Let a field researcher find a business quickly by name, street or postcode.
• Record a delivery outcome immediately, at the door.
• Distinguish pending, delivered, refused, return, closed and follow-up states.
• Reduce duplicate visits and forgotten follow-ups.
• Support navigation and directions while moving between businesses.
• Show progress across the whole fieldwork campaign.
• Remain useful when mobile connectivity was unreliable.

The product had a narrow, well-understood user base — which made it possible to design for the session rather than for a persona.

• Primary — research assistant or field researcher carrying out the physical distribution.
• Primary — research team members reviewing campaign progress.
• Stakeholder — the Smart Food Cities research team and Anglia Ruskin University researchers.
• Stakeholder — Cambridge food businesses receiving the survey advert or invitation.

This was firsthand discovery rather than hypothetical user research. I was one of the people doing the field activity, so I experienced the coordination gap directly rather than hearing about it second-hand.

I designed the product around the actual sequence of work: what you need to know before leaving, what you need at the door, and what has to be captured before you walk to the next address.

Almost every meaningful decision in this product came from the physical conditions of the work rather than from a feature wish list.

Each decision below is paired with the reasoning behind it, because in an internal tool the rationale is the product.

Distribution was already underway, so the first version had to be genuinely useful immediately. I drew a hard boundary around what the first version had to do and what it deliberately did not need to do.

I identified the workflow problem through the research work itself, defined the field states, search behaviour, progress model and interaction flow, then used Lovable to accelerate implementation.

I tested the product against the actual 597-business field dataset and iterated around how the tool needed to work during physical visits.

AI accelerated implementation; it did not replace product ownership. The problem framing, status model, scope boundary and field testing were mine, and the corrections that mattered most were the ones that came from using the tool while walking.

Described conceptually — this is the product architecture as I designed it, with implementation specifics flagged where they still need confirming against the current codebase.

The evidence here is qualitative and operational. I am deliberately not claiming quantitative outcomes I have not yet measured.

• The tool originated from a real research-delivery problem, not a portfolio exercise.
• It was built for a live Cambridge fieldwork dataset of 597 food businesses.
• The workflow and statuses reflect delivery outcomes actually encountered or anticipated during field activity.
• It provided a single place to see campaign progress and the state of individual businesses.

What this project demanded of me as a product person, rather than what the product contains.

Internal tools create value by reducing cognitive load and closing coordination gaps, not by having lots of features.

Status design matters because each status implies a different next action. 'Return' and 'refused' are not variations of the same thing.

Offline capability is a product requirement, not a technical nicety, when the environment makes connectivity uncertain.

When you are also the user, firsthand insight is powerful — but it still has to be separated from assumptions about other users.

The best MVP was not route optimisation. It was making field state visible and reliable first.

The natural next phase is moving from a single-researcher field aid to a coordinated, measurable team tool.