Background "From Machine to System"
The shift from building a machine to managing how it operates at scale
Kisaan Mittra began with the development of an electric reaper designed for small and marginal farmers. The machine solved a clear physical problem, access to affordable harvesting.
What it exposed was a coordination problem. There was no structured way for farmers to access the machine, and operations relied entirely on phone calls and informal networks.
To address this, a farmer facing booking system was designed, capturing demand and bringing visibility to the request side.
Once a booking is confirmed, coordination shifts entirely to operations, a layer that had no system behind it. Assignments happen over phone calls. Machine status lives in memory. Breakdowns trigger reactive coordination.
The problem is no longer capturing demand. It is executing it reliably. This case study focuses on that layer.
Overview
Kisaan Mittra’s operations layer is a dispatch and monitoring system that manages how harvesting requests are executed on ground. Once a booking is confirmed, the system coordinates operator assignment, machine allocation, job execution, and breakdown response across a geographic zone.
It connects two critical surfaces:
A Field Officer platform that manages assignments, monitors fleet health, and resolves operational events
An Operator mobile app that executes jobs and generates real time state updates from the field
Every action in the field updates a shared job state, replacing phone calls with structured, traceable events.
Timeline
Defined the operational model, designed both platforms, and built the system prototype in 5 weeks.
Background
Operations were previously handled through calls, memory, and informal coordination.
There was no shared system to track jobs, no visibility into fleet activity, and no structured way to respond to failures. As booking volume increased, coordination complexity scaled, but the tools did not.
Research
Operations Breakdown
Even when demand exists, execution fails
The Execution Gap
Execution depends on two roles operating under uncertainty and time pressure.
Field Officer
System Orchestrator
- Assigns operators to confirmed bookings under time constraints
- Manages multiple jobs, locations, and machine states simultaneously
- Relies on fragmented inputs (calls, memory, notes)
- Responsible for maintaining schedule continuity
Operator
Execution Node
- Executes assigned jobs on ground
- Depends entirely on clarity of assignment (location, crop, timing)
- Handles real world disruptions (delays, breakdowns, access issues)
- Updates job status back into the system (or fails to)
The system was defined before any screen was designed.
Most products start with screens. This one started with operations. Before designing interfaces, the system was defined:
What events exist
Who generates them
Who resolves them
This determined the entire structure:
Farmer bookings enter the system, the officer assigns them to operators, and the progress is updated through a shared system state.
State Machine
A structured lifecycle that defines how every job progresses from request to completion.
Before this system, a job had no shared definition. A strict state machine was introduced as the backbone of execution.
Backward transitions blocked by default. Every override is attributed and logged.
Assignment Logic
Evaluates multiple factors to recommend the best operator without exposing complexity.
Assignments are not random and not fully automated. The system evaluates available operators and presents a ranked recommendation, while the final decision stays with the officer.
Behind the UI
Two rules shaped assignment:
Eligible operators are ranked automatically, while the final assignment decision stays with the officer.
Surface UI
The officer sees only the best recommendation and supporting alternatives. The complexity stays in the system, not the interface.
Field deployed pairs take priority over base station. A pair 20km from the next farm is prioritised over a fresh pair 150km away at base unless accumulated workload says otherwise. The 50% distance weight and 20% workload weight together handle this.
Real-time dispatch, fleet monitoring, and field coordination for harvesting operations.
A desktop operational platform built for dispatch officers managing live agricultural field operations. The system supports monitoring, assignment, exception handling, and execution tracking across operators, machines, and active harvest jobs.
The platform is organised into two operational layers: monitoring live system state and resolving assignments, breakdowns, and active operational issues.
Monitoring
Monitoring screens help officers track bookings, machines, operators, and alerts in real time.
Dashboard
The operational command center built to communicate overall system state in under five seconds. It gives officers immediate visibility into active jobs, pending assignments, fleet availability, and emerging issues across the network.
Suggestion card is preview only
Assignments require entering the Assignment Overlay.
Slower dispatch, fewer blind assignments.
Persistent alert tray
Alerts accumulate instead of interrupting active workflows.
Fewer interruptions, lower forced visibility.
Booking Queue
The operational ledger that surfaces every booking across assignment, execution, and completion states. It enables officers to scan system health, trace booking history, and move quickly between jobs without breaking review context.
Slide in detail panel
Booking details open in a side panel instead of a separate page.
Faster sequential review, lower detail immersion.
Fleet Monitor
The real time health view of the electric fleet across geography. It shifts attention from operator activity to machine condition, allowing officers to detect strain early and intervene before minor stress becomes field failure.
Machine first organisation
The monitor is structured around machines instead of operators.
Less people centric visibility, clearer asset accountability.
Ampere as primary health signal
Real time current draw is surfaced with color coded thresholds to indicate strain before failure.
More complex telemetry model, earlier intervention capability.
Alerts
The structured incident surface where the system shows what it knows before the officer decides what to do. Built to surface causal context, machine detail, and a system generated recommendation in one read.
Combined event timeline
System events and operator reported events appear in the same chronological sequence.
Mixes sources with different reliability, exposes causal gaps that separate logs would hide.
Recommended Action
Every recommendation carries a confidence label and a one line rationale.
Risks over reliance on High Confidence suggestions, gives officers a defensible starting point.
Decision
Interfaces built for assignment, escalation, and operational intervention under time pressure.
Assignment
The highest stakes decision surface in the system. This overlay forces the officer to encounter complete booking context, operator comparison, and SLA pressure before committing to an assignment.
Three operators only
Only three ranked operators are shown. No scrolling or expanded shortlist.
Reduces visibility of the full pool, prevents analysis paralysis during dispatch.
Score labels over numeric scores
Operators are labeled Best Match, Fastest, and Low Workload instead of showing raw scores.
Less scoring precision, faster comparison under pressure.
Alert
The incident response surface. This overlay presents complete context before action what failed, when it failed, and what the system recommends so the officer acts with clarity, not urgency alone.
Radius defines viable coverage
The map ring shows which operators can realistically reach the farm within the remaining slot time.
Simplifies real travel complexity, speeds up replacement decisions.
Recommended action stays advisory
Operators are labeled Best Match, Fastest, and Low Workload instead of showing raw scores.
Less scoring precision, faster comparison under pressure.
Job Detail
A real time job inspection and intervention surface. It enables officers to assess whether work is progressing as expected, contact the operator or farmer directly, and escalate only when necessary.
Field coverage over elapsed time
Progress is measured through harvested acreage and completion percentage instead of slot time alone.
Depends on live telemetry accuracy, but gives officers a measurable completion signal instead of unreliable time estimates.
Escalation separated from quick actions
Calling the operator or farmer is prioritised before escalation actions are surfaced.
Adds friction during urgent failures, reinforces escalation as a deliberate last step instead of a first reaction.
Mobile workflow for operators managing active harvest jobs in the field.
A mobile execution workflow built for field operators performing live agricultural harvest jobs across navigation, harvesting, payment, and issue reporting.
The application guides operators through fixed operational states from assignment to job completion.
Edge Cases
Issue reporting branches out from the active job flow when field execution is interrupted by machine or operational problems.
Testing and Validation
Tested with the people who run the operation under real pressure.
Operational structure replaced fragmented coordination.
Core decisions that shaped how the system behaves under real operational conditions.
How the project evolved from interface design into operational systems thinking.
Designing Kisaan Mittra changed how I approached product design. What initially started as a workflow and interface problem gradually became a systems problem centered around operational states, assignment logic, breakdown handling, and execution continuity under real world constraints.
As the platform evolved, many assumptions changed through testing and scenario walkthroughs. Several interaction models had to be simplified, restructured, or removed entirely once the operational behavior became clearer. The following reflections capture the parts of the system that became difficult, the assumptions that failed, and the decisions that ultimately shaped the final product.
Where the complexity actually was
Operational systems became more difficult than interface design.
The complexity of the project shifted from screens into defining how assignments, operational states, failures, and escalations behave under real execution constraints.
Assumptions that changed during the project
Several interaction models became unnecessary once the operational logic was defined.
Early workflows included machine selection during dispatch, assuming officers would manually choose operator machine combinations during assignment.
What testing exposed
Scenario based walkthroughs revealed gaps that static interfaces could not.
Several operational issues only surfaced once workflows were tested as connected execution states instead of individual screens.
What the project became
The system evolved from interface design into operational state design.
The project gradually shifted away from designing screens toward defining how events, responsibilities, and system states interact across live field operations.
