A precision-irrigation research project at LiteFarm, spanning IoT soil sensors, variable-rate systems, and automated pivots. The evidence overturned a brief that asked for more technology. Led solo, research to delivery.
LiteFarm's Smart Irrigation project arrived with an assumption baked in: farmers needed more technology. IoT soil-moisture sensors, variable-rate irrigation, automated pivots that dose water by the square metre. My brief was to design for that future.
The evidence overturned it. The farmers I interviewed wanted technology that asked less of them.
LiteFarm is an open-source farm management platform that, by the project's own count, is used in 160+ countries. I was the sole designer, covering research, strategy, UI, and delivery alone. Which meant I also had to get fluent, fast, in a precision-agriculture domain no one on the team knew well enough to pressure-test a stakeholder brief against. This is how I did that, and what it changed.
Before I could optimise anything, I had to understand what the job actually was, beyond the job description.
In a fully staffed design org, this work would be distributed across a UX researcher, a product designer, a UI designer, a design strategist, and someone managing the design system and web presence. At LiteFarm, that someone was me.
The full scope included user research and synthesis across multiple farmer segments; market and domain research on emerging agricultural technology; UX strategy and product direction input; journey mapping, wireframing, and prototyping; pixel-perfect UI design and delivery; website design and marketing materials; and close collaboration with developers, product managers, and external stakeholders.
The real risk was doing all of it poorly, moving so fast that the things that matter, the research, the real user needs, the thinking, got skipped in favour of outputs that looked like progress.
I didn't accept that trade-off. Instead, I rebuilt the process.
Before reaching for any tool, AI or otherwise, I mapped where the real friction was.
Three patterns showed up immediately.
Time lost in translation. Raw research data, hours of interview recordings, pages of notes, was sitting too far from the decisions being made. The gap between "we talked to farmers" and "here's what they need" was too wide and too slow.
Domain knowledge gaps creating bottlenecks. Smart Irrigation meant evaluating IoT soil sensors, variable-rate irrigation, and automated pivots, and no one on the team had the technical background to judge what was feasible, what was meaningful, and what was just tech for tech's sake. That gap was slowing everything down.
Cognitive fragmentation. Constantly switching between research mode, strategy mode, and craft mode is expensive. Every context switch costs time and depth. Without a system, the work was reactive.
The answer was to figure out which parts of the process genuinely required human judgment, and which parts could be accelerated without losing quality.
The tools matter less than the method.
The pipeline I built has five stages. Each one is a deliberate decision about where AI amplifies the work, and where I stay fully in control.
When the Smart Irrigation project landed, the brief came with an assumption baked in: farmers needed more technology, from IoT soil-moisture sensors and variable-rate irrigation to automated pivots that dose water by the square metre.
The problem was that no one on the team, including me, knew enough about the domain to pressure-test that assumption. And the stakeholder pressure to move toward advanced precision-ag tech was strong.
I started with domain immersion. Gemini Deep Research gave me a fast, structured understanding of precision irrigation: the sensor hardware, variable-rate and pivot systems, the research directions, the adoption patterns. NotebookLM helped me interrogate technical papers and sensor research in a way that surfaced the real questions underneath the obvious ones.
Then I went into the field, in a structured way.
First, I interviewed researchers and engineers working on smart sensors and precision irrigation, to understand why the field kept pushing for more tech, what they were trying to solve, and what they assumed about the farmers they were designing for.
Then I ran structured interviews with six farmers, translated them, and processed them into a large-scale affinity diagram and a detailed empathy map.
The farmers were not asking for more technology. They were asking for less. More specifically: systems that didn't add to their cognitive load, that worked in low-connectivity environments, that didn't require them to learn a new interface every season, and that didn't assume a level of technical literacy most of them didn't have and didn't want.
The research changed what got built.
Features that had been prioritised based on technical possibility were deprioritised. The product direction shifted from "how do we give farmers more data" to "how do we give farmers clearer decisions." That brief produced a different product.
That shift happened because the research process was rigorous enough to hold up against stakeholder pressure. The affinity diagram and the empathy map were the evidence.
AI is genuinely useful for pattern recognition at scale, for first-pass synthesis, for domain briefings, for drafting documentation, and for cutting the distance between raw data and structured insight.
AI is not useful for deciding what matters, for reading the emotional register of a farmer who's frustrated but polite, for knowing when a design pattern is technically correct but humanly wrong, or for the moment in a stakeholder meeting when the data says one thing and the room wants another, and someone has to hold the line.
Those moments are judgment problems, and judgment is not a feature you can add to a pipeline.
The practice I built at LiteFarm protects the thinking by automating the right things around it.
Research, strategy, UX, UI and delivery, covered alone, with no extra headcount.
20 hours of livestock-study interviews to structured findings. Solo.
Structured interviews for the irrigation research.
The Smart Irrigation research directly changed what got built. Brief shifted from "give farmers more data" to "give farmers clearer decisions." Not faster design, better decisions.
Research, strategy, UX, UI, and delivery were all covered without handing off the responsibility for quality.
20 hours of livestock-study interviews processed into usable findings in under 5 days, with a process I could run again.
Precision irrigation, IoT sensors, and variable-rate systems required deep knowledge fast. The AI-assisted immersion process meant credible interviews with domain researchers within days of first encountering the field.
The Smart Irrigation research directly redirected the product brief.
AI should handle the parts of the process that don't require human judgment, formatting, drafting, first-pass clustering, documentation. The moments that require interpretation, empathy, and argument are yours. Keep them that way.
Domain immersion before interviews is not optional. AI-assisted research briefings compress weeks of background work into days. Show up fluent enough to ask the questions that matter.
The difference between research that changes decisions and research that gets filed is structure. Affinity diagrams, empathy maps, and insight hierarchies are arguments. Build them like you intend to win with them.
Rapid prototyping, emotional nuance, handling stakeholders, and final visual judgment are not AI problems. Treat them like they are, and you will ship the wrong things faster.
So far the pipeline has run with one designer, and carrying it to a team of two, five or twenty is still untested.
The work I do is research-driven and hands-on. I think at the strategy level and stay in the craft. If you're building something that needs both, let's talk.