Helping Farmers Make Better Decisions — a Case Study

Farming isn’t easy. It takes months to determine whether the effort invested to harvest a good yield was worthwhile. Farmers devote countless amount of hours into working their land, even when it means that they may be missing out on their niece’s wedding or granddaughter’s 3rd birthday.

With such a small amount of the world’s population involved in farming, it’s crucial that a farmer’s yield is optimized to keep up with the demands of a growing population. How do we tackle this issue? That’s a problem that my team and I set out to tackle.

The Problem

Here are some of a farmer’s current pain points:

  1. Not enough real-time knowledge about their fields at all times.
  2. Not a lot of money to shed on the latest technology.
  3. Even with access to technology (a rare few), they aren’t able to extrapolate key insights from the data collected from their farm.

Our biggest design challenge was to figure out a way to make our solution affordable for farmers to use in their day-to-day lives, so we tasked ourselves with developing a product that would cost farmers the bare minimum.


To design an effective solution for farmers who would be using our product on a daily basis, each of us had to be honest about the challenges and our weaknesses:

SWOT Analysis (S — Strengths, W — Weaknesses, O — Opportunities, T — Threats)

Being a university project, there were a number of challenges the team had to overcome and ensure the project’s success:

  1. The team consisted of 7 members — which meant that every key decision had to be unanimously agreed upon by each member.
  2. Juggling course-work and project deliverable’s through the school year was one of the biggest challenges, as the deliverables accounted for a huge chunk of the grade.
  3. Being university students, each one of us had other extra-curricular commitments to attend to.

The Solution

A system that would help a farmer make timely decisions by keeping them updated about their farms.

To tackle this problem, we decided to adopt Scrum as a framework to help us tackle problems systematically. We chose Design Thinking as an approach to develop a deep and holistic understanding of our users, so we could help identify simple alternatives to the current products in the market.

My Role

My primary role in the project’s design phase was to lead the efforts of the EDC (Environment Data Collection) team, details of which I will divulge in later during the study.

I was also part of the UI/UX team — and my role was to convert low-fidelity wireframes into a fully functional prototype.

The Process

Although the entire project (including development) spanned a total of 24 weeks, I’m only going to be showcasing the design phase of our project which lasted for half the period. It was essential that we had a working prototype by the end of those 12 weeks, to prove to ourselves and the course instructor that our product was:

  1. Desirable (satisfies the user’s current need)
  2. Feasible (technologically possible)
  3. Viable (economically possible — under the budget of $750)

Empathize, Define (Weeks 1–6)

Techniques/Tools utilized overview:
User Personas, User Interviews, S.M.A.R.T Framework, K.I.S.S. (Keep it Simple Stupid)

To effectively empathize with the users, research was conducted by consulting with experts from the Precision Farming industry, scouring research papers online and analyzing the current products in the market. We also reached out to the Ontario Federation of Agriculture, Canadian Federation of Agriculture and AgriFood Canada for insights on the current situation in farming.

Through research, some of the user’s pain points were identified:

User Persona
User Pain Points

Having identified the user’s pain points, there was still a sense of ambiguity about what we were supposed to do. What exactly is the farmer looking for? Will our product be able to survive extreme outdoor conditions? These are just a few of the many questions that began to surface once we dove deep into the nitty-gritty of our research.

To make things simpler, we decided to adopt the S.M.A.R.T Framework to identify what we wanted out of our product. Our goals were formulated by answering a set of questions for each aspect of the framework:

S (Specific) — What exactly does the farmer want out of the product?

M (Measurable) — How do we know that our product works the way we want it to?

A (Actionable) — How do we increase the farmer’s engagement with the product?

R (Realistic) — What can we realistically accomplish?

T (Time-based) — How long would it take to accomplish each goal?

At the end of the day, we weren’t striving for perfection. Someone once told that me if I ever come across a design’s that’s perfect, chances are it was a result of a poor design process. Good design implies achieving goals within a given set of constraints, and there’s always going to be constraints. Time was our biggest constraint, so we had to be honest with ourselves about what can we realistically achieve within the allotted time frame while managing expectations.

“If you ever come across a system that’s perfect, chances are it was a result of a poor design process.”

The result of implementing the framework produced the following goals, and helped define the problem while keeping the end-user’s needs in mind:

1. Collect, validate and tabulate relevant agricultural data for the farmer.

2. Allow Remote Data Access.

3. Accurately detect the number of pests in a given partition.

4. Minimize end-user cost.

Ideate, Prototype (Weeks 7–10)

Techniques/Tools overview:
Wireframing, What-How-Why Framework, (UI Prototyping)

Once we had identified our goals, we started to distill the goals identified into objectives. I’ve never really known the difference between goals and objectives until I came across this phase of the project — but in a nutshell, goals are an abstract version of objectives. Objectives should be much more specific and precise, whereas goals help us set a general direction.

“Goals without objectives can never be achieved while objectives without goals will never get you to where you want to be. ”

We used the What-How-Why framework to construct objectives for the identified goals. It was essential to figure out the why’s, how’s and what’s early on in our process to the best of our ability, so we wouldn’t have to make major revisions down the road.

Brainstorming session in progress.
Brainstorming session in progress.

To manage expectations and stay within our budget, we decided to rule out Pest Detection even though it was a recurring theme among experts during the research phase. The conclusion we came to was that it would be time-consuming — a lot of man-hours would have to be invested to achieve this goal.

Having identified our objectives, we decided to group together our findings and divide our system into sub-systems.

Iteration 1 — System divided into 6 sub-systems

After another iteration, we divided the system into 7 sub-systems instead of 6.

Final Design — System divided into 7 sub-systems

The system were divided into the following sub-systems:


The Power Sub-system was to provide a ‘field node’ with consistent power supply till the first frost in the year, which in agriculture is defined as the growing season.


Chassis sub-system — Initial Concept

The Chassis Sub-system was to house all the major components of the system that would be on the farm during the growing season, and provide sufficient protection for components vital for the system’s overall operation.

Environment Data Collection (EDC)

EDC sub-system concept. Center— Raspberry Pi Zero ; Around — Sensors measuring different variables

The EDC Sub-system was to collect data from the environment. The variables we decided to update the farmer on are: Soil Temperature, Soil Moisture, Wind Speed, Air Temperature , Humidity, Location and uV Radiation.

The core component of the EDC Sub-system was the Raspberry Pi Zero (picture in the image above), which allowed us to easily implement a local database and interface with multiple sensors measuring data in the field.

Communication (COM)

COM sub-system concept — EDC 1 and EDC 2 are simply two nodes on a farm, communicating the data collected to the HUB.

A core part of the entire system, the COM Sub-system was responsible for communicating data from the field to the farmer.

Key Components: Low cost NRF24L01 transceivers, existing open-source libraries that help interface Raspbian (Raspberry Pi Operating System) with the transceivers.


Hub sub-system

The HUB Sub-system was to store the received data locally until an internet connection to the server was successful. This allowed our system to be robust and efficient, as the data collected would not be lost during worst-case scenarios.


SERVER sub-system

The SERVER was the intermediary between the field and the User Interface (UI).

User Interface (UI)

The User Interface (UI) was designed to be responsive to ensure that the farmer could access the website from their mobile phone, tablet or desktop computer and still have access to all the data they desire.

Early sketches — User Interface
Early sketches — User Interface

The wireframes were soon converted into a high-fidelity prototype using

Login Page — UI Web Prototype
Dashboard — UI Web Prototype
Maps — UI Web Prototype
Insights — UI Web Prototype

Evaluate (Weeks 11–14)

Techniques/Tools overview:
Usability Testing

During the year, we collaborated with the McMaster Museum of Art to test an early prototype of the system. Turns out, the museum needed help in monitoring the temperature and humidity levels in their vaults which housed paintings worth millions of dollars. This was the perfect opportunity for our team to test our system and also contribute to the art community in the process.

We installed our system in areas of the museum that needed monitoring and also conducted usability tests with museum personnel who would be using our application. It was in testing for a period of 3 weeks.

Museum Implementation

Final Product

Final Product — AgriBoost
Final Product — Responsive User Interface


At the end of the school year, all groups were asked to present their projects to a panel of experts from the industry. Each group would present their project for 20 minutes, and the top 3 ideas would be chosen by the end of the day.

I’m grateful and fortunate enough to say that our project won the top prize! It was a great feeling to see the team’s hard work pay off. After the win, our project had started to get attention from people outside the Department of Computing and Software .

Various articles posted across social media reflecting our joint work with the McMaster Museum of Art.

Lessons Learned

Here are some of my insights from our journey:

Better User Testing/Evaluation

Due to time constraints and overhead costs, we weren’t able to conduct usability tests and contextual inquiries with our primary market (farmers) — so we tested our product with members of the Art Preservation community for a limited time.

A bulk of our user research was conducted by reading research papers, browsing the internet and organizing conference calls with experts from the industry.

I believe that a lot more could’ve been learnt about farmers and their current situation by physically immersing ourselves in similar conditions.

A group of 7 people is a LOT

We had one of the biggest groups in class, and were warned about how tricky it could get during the course of the project. And sure enough, it did.

More people usually means less work for the each of us, but that also means more debate about each design decision. The debates turned out to be time-consuming and effortfull, I remember walking out of each meeting drained out of energy. But in hindsight, it was vital to our project’s success.

By engaging in debates, we discouraged the common phenomenon of Groupthink to seep in by valuing each member’s opinions equally. The more we talked about each decision, the clearer our concepts got by the end of each meeting.

It was an experience that all of us valued greatly since we were all graduating soon, and about to step into the real world where teams can get a lot more trickier!


Testing our prototype with the museum opened up a whole new potential market for our product. This meant that it wouldn’t be just the art community that could use our product, but even other indoor facilities that needed environment monitoring could benefit greatly.


Left to Right: Vishal Bhatia, Gary Barretto, Gino Salayo, Chrisite Condron, Pareek Ravi, Kunal Shah, Pavithran Pathmarajah.

Gary Barretto led the efforts of the HUB team.

Christie Condron played the role of scrum-master, and also led the efforts of the CHASSIS team.

Pavithran Pathmarajah led the efforts of the SERVER team.

Pareek Ravi led the efforts of the COM team.

Gino Salayo led the efforts of the POWER team.

Kunal Shah led the efforts of the UI team.

A BIG thank you to Dr. Michael Noseworthy and the McMaster Museum of Art for their continued support throughout the course of the project.

Thank You!

This is my first article on Medium and I’m also currently pursuing UX Design at the Interaction Design Foundation. Having recently completed multiple courses in UX, I was fortunate enough to get the amazing opportunity to work with a project like this!

I hope you liked it, this is also my first UX Case Study so please feel free to leave your thoughts and reviews in the comments below! Have a wonderful day :)




I love reading about people building stuff

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Heuristics: Beyond Nielsen and the other guy

Scratching the Surface Why Testing on Mobile is Different

Modern houses are the worst things to come out of the 21st century.

A Simple UX Process To Deliver And Maintain Better UX

The Orbit — UX Case Study

Hindrances for Quality Technical Documents

How to Make Animated Videos, The Ultimate Guide

8 Skills They Don’t Teach You at Design School

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Vishal Bhatia

Vishal Bhatia

I love reading about people building stuff

More from Medium

UX Design Case Study: Steams Store Page

A Beginner’s Guide to Product Design Ft. Matt Wilson

How to make self-learning in your team fun? Let’s explore Service Design!

Good Design or Fit Design?