Most agritech personas reduce a smallholder farmer to a literacy percentage and a regional language, then design around both as limitations to accommodate. The sturdier approach treats voice input, icon-first navigation, vernacular content, and offline resilience as the baseline design brief, not accessibility add-ons, because for the majority of the world's farmers that is simply how a phone gets used.
Quick answer: Build personas around what a farmer is trying to accomplish in a given week of the season, not around a literacy label. Make voice, icons, vernacular text, and offline mode the default interface — and test each of those choices with real usage before shipping it as fact.
Why Literacy, Language, and Low-End Phones Are the Median User, Not an Edge Case
Treating low literacy, non-dominant languages, and patchy connectivity as "edge cases" inverts the actual population you are shipping to. Across the smallholder geographies most agritech products target — South Asia, Sub-Saharan Africa, Southeast Asia, Latin America — these three conditions describe the typical user, not the outlier one your design has to route around.
The scale here is not a rounding error. The UN Food and Agriculture Organization and the World Bank have both used estimates in the range of roughly 500 million smallholder farms worldwide, producing a large share of the food consumed in low- and middle-income countries. UNESCO's literacy estimates consistently show adult literacy gaps concentrated in rural areas and skewed toward women — the same demographic that often manages home-plot decisions and household purchasing.
Connectivity tells the same story. GSMA's State of Mobile Internet Connectivity research has repeatedly documented that smartphone ownership and mobile internet use lag well behind mobile ownership in rural low- and middle-income regions, with a persistent gender gap in smartphone access. ITU connectivity data shows a similar pattern: rural areas trail urban ones on both device quality and network reliability, often by a wide margin.
| Design assumption | What agritech PMs often build for | What the underlying data actually supports |
|---|---|---|
| Literacy | Full-text menus, forms, and reports | Meaningful shares of rural adults in target geographies read with difficulty or not at all (UNESCO) |
| Device | Smartphone-first, app-store distribution | Feature phones and shared/low-end smartphones remain common; data plans are rationed (GSMA) |
| Language | One national or "official" language | Dozens of spoken vernaculars per country, often undocumented in text-to-speech engines |
| Connectivity | Always-on 4G/5G assumption | Rural network reliability lags urban by a wide margin, with frequent dead zones (ITU) |
Read plainly, that table says the "constrained" user is the modal user. A persona built on a literate, smartphone-native, single-language, always-connected default will misrepresent most of the people who actually pick up the product. For the broader context on why agritech products behave differently from generic consumer apps, see this complete guide to agritech product management.
The literacy spectrum is not binary
"Low literacy" is not one bucket. A farmer might read numerals fluently (prices, dates, quantities) while struggling with dense paragraphs, or read a local script but not the Latin-alphabet English used in an app's settings menu. Functional literacy in one context (reading a seed packet) does not transfer automatically to a different one (parsing a dashboard's navigation).
Designing for this spectrum means testing comprehension at the level of icons, numerals, colors, and short phrases separately, rather than assuming a single literacy score predicts performance across an entire interface.
Building a Jobs-to-Be-Done Persona Template That Replaces Demographic Stereotypes
A demographic persona ("Ramesh, 42, owns 2 acres, limited education") tells you almost nothing actionable about interface design. A JTBD-based persona instead documents what the farmer is trying to accomplish, under what constraints, and what "done" looks like — which is exactly what interface, language, and channel decisions should be built against.
Tony Ulwick's Outcome-Driven Innovation work, which formalized jobs-to-be-done into scorable "desired outcome" statements, is the clearest starting point. Rather than asking who the user is, it asks what job they are hiring the product to do, and scores each desired outcome by importance versus current satisfaction — the gap is the opportunity.
The template
Structure each persona as a job record, not a bio. A usable version has six fields:
- Core job — the functional task in the farmer's own words ("decide whether to spray today").
- Situational context — season stage, crop, plot size, and who else is involved in the decision (spouse, hired labor, input dealer).
- Forces of progress — the push (a visible pest), the pull (a neighbor's better yield), the anxiety (wasting a spray on the wrong pest), and the habit (asking the local dealer first).
- Constraints — literacy level for numerals vs. text, primary spoken language and script, device type, typical data budget, and network reliability at the plot.
- Success metric, in the farmer's terms — not an app metric like "session length," but "I sprayed once, correctly, and it worked."
- Current workaround — what the farmer does today without your product: asking the input dealer, calling a relative, guessing.
| Field | Demographic persona (avoid) | JTBD persona (use) |
|---|---|---|
| Framing | "Low-literacy female farmer, 38" | "Deciding whether to spray, under time pressure, with no confirmed diagnosis" |
| Constraint | "Can't read well" | "Reads numerals reliably; struggles with paragraph-length text; understands spoken Marathi, not Hindi" |
| Success | "Uses the app weekly" | "Reaches a spray/no-spray decision she trusts within one day of noticing damage" |
| Design implication | Simplify the text | Replace the text step with an icon + voice confirmation, and test whether both are needed |
This is also where the Ulwick opportunity score (importance plus the gap to satisfaction) earns its keep: it tells you which job to redesign first, instead of redesigning every screen on a hunch. Prodinja's Customer Jobs tool builds personas this exact way — jobs-to-be-done statements scored with Ulwick opportunity scoring and Forces of Progress — so the output is a ranked list of underserved jobs and real constraints, rather than a demographic sketch dressed up as a persona. For the full method behind this structure, this complete guide to jobs-to-be-done is a useful companion.
Mapping a Season: A Customer Journey Emotion-Curve Exercise
A farmer's relationship with an agritech product is not flat across the year; it spikes and dips with the crop calendar. Mapping an emotion curve across one full season — plotting anxiety and confidence stage by stage — surfaces exactly when a text-heavy interface will fail and when a voice or icon shortcut earns disproportionate trust.
Run this as a structured exercise, not a brainstorm. Interview or shadow farmers through at least one full cropping cycle, or reconstruct it retrospectively stage by stage, and score each stage on two axes: anxiety (uncertainty, financial exposure, time pressure) and confidence (trust in their own judgment and in available information).
The five-stage curve
| Season stage | Typical emotional state | Dominant information need | Design implication |
|---|---|---|---|
| Pre-season planning | Moderate anxiety, low confidence (credit, input choice) | "What should I plant, and can I afford it?" | Simple comparisons; voice-guided input cost estimates |
| Sowing & input purchase | High anxiety (money committed) | "Am I buying the right input at a fair price?" | Icon-based product ID; price transparency, minimal text |
| Mid-season stress | Peak anxiety (pest, weather, disease risk) | "Is this normal, and what do I do right now?" | Fast, low-literacy diagnosis path; urgent, short voice alerts |
| Harvest | Rising confidence, moderate anxiety (timing, labor) | "Is it time, and where do I sell?" | Simple yes/no decision aids; local price/voice updates |
| Post-harvest & sale | Confidence peak or sharp anxiety (price realized) | "Did I do well, and what do I change next time?" | Plain-language recap; light-touch reflection, not new tasks |
The mid-season stress point is where most text-heavy tools lose farmers entirely — it is also the highest-anxiety, lowest-patience moment in the whole curve, which is exactly the wrong time to ask someone to read three paragraphs. Products that instead compress that moment into a photo, a tap, or a ten-second voice note earn outsized trust relative to their actual feature scope.
This exercise pairs directly with seasonality-aware product planning — a curve like this only means something if your release rhythm matches the calendar it describes, which is the subject of this piece on seasonality and agritech product rhythm. For the general mapping method behind the curve itself, see this complete guide to customer journey mapping.
From Text-Heavy Dashboard to Voice-First, Icon-Driven Flow: A Concrete Redesign
Take a common agritech screen — a crop advisory dashboard listing weather, market prices, and pest alerts as stacked text cards — and the failure mode is obvious in hindsight: it assumes reading is the fastest path to a decision. For most of the emotion curve above, it is not. It is often the slowest.
The original design
- A scrollable list of text cards: "Weather: 32°C, 40% chance of rain," "Market price: tomato ₹18/kg," "Pest alert: fall armyworm reported in your district."
- A settings menu in one national language, with a language toggle buried three taps deep.
- Text-based push notifications requiring the app to be opened and read in full.
The redesigned flow
- Crop-stage icon strip at the top — a row of icons (seedling, flowering, harvest sack) with the current stage highlighted, tappable to hear a short voice summary in the farmer's chosen dialect, not just national language.
- Color-and-icon severity system for alerts — a red pest icon with a single spoken sentence ("Armyworm seen nearby — check your leaves today") replaces a text paragraph, echoing the kind of lightweight, photo-triggered diagnosis discussed in this feasibility look at AI crop disease detection.
- Tap-to-call and tap-to-voice-note as first-class actions, not fallback options buried under a text search bar.
- Numeral-forward price display — large digits for the price itself, with a single icon (rupee/naira/peso symbol plus up/down arrow) instead of a sentence describing the trend.
- Everything cached for offline replay — the voice summary and icon state load once online and remain available without a live connection, since a spotty network at the exact moment of decision is the norm, not the exception; this is the same design posture covered in this guide to offline-first design for agritech connectivity.
Assumptions that must be tested, not asserted
A redesign like this looks obviously better on a slide. It is still full of unverified assumptions, and each one can fail in a specific, testable way:
- Icon comprehension without labels — a pest-severity icon that seems intuitive to a designer may be ambiguous to a farmer who has never seen that visual grammar before; test recognition rate before trusting it.
- Voice message length and pacing — a ten-second note may retain attention where a thirty-second one does not; measure completion, not just playback starts.
- Dialect vs. standardized language — a voice engine trained on the "official" language of a state or country may still miss the spoken dialect farmers actually use at home.
- Trust in a synthetic voice vs. a known human voice — some pilots on agricultural advisory find farmers trust a recognizable local extension worker's recorded voice more than a generic text-to-speech voice; do not assume either wins by default.
- Offline cache staleness — a cached price or alert that is a day old can be actively misleading during the mid-season stress stage; decide explicitly how staleness is communicated, not just tolerated.
Each of these is a hypothesis, not a finding — the honest version of this redesign ships with a plan to test all five, not a claim that they are already true.
Designing the Baseline: Voice, Icons, Vernacular, and Offline by Default
Treat these four as the starting interface, not a fallback mode toggled on for "low-literacy users." Nielsen Norman Group's research on designing for low-literacy audiences has long argued that simplification benefits nearly all users, not just the least literate segment — a finding that generalizes cleanly to rural agritech, where even literate farmers prefer the faster channel under time pressure.
Two existing programs are worth studying as reference points, not as products to copy wholesale:
- Digital Green, a nonprofit operating across South Asia and Sub-Saharan Africa, has built its agricultural extension model around locally-produced video featuring farmers the audience recognizes, explicitly designed around low literacy rather than working around it.
- Voice-based advisory efforts, including IVR-driven programs studied by organizations like Precision Development (PxD), have shown that a phone call or voice message can reach farmers that a text-based app or SMS service cannot, particularly feature-phone users with no app-store access at all.
CGAP's human-centered design work on financial inclusion for low-literacy, low-income users offers a parallel lesson from adjacent fintech: the interfaces that stick are the ones that mirror an existing mental model (a paper ledger, a known voice, a familiar icon) rather than importing a smartphone-native pattern language wholesale.
A short checklist for the baseline
- Voice: every critical action has a voice equivalent, not a "listen" button bolted onto a text screen.
- Icons: tested for recognition, not just aesthetic clarity, with a fallback label for the minority who prefer text.
- Vernacular: matched to spoken dialect, not just the nearest official language, with local recording where synthetic voice trust is unproven.
- Offline: core information — prices, alerts, the last advisory — cached and usable with zero live connection.
None of this replaces field validation. It sets the default you validate from, rather than the accommodation you bolt on after a literate-user-first design fails in the field.
Key Takeaways
- Literacy, language, and connectivity gaps describe the median smallholder user, not an edge case — UNESCO, GSMA, and ITU data all point the same direction.
- Build personas around jobs, not demographics — a
JTBDstructure documenting the core job, forces of progress, and constraints predicts interface decisions far better than a bio. - Score jobs with an
Ulwick opportunity score(importance plus the satisfaction gap) to prioritize which underserved job to redesign first. - Map the emotion curve across a full season — mid-season stress is typically the highest-anxiety, lowest-patience moment, and the place text-heavy tools fail hardest.
- Redesign the interface, not just the copy — voice, icons, numerals, and offline caching should be the default flow, with text as the fallback for users who prefer it.
- Every redesign choice is a hypothesis — icon comprehension, voice length, dialect accuracy, voice trust, and cache staleness all need field testing before they're treated as settled.
- Reference programs like Digital Green and PxD's IVR work show these patterns succeeding at scale in comparable geographies, without claiming any single blueprint transfers unchanged.
Frequently Asked Questions
How do you design UX for low-literacy users in agritech?
Design voice, icons, and numerals as the primary interface, with text as a secondary option, rather than simplifying text as the main fix. Test icon comprehension and voice message length directly with farmers, since assumptions about what reads as "obvious" frequently fail in the field.
What is a jobs-to-be-done persona, and why use it for smallholder farmers?
A JTBD persona documents the functional job a farmer is trying to get done — like deciding whether to spray — along with the situational forces, constraints, and success definition around it. It replaces demographic labels with actionable design inputs, which is why it fits smallholder contexts better than a standard bio-style persona.
Should agritech apps support voice input and output by default?
Yes, for most smallholder-facing products, voice should be a first-class channel rather than an accessibility add-on, given documented literacy and language gaps in rural populations (UNESCO, GSMA). Whether synthetic or human-recorded voice performs better is a local question to test, not a default assumption.
How many languages or dialects should a smallholder product support?
Support the spoken dialects farmers actually use at home, not just the official state or national language, since the two frequently diverge. Start with the one or two dialects covering your largest user segment, validate comprehension, then expand rather than launching a long language list unevenly tested.
Is offline-first design necessary for rural agritech products?
In most rural geographies targeted by agritech, yes — network reliability lags urban areas significantly (ITU), and the moments farmers most need information, like mid-season pest pressure, often coincide with poor connectivity. Caching core content for offline use should be treated as core functionality, not a resilience feature added later.