Introduction - System Overview & Supporting Research
After several stages of ideation and conducting thorough research via qualitative 1:1 interviews, photo study, secondary research, guerilla interviews and user enactments, we have created Plants That Talk, a system for communicating crop health, anthropomorphizing the health of a users garden and informing the user what steps they need to take to have an optimally healthy garden.
What's included in the system?
- A central hub that will collect information from individual satellites
- Individual satellites will be included in Plants That Talk seed packages (purchasable online or through Home & Garden stores)
- An application that will serve as a presentation and interactive layer for conveying information about the garden to the user
- An online community page similar to https://www.thingiverse.com/ or other analogous sites where users can share information about their gardens, set ups and receive assistance as necessary
Why this system?
Prior to the creation of this system, the design team conducted a multi-faceted formative study aimed at uncovering who the target audience is and what the needs are of a targetted user. Furthermore, research conducted was centered around the following facets:
After exploring these questions, we discovered that our users expressed the following:
Values:
Motivations:
Constraints:
As such, our primary goals in developing a system included:
Additionally, our design motivations are as follows:
- uncovering the values of gardeners
- understanding motivations
- knowing what a day-in-the-life of a garden entails
- Identify contrainsts and threats facing gardeners
- identifying the bounderies probable users have with automation, information overload and level of detail vs abstractness of information
- Whether users would want direct notifications or want information that is available to check
After exploring these questions, we discovered that our users expressed the following:
Values:
- Ownership
- Being green
- Aesthetically pleasing
- Social sharing
- Nostalgia
- Relaxation
- Developing expertise
Motivations:
- Utilize space for productive purposes
- Connect to nature
- Hobby/passion
- Gardening as a time for personal reflection
- Practicing self-sustainability, environmentalism
Constraints:
- Time
- Budget
- Lack of expertise/knowledge
- Self-doubt
As such, our primary goals in developing a system included:
- Useful and usable - people want to spend their time gardening, not setting up overly complicated systems
- Have a system that talks to the user. As multiple interviewees expressed, "I wish my plants could talk to me to tell me what they need"
- Empower the user and help them transition from amateur to expert gardeners
Additionally, our design motivations are as follows:
- reinforce user values
- reassure unsure gardeners
- inspire and empower gardeners
- reduce learning curve for first-time gardeners
- installation should feel like gardening
How does Plants That Talk meet goals formulated through research?
- Anthropomorphed representations of the crops a user has planted helps engineer and strengthen emotional attachment to the garden (connection to nature)
- System of information gathering and communication allows plants to talk to their gardeners
- Unobtrusive design and no/low automation allows users to do the work themselves, only armed with more knowledge of what work should be done
- Helps engineer confidence that gardeners are taking the approriate actions necessary to care for their garden
Who would use this product?
Amateur gardeners with small plots of land (community garden, front/back yard).
This system would not be used for commercial or large-scale purposes and is not intended to scale up to that level.
This system would not be used for commercial or large-scale purposes and is not intended to scale up to that level.
System Concept
Plants That Talk, an integrated system that communicates the needs of the garden to the gardener, engineering ownership, self-sustainability and facilitating a connection to nature.
System includes:
Main design feautres:
System includes:
- a central communications hub
- individual measurement satellites
- a smartphone application
Main design feautres:
- measures and communicates vital information regarding crop health
- plug and play system that is flexible for any garden or situation
- anthropomorphizes plant information to engineer connection and empathy
- provides contextual tips, empowering the user and engineering expertise
Goals For The Demo
For our demo, we are hoping to:
- Communicate the simplicity of the design
- Demonstrate how we can measure soil (specifically hydration) and transmit that data into an application
- Show how the animations of the app respond to real-time data
- Articulate how this system can be utilized in a realistic use case
The Demo
Materials Used:
Satellite
Small pots with soil
Laptop
Video that shows how the anthropomorphic crops respond to changes in hydration
High-level description of the script:
Explain the interface
Walk through a use case:
In the event all else fails, we can still manually manipulate the interface and rely on a Wizard of Oz demonstration technique.
If the battery fails we created a backup where we can power the device through microUSB connection.
Time permitting can show how the communication system works through a Wizard of Oz manual demonstration within Framer and lastly, explain other user cases and applications that our system can engage.
An explanation of how the demo did or did not capture key elements of the intended experience:
Captured:
The key design feature - having a garden that talks to its user - is accounted for and the primary focus of the demonstration.
Articulating how the various components work in concert together is authentically captured in the demo, meaning the product works without the need for faking it.
We were able to get the satelitte working and is capable of reading moisture and light levels, uploading that to Firebase and then our Framer-built application is able to pull that data down and approriately display the correct information to our user.
Use case of the gardener being away from home and having his buddy perform the work necessary to keep his garden healthy while away.
Not captured:
We had explored the idea of having some level of automated water for edge cases where users were away from their garden (e.g., on vacation, working late, etc.); however, this element was not captured in our prototype or demo.
We were unable to get the hub working and that part is instead communicated through Wizard of Oz approach.
Lastly, we had explored the idea of an ambient light system in the event that a user would not want to use the app; however, this aspect was not constructed nor demoed.
Any feedback or insights that came out of preparing the demo:
The primary insight that came out of preparing the demonstration was how expensive pH sensors are as they currently exist on the market. Though our system accounts for this, we realized it was something we would have to use Wizard of Oz prototyping in order to communicate.
We learned that our system works on an 8 second cycle, so that our system is nearly in real-time.
Unfortunatley our temperature and humidity sensor was damaged and was not included in the demo; however, this is an important finding as it informed us that the casing housing these comopnents needed to be stronger than originally estimated.
Once we got the system working and had met the criteria of our MVP, we started to brainstorm about additional features that could be included in this system that would also align with our goals and user values, such as leveraging weather APIs that would send notifications to the user in the event there was going to be a frost, rainfall, etc. so that they would know whether or not to cover their crops or whether they would have to manually water or let nature do that for them.
Satellite
- Particle Photon
- Enclosure
- Fabrication & Circuit Design
- Soil Moisture Sensor
- Temperature/Humidity Sensor
- Ambient Light Sensors
- 400 mAh Rechargeable Battery
- Enclosure, Fabrication & Circuit Design
Small pots with soil
Laptop
Video that shows how the anthropomorphic crops respond to changes in hydration
High-level description of the script:
Explain the interface
Walk through a use case:
- Scenario where gardener goes on vacation
- User wonders how their plants are doing
- User checks application and sees that their carrots need watering
- User calls a friend and asks them to water the plant
- Friend asks where the carrots are
- The user tells their friend where the carrots are located in the garden
- Friend confirms that he watered the plants
- User checks app, sees that his plants are happy and thanks their friend
In the event all else fails, we can still manually manipulate the interface and rely on a Wizard of Oz demonstration technique.
If the battery fails we created a backup where we can power the device through microUSB connection.
Time permitting can show how the communication system works through a Wizard of Oz manual demonstration within Framer and lastly, explain other user cases and applications that our system can engage.
An explanation of how the demo did or did not capture key elements of the intended experience:
Captured:
The key design feature - having a garden that talks to its user - is accounted for and the primary focus of the demonstration.
Articulating how the various components work in concert together is authentically captured in the demo, meaning the product works without the need for faking it.
We were able to get the satelitte working and is capable of reading moisture and light levels, uploading that to Firebase and then our Framer-built application is able to pull that data down and approriately display the correct information to our user.
Use case of the gardener being away from home and having his buddy perform the work necessary to keep his garden healthy while away.
Not captured:
We had explored the idea of having some level of automated water for edge cases where users were away from their garden (e.g., on vacation, working late, etc.); however, this element was not captured in our prototype or demo.
We were unable to get the hub working and that part is instead communicated through Wizard of Oz approach.
Lastly, we had explored the idea of an ambient light system in the event that a user would not want to use the app; however, this aspect was not constructed nor demoed.
Any feedback or insights that came out of preparing the demo:
The primary insight that came out of preparing the demonstration was how expensive pH sensors are as they currently exist on the market. Though our system accounts for this, we realized it was something we would have to use Wizard of Oz prototyping in order to communicate.
We learned that our system works on an 8 second cycle, so that our system is nearly in real-time.
Unfortunatley our temperature and humidity sensor was damaged and was not included in the demo; however, this is an important finding as it informed us that the casing housing these comopnents needed to be stronger than originally estimated.
Once we got the system working and had met the criteria of our MVP, we started to brainstorm about additional features that could be included in this system that would also align with our goals and user values, such as leveraging weather APIs that would send notifications to the user in the event there was going to be a frost, rainfall, etc. so that they would know whether or not to cover their crops or whether they would have to manually water or let nature do that for them.
Prototyping Process
Our high level process was as follows:
- Identify and purchase necessary components
- Assemble components
- Ensure assembled components can communicate with Firebase database
- Sketch out wireframes based on user feedback and research
- Create wireframes for how the app should look and feel within Axure
- Import wireframes into Framer and create additional stylings and animation
- Feed data from product into the Framer interactive prototype
Whiteboard Sketches:
Axure Wireframes:
Animating in Framer:
Data feeds from Firebase to Framer:
Building the Hardware:
Creating a backup microUSB connection in the event that the battery failed:
Finished prototype: