Greenhouse Banner Photo

Project Greenhouse

Creating affordable "Smart-Home" solutions for agricultural operations

Providing automatic metric testing and data recording allows greenhouse operations to maximize their efficiency and intelligently experiment on future crops.

This is our team's story of how we discovered this emerging market and how we went about designing the product for our users.

Project Summary

Project "Greenhouse" is a digital monitoring system for greenhouse environments. Metrics, such as temperature, pH level and water level, are captured by sensors and transmitted to an online storage system. The real-time metrics can be accessed through computers and mobile devices to help farmers monitor remotely, saving time and resources for the business. This project is still in early development.

Project Dates: May 2018 -> Present

My Role: Lead UX Researcher

As the lead UX researcher, my job was to steer the direction of an idea to a marketable product. I worked closely with the product designer and stakeholders to define our business objectives. Communicating with greenhouse farmers, I was able to create a list of user requirements to fulfill their needs.

Project Goals:

  • Create a product that integrates "smart-home" concepts for an agricultural purpose
  • Develop a software service and hardware product
  • Ability to create this product on a limited budget
  • Produce an MVP to demo to potential clients

What problem does this solve?

Having access to real-time metrics allows business leaders to make informed decisions about how to allocate labor and resources. Offering monthly services (maintenance, data analysis) will allow us to generate revenue after the purchase and implementation of our product.

Why is this project worth doing?

New agricultural markets are emerging across the nation, especially in the organic foods sector. Most farmers do not have access to automated testing for real-time metrics (water level, pH level, light level), and have to check manually and infrequently. Our product looks to improve the information needed to make business decisions and reduce the labor spent monitoring crops.

Is this better than the alternative?

At the moment, our competitors are marketed to large scale operations, but do not have the robust business model to support small-to-medium sized agricultural operations. Our service looks to provide an affordable and elegant solution for small-to-medium sized operations.

Methodology: Discovering the User

Understanding the user was one of the more challenging aspects of this project. When the project was first designed, it was a product that offered a service, but did not have an ideal user base in mind.

Through user interviews with several greenhouse growing operations across multiple states, we we discovered that our initial design was not a good fit for our targeted audience. Our product was complex and powerful, but our demographic didn't have the same grasp of software and statistics to allow an informed business decision.

Sample Greenhouse Questionnaire
Questionnaire for the Greenhouse Project
Our general script and questionnaire sheet when interviewing farmers. Link to a section of the questionnaire (GoogleDocs)

Field studies uncovered that our users spent more time trying to distinguish problematic plants and diagnosing what went wrong. The user would have to spend time testing the pH level, checking the water level, examining for mold or bugs, and finding a solution.

Personas and user profiles were built based on our meetings with greenhouse employees at all levels. We found that there were three primary archetypes of users that would be using our product. Our next challenge was to sit down and evaluate each of the user's requirements and how they evolve with usage of our product.

Greenhouse Personas
Personas for the Greenhouse Project
Above are three personas developed to understand the different types of users that would use our product (GoogleDocs).

After several visits to various greenhouses, our team went back to the drawing board to take what we learned and apply changes to make our software more valuable.

Reinventing the Wheel

Our first meeting after our visits at the greenhouses generated a list of product requirements, both for our project team and what features our potential clients need.

Our list of product features needed to be refined, and a large number of features are to be released in future versions of the product. We narrowed down the number of release features from 9 down to 4.

Requirements and Specifications
Business Requirements:
  • Affordable prototype and MVP
  • Ability to scale with features
  • Sellable product to our intended market
Release Features:
  • Real-time data monitoring
  • Push alerts to warn of data that falls out of range
  • Out-of-the-box functionality (no assembly required)
  • Mobile and Desktop accessibility
Planned Features:
  • Statistical analysis for own ecosystem
  • Statistical analysis for cross-ecosystems for all clients
  • Consultation feature for strategy and future planning
  • Automation for adjsting light levels, pH, so-on
  • AI pattern analysis for suggested optimal growing actions
Above are a simplified requirements and features list for the Greenhouse project.

Once we had our new list of business requirements, our team went back to our potential clients and performed a survey detailing what parts of the business could be improved. With those new suggestions in mind, we went back to our feature list and revised.

Each research iteration helped us understand our user's needs better, and provided the insight on what exactly we needed to build. Of course there are ambitious features we'd like to add, but we now understand that we go to the users first.

What our competitors do right

Discovering the business model for our competitors gave us the opportunity to think about how to generate profit off of our product after selling a tangible object. Our lead competitor sells itemized modules for each sensor, along with services to access the sensor data.

Our initial plan was to sell our sensor package accompanied with our full software service at a fixed price. After understanding how a subscription model would be more profitable, our team decided to look into what solutions we could offer on a monthly basis.

Designing the UI

Our most recent stage is making all of the transmitted data available on a mobile device screen. I started by brainstorming with the team and asking a series of questions:

  • Where are the user's going to use this? In an office setting or inside the greenhouse?
  • What key features are needed upon MVP release?
  • What is the best way to go about visually representing the data?
  • How should we organize the displayed information? By category? By plant location?
  • Which metrics are going to be the most important? How do we allow users to traverse between metrics?
  • How much information is TOO MUCH information? When will the application become too taxed and break?
UI Design Artifact
Personas for the Greenhouse Project
The image above shows some of the UI considerations for the Greenhouse App. Link to a larger canvas showing more design considerations.

At this moment, our team is still making a decision on which user interface style would work best. We are working with stakeholders to answer the questions above and develop an elegant program.

The Next Steps

Since our team has been able to take a strategic approach to discovering our user's needs, we have been having a much easier time bringing our idea to a tangible product. We have changed our process of how we evaluate new features.

Our team is more focused on reaching the goal of an MVP, and less concerned about including all of the desired features that were wanted upon initial release.

Once the MVP is complete and polished, we will be looking to demo our products with certain clients. This will give us even more feedback about how to improve our product for future iterations.