Building Shamba-MedCare AI app for Real Users

Source: Dev.to

The Users I’m Actually Building For

Here’s the uncomfortable truth about my target users:

This isn’t edge‑case accessibility. This is the use case: a 55‑year‑old farmer with reading glasses she can’t find, soil under her fingernails, standing in bright sunlight with one bar of signal. She’s who needs this app most.

So I built the accessibility system around her, not around developers reviewing my code.

The Voice Button That Changed Everything

The single most impactful feature I built was embarrassingly simple: a button that reads the diagnosis/results aloud.

I used the Web Speech API, which is built into every modern browser. The implementation took maybe an hour, but the impact was huge. The voice doesn’t just help users who can’t read; it helps everyone.

My mom, who reads perfectly well, said hearing “Your tomato has early blight. This is a fungal disease. Severity is moderate” felt more trustworthy than reading the same words—like getting advice from a person instead of a screen.

The voice script matters too. I don’t just dump the JSON response into speech; I write it conversationally:

“Your tomato leaf has a health score of 45 out of 100. I detected Early Blight, which is a fungal disease. The severity is moderate. For treatment, you can use neem oil spray, mix two tablespoons with one liter of water, and spray every seven days.”

Pauses between sections, specific measurements, no jargon. The AI generates this because I asked it to in the prompt: “provide practical, actionable treatment steps that farmers can follow.”

Font Scaling Without Breaking Everything

The accessibility settings panel lets users choose font sizes: Normal, Large, or Extra Large. Sounds trivial, but the implementation taught me a lot about CSS architecture.

I changed the font size on the document root element. Every component using rem units automatically scales—no prop drilling, no context providers. One line of JavaScript, and the entire app responds.

The trick is building components with rem from day one. If you’ve hard‑coded pixel values everywhere, retrofitting accessibility becomes a rewrite. I got lucky: Tailwind’s default classes use rem, so most of my UI scaled correctly without changes.

Settings persist in localStorage, so a farmer who needs large fonts doesn’t have to re‑enable them every session.

Touch Targets for Rough Hands

Apple recommends a 44 px minimum for touch targets; I went bigger.

Why? I watched my uncle try to use a banking app. His fingers are thick from decades of farm work, and he kept hitting the wrong buttons—not because he’s clumsy, but because the app was designed by someone with smooth developer hands typing on a MacBook.

My button sizes:

• Standard buttons: 48 px minimum height
• Primary actions (e.g., “Analyze”): 56 px minimum
• Bottom navigation: 64 px minimum

The bottom navigation placement matters too. Thumbs naturally rest at the bottom of the phone. Putting the main navigation there enables true one‑handed use, even though web convention often places navigation at the top.

Color That Works Without Reading

The health score uses a five‑color severity system:

A user can glance at the color and know how worried to be—no reading required. The traffic‑light metaphor is universal: green means go, red means stop.

I chose these specific colors for three reasons:

• Color‑blind‑safe progression – Luminance decreases from green to red, so severity is readable without color perception.
• Sunlight visibility – High‑saturation colors remain distinguishable in bright outdoor light; pastels wash out.
• Cultural familiarity – Traffic lights exist everywhere, making the metaphor instantly understandable.

Progressive Disclosure

A full diagnosis from Claude contains 25+ fields: disease name, scientific name, confidence score, symptoms, causes, spread risk, urgency, treatments with ingredients and preparation steps, prevention tips, regional availability notes, and more.

Showing all of that at once would overwhelm anyone, especially someone who struggles with text‑heavy interfaces.