Overview
My role
My role
My role
Plant Sitter is an automatic plant watering app and system that cares for your plants no matter where you are.
Our app and system can customize the water amount and frequency each plant requires.
UX and Product Designer. Worked in a team of four.
Defining the project
What is the task or
problem?
-
Plants must be taken care of if you decide to travel.
-
Busy lifestyles take a toll on plant health since it is harder to keep track of their watering schedule.
-
Different plants have different watering schedules.
-
Watering devices available now do not have customizable features for plants, nor mobile features.
Who is it for?
The app is for plant owners who need help taking care of their plants while they're away from home.
When do they use it?
The user should be able to manage their plants health while they are away from their home and monitor their plant's health.
Where
do they use it?
The user can use the app wherever they are and the changes are made to their home plants.
DESIGN
Design Goals
The design goals of the Plant Sitter App is to give the users peace of mind especially when they are away from home. Plant Sitter is meant for users who can not afford to pay someone to water their plants and is looking for a budget friendly method. It is also meant for users who struggle with the maintenance required to care for their plants. The application will be easy to use and accessible on any smartphone to give users access to updates when they are on the go.
To design the Hi-Fi prototype of the Plant Sitter application, we had to undergo a multi step design process. To start off, we came together and brainstormed different product ideas. When we came to an agreement, we decided that creating a plant watering application was a better option because it is very unique and would be a high demand product.
As a group, we each made our own sketches of the application. With these sketches we were able to create a design charrette, mood board, personas and scenarios. We then created a mid-fi prototype of the Plant Sitter application and ran usability tests. As a result of these usability tests we received some constructive feedback. This helped us pinpoint areas of improvements in our design prototype and create a Hi-Fi prototype of the Plant Sitter application.
User Persona and Scenario
Patricia
“I want an easy and affordable solution to water my plants while I am away/traveling”
​
Patricia is a 26 year-old living in Houston. She works as a Junior Financial Analyst.
​
Patricia will be in Cancun for vacation for a month with family. She is concerned about privacy and security issues in hiring someone to water her plants.
​
She needs a cost-efficient product that will water her plants while she is away.
John
“My busy schedule makes it difficult for me to keep track of my plant watering schedule”
​
John is a 33-year-old doctor living in California. When he is not saving lives, John enjoys listening to music and art.
​
Due to his busy workload, John cannot take care of his house plants and has gotten rid of all of his dead plants.
​
He wants to purchase new plants but wants to make sure they are taken care of since he struggles to remember to water them.
EMPATHIZE
Mid-Fi Prototype
This page displays when the user decides that they would like to add their plant manually. The user is able to customize the name of the plant and the watering frequency.
This page displays when the user is ready to add a new plant to the Plant sitter application. The user is given the option to add a new plant manually or by search.
Adding plants by search can help beginners, who do not yet know how often their plants need watering.
The user's main page will show all their plants, their watering schedule and when they were last watered.
MID - FI
Usability Testing
User testing was conducted to ensure the application worked well and achieved its goals. Three different tasks were conducted through testing, which were all done on the Plant Sitter Prototype.
The test participants were asked to rate how difficult each task was to accomplish, if they had any troubles, and if they had suggestions for the task.
After completing the user tests, our group gathered the information and discussed test results. We found that all our participants found the application easy to use, and no task was deemed as difficult at all. From this, the team deduced that the prototype was functional and the structure aided in achieving the wanted goals.
Results
Since the structure worked well, we focused our attention on other problems participants found. Some of these were:
Design Changes and Recommendations
A few of the problems that were addressed by the participants were easy to fix since they referred to small mistakes made in the prototype. Some actions that were required by the test tasks, did not work, or did not have the functionality necessary. We fixed these problems on the spot.
The other problems required different sets of recommendations, from which we would decide what the best course of action was.
TESTING
Achievements and Lessons Learnt
One of the realizations we had in the process was utilizing adaptive views on Axure to make our singular app prototype provide views of the watering apparatus. Previously, we had made two separate prototypes. By the stage of our high fidelity prototype, we had integrated and condensed the prototypes into one Axure link. This move was a visual representation of how we envisioned the dual channels would work together: the app would be the fully fleshed controls and customization, with supplementary moderate functionality through the watering device’s touch screen.
Our data during user testing felt a little thin, which suggested that more qualitative, observational data may have been missed in the testing of user task scenarios. While we agree that sometimes there is not much to report on, we had to consider if there was a minimal amount of probing during our questioning as well as reporting that did not cover all details of what occurred during testing. Future tests could utilize recording participants’ tests as a way to review what occurred during the usability test, in case our note-taking falls short or we miss something that happens that is not explicated by the user.
The camera/live photo feature was a lesson in the limitations of prototyping. During the phase of our mid-fidelity prototype, we decided to remove the camera plant identification item from our prototype (and even possibly, the potential product). We did not find a feasible pathway to implement that feature in our prototype in Axure. Additionally, a desktop test of our prototype (which was the format of some of our user tests) would fail to approximate this feature even if it was an integrated browser widget. The move also had us consider whether the plant identification feature may have been an unrealistic, too complex app feature, given that entire apps exist for this sole function.