Inspection App
UX Research
Business and problem
The agro inspection app was created in 2019 to support field inspectors during on-site inspections: filling out reports, looking up farm data and accessing policyholder information. The product had been built without any UX involvement, with a technical focus and no consideration for the real working conditions in the field.
The challenge wasn't just improving usability: it was understanding how inspections really happened.
As the operation grew, support tickets rose sharply, a sign that the product had drifted away from the reality of the people using it every day. What was missing was an understanding of where, in practice, it failed the people working in the field.
How I worked on the project
I was responsible for the research and discovery phase, from fieldwork to presenting the findings.
Field research
I ran shadowing sessions with three inspectors in their real context of use: in the crop field, with no internet and the sun glaring on the phone screen, and at the farm headquarters, with internet and in the shade.
Feature mapping
I listed the features that could be added to the app, based on the other apps inspectors were already using to carry out inspections.
Market benchmark
I analyzed competitors and the features they offered, complementing what the fieldwork and the inspectors' own apps showed.
Synthesis
I organized the research insights into a structured backlog of improvements, which was later presented to the project stakeholders.
Technical feasibility
In alignment meetings with the technical team, I discussed the feasibility of the features users requested.
Presentation
I presented the research data to stakeholders and the internal Product team, which opened a strategic discussion on whether to integrate or build the parallel tools.
How I reached the solution
I conducted field research using shadowing and contextual observation, following three inspectors on different days through their real work routines. The field team also included people from the business side and an auditor who oversaw operations, which let me capture different perspectives on the same problems.
What I found was different from what the support reports suggested. The work happened in three distinct, disconnected moments, and inspectors filled the gaps in the app with parallel tools. Four points sum up what I observed:
Field
No connectivity, sun exposure, constant travel and operational pressure.
Farm headquarters
Where reports were filled out, with the client present for real-time validation.
Storage shed
Used for final analysis of harvested crops, in certain types of insurance.
Parallel tools
A satellite GPS to record routes, since there was no internet signal in the fields, and other apps to store what the system couldn't keep offline.
Each extra tool was concrete evidence of a gap the product hadn't yet closed. It was this mapping, and not just the support reports, that gave grounding to the improvement backlog presented to stakeholders.
What was delivered
This project did not involve designing screens or releasing anything to production. The deliverable was a structured backlog of improvements, built from the research insights and presented to stakeholders.
The presentation sparked discussions that went beyond design: the business team asked whether some of the parallel tools inspectors used should be built natively into the product or integrated via API. That conversation, which came directly from the field observations, opened up a strategic direction that wasn't in the original scope of the research.
The main opportunities identified were:
- Offline operation as a requirement, not a differentiator
- Simpler flows for the most repetitive operational tasks
- Better separation of access profiles and visibility of essential information
- Action confirmations at sensitive steps of the process
- Performance improvements to reduce friction during field use
What I learned
This project reinforced something that remote interviews rarely show: the context of use completely transforms the problem.
Watching an inspector use a satellite GPS because the app didn't work without internet was more revealing than any support report. The user had already created the solution: the product just needed to learn from it.
If I were to do it again, I would spend more time on two fronts: deepening the one-on-one conversations with inspectors to understand nuances between different operating profiles, and involving the technical team earlier to discuss the feasibility of the solutions identified, especially the decision between building natively or integrating via API, which would have a direct impact on the product roadmap.
