Published on | Prototyping: From UX to Front End — Medium Bella Margolles

What if I told you that you could grow a garden from the comfort of your own kitchen?

The AVA Byte is an automated, indoor smart garden capable of year-round plant growth. It uses soil-free, compostable pods to grow a wide range of edible plants like herbs, microgreens, mushrooms, etc.

It’s been likened to a Nespresso machine, but for plant growing, with it’s focus on pods and it’s sleek, beautiful design. Through it’s use of hydroponics (growing plants without soil), the AVA Byte boasts high-speed plant growth and pesticide-free food ingredients for consumers.

Overall, a pretty exciting product. Take a look at their promo video to get a visual sense of what the AVA Byte has to offer:

<a href="https://medium.com/media/f5b282c0c2d3381dc813287b426d0a01/href">https://medium.com/media/f5b282c0c2d3381dc813287b426d0a01/href</a>

01_Project Overview

The Opportunity

AVA Byte is the brain child of Valerie Song and Chase Ando, who envision hydroponic gardens as the future of sustainable urban living, and one solution to depleting resources consumed by a rapidly growing population.

The AVA Byte was successfully funded by backers on Indiegogo who share this same vision and interest, and is set for delivery by early 2018.

Project Goal

The team at AVA tasked us with designing a mobile application that would enable AVA users to monitor and control the growth of their plants. Additionally, as UX/UI Designers, we needed to ensure that the resulting design was directly informed by our users’ goals.

Business Goals

Within the scope of this project, success to Team AVA meant designing an app that:

features user-friendly control and monitoring capabilities to encourage use of the AVA + app
includes page that allow users to purchase more pods
motivate users to share their experiences with the product via an in-app community page

Design Team

Our design team consisted of two User Experience designers (including myself), and one User Interface designer.

Timeline

Our project timeline was roughly three weeks from the first meeting with our clients to the day we presented our design.

Three week crunch

It was a tight squeeze to go from initial user research to a high fidelity prototype within that time period, but we did it! Let’s delve deeper into the processes and tools we used to make this all possible.

02_Research

Competitive Analysis

We took a look at apps that AVA’s direct competitors had put out, taking into account features they included, how they organized flow and information, and the user interface.

The Click & Grow had quite a simple interface, with good visual cues and functionality.

The Click & Grow App

The Aerogarden app was not visually appealing, but gave us ideas for potential features and how to intuitively organize information.

The Aerogarden App

We also looked at another smart monitoring app, the Fitbit, to see how they presented data and organized controls.

Next, we wanted to get in contact with potential users to gain insight into their experiences and motivations related to growing plants.

Interviews

We interviewed a total of 9 people, screening candidates by asking whether they were interested in growing their own food plants. Included in that number were four interviewees who our client connected us with, who had either backed the AVA Byte on Indiegogo or had expressed interest in hydroponic gardening.

We asked demographic questions, asked about expectations for app features, and explored their motivations for growing food indoors and growing plants in general.

Surveys

We sent our surveys out to two different groups: Confirmed AVA Byte backers, and regular plant growers. We split the surveys up because:

1.) Certain questions asked in the Backers survey were quite specific to the product, so we needed to cater those questions to our potential audience, and

2.) While taking data from a larger sample size would yield a fairer representation of responses, in the case of split or conflicting results, we would put more weight to data from Backers, as they are users that had already purchased the product.

Our surveys contained exploratory questions similar to what we asked in our interviews, with a more quantitative approach.

Findings

Overall, our data came from 9 interviews and 122 survey results.

Visual representation of our data collection: 9 interviews, 53 non-backer surveys, 69 backer surveys.

We found interviews to be the most useful tool in getting qualitative data related to users’ emotional response and internal/external motivations for growing their own food. One user stated this:

“I really enjoy the process of seeing my plants grow. It’s exciting to wait for that moment when the plant is finally ready to harvest”

This was a recurring finding amongst both interview and survey results. The great perk of conducting face-to-face interviews was that we were able to recognize aspects of plant growth / the product / the technology that users were particularly passionate about. Emotional reactions aren’t as easily discerned through surveys.

To get a better sense of our data, we first constructed an affinity diagram.

The affinity diagram helped us eliminate any useless data, and group together results to infer patterns and meaningful information.

Key Findings

Experience

Users self-identify as “Average Joes/Janes” in the gardening department

Although the product is marketed to “plant killers,” we found that people interested in the AVA Byte rated themselves as average to below average in gardening skill.

Motivations

Users have similar motivations for growing their own plants

We asked users what they found most interesting about growing their own plants. We purposely formatted response type for this question as short answer because we suspected that trends would emerge, and we wanted to categorize that qualitative data ourselves to get a better feel of our users’ motivations.

Sure enough, Sense of Accomplishment, Health, and Teaching & Learning (in no particular order) emerged as leading motivators for growing your own plants. Some other people cited aspects related to convenience, but that category wasn’t as prominent.

Interestingly, when looking into the same question posed to non-backers, respondents rated Aesthetic / decoration as the second highest motivator for growing their own plants. This interesting split between backers / non-backers demonstrates why we thought it was important to put more weight on backer survey data, as we were more interested in knowing what actual buyers of the product saw as a priority.

We also asked users what got them interested in using the AVA Byte, here are their top responses:

This confirmed that users are mostly interested in using the AVA Byte for growing ingredients to cook with. Furthermore, we found that they’re particularly interested in growing their own herbs.

Herbs, victorious!

Expectations for App

Users expect the app to deliver on it’s basic premise (monitor and control settings), and directly aid their plant growth efforts

Practical Users want basic capabilities to help them succeed

Most users expected a dashboard with basic capabilities that AVA had promised in their promotional efforts. The fact that they also valued plant growth recipes, a store page, and a user guide shows that users wanted guidance in using their AVA to grow plants, and a way to sustain their use of the AVA Byte long-term.

Web Habits

Our users prefer Facebook.

2. Our users predominantly use the iPhone.

03_Planning

From conducting our research, we were able to identify our user problem, and propose a solution to that problem.

The Problem

Users need a reliable tool to monitor plant settings on their AVA Byte so that their plants will thrive with minimal effort

The Solution

Develop a mobile application that will allow users to monitor the plants in their AVA Byte closely

Design Implications

All the data we collected from interviews and surveys affected design decisions we made while conceptualizing the initial wireframes.

We decided to build our app on iPhone mobile platform, as most users were accustomed to iPhone’s design and usability.
We decided that, for the scope of this project, our efforts would be best directed in developing a robust dashboard that addressed all user needs for control and monitoring capabilities. Although we had some ideas for a prospective community page and profile page, we identified the dashboard as our MVP, namely the minimum viable product we could design to meet the users’ greatest need within the mobile app.
The data we accumulated directly informed how we crafted our user persona.

User Persona

Our user persona took the form of David Bauer, a married Software Developer in his early 30’s who is motivated to grow and cook with fresh ingredients all year round, despite his busy schedule.

Creating a persona was very helpful in helping us make design decisions. Whenever in doubt, we would try to view the problem from David’s perspective to get a sense of whether a feature was necessary, whether a motivation was not aligned, whether level of tech proficiency needed to be assessed, etc. It’s important to note that since David is a product of all our data, his goals, motivations, and frustrations reflect that of all our users in general.

We also noted a secondary persona that emerged from our research:

Tanya shares a lot of similarities to David, but is more prone to experimenting with her plants’ growth. Tanya is even more interested in the science behind plant growth, and under what specific conditions different plants thrive.

It’s important to note that the Tanya persona motivated us to explore user customization of the app controls; even though David is more cautious, over time he may gain enough confidence to fiddle around with controls, much like Tanya.

User Story

Placing our persona, David, into a user story helped us visualize his user problem more effectively and convey his emotional response to that problem more strongly.

David is at work and thinking about what to cook for dinner for himself and and his wife. He remembers seeing a recipe for a great basil pesto pasta that he wants to try out. He knows he’s growing basil in his AVA Byte, and suddenly remembers it’s been quite a while since he last filled the AVA Byte with water. He opens the app on his iPhone to check the water level. The dashboard shows that the water level is still good and he doesn’t have to refill the water for another few days.

Storyboard

We created a storyboard to convey emotion within the user story and encourage us to empathize with the user’s problem.

David is always on the go, good thing his AVA Byte keeps in touch.

Feature Prioritization

With all this new data to play around with, it was easy to get caught up in all the features we wanted to add to the app. However, due to the limited time we had, and to avoid Scope Creep (AKA having our scope get out of hand due to not having clearly defined it from the start), we worked on a list of “Must Have” features, “Nice to Have” features, and features that were “Not Needed.”

One other useful method we used to focus our scope was by charting features by impact and effort. We categorized app features by “High Impact, Low Effort,” “High Impact, High Effort,” “Low Impact, Low Effort,” and “Low Impact, High Effort.”

This helped map out features to work on first (easy features with high impact), which features to spend the bulk of our energies on (high impact features that were difficult to design), and assess whether we would have the time to design simple, low impact features.

User Flow

Once we had a better grasp of which features we were including in our app, we created a user flow to demonstrate the step-by-step process a user would take within the app.

We included an Account set-up stage to facilitate connecting the AVA Byte to WiFi and to the mobile app, and we created user on-boarding so that first time users would have complete understanding of how the controls work.

Here is a a close-up of our main user flow, which is the user interacting with the dashboard capabilities. We added customization features to address the needs of our secondary persona, Tina the Tinkerer, who would be more

Additionally, we added an alternate user flow (see grey boxes) to show how the user would interact with the app months later when he needed to replace his pods.

Site Map

We created a site map to organize the different pages and subpages that would live within our app.

Site Maps are very handy in getting a grasp of an app’s overall information architecture

04_Design & 05_Testing

Once we knew what information we wanted to include in the app, and how to structure that information, it was time to start experimenting with the look of the dashboard.

Sketches

We used the “Design Challenge” method to get our ideas flowing quickly. We spent 5 minutes quickly sketching out as many designs as possible, 2 minutes afterwards explaining our designs to our teammates, and 2 more minutes after that critiquing each others’ designs, explaining what we liked and didn’t like, and what we wanted to incorporate into our own design as it evolved.

We did 4 rounds total of design challenge (2 with just UX Designers, and 2 more together with our UI Designer). It such a helpful tool for pumping out ideas quickly without getting too attached, and getting inspired by each others’ designs. We also drew inspiration from our clients’ existing dashboard concept, which featured a visual of the AVA Byte and different control buttons.

Design Challenge sketchesMore Design Challenge sketches

Low Fidelity Wireframes + Prototyping + Testing

After sketching out our ideas for the dashboard, we started sketching out wireframes.

DashboardWater controlsCustomization option

We loaded these initial wireframes to Marvel to create a low-fidelity prototype.

We tested this prototype on a few people, just to get a sense of what pages were missing in our flow, whether the dashboard was user-friendly, and to determine if the dashboard interactions were intuitive.

Testing our low-fidelity prototype

From our user testing, we discovered that we needed to:

Improve hierarchy of information to distinguish clickable versus non-clickable information
Create additional on-boarding pages to clarify dashboard control capabilities to new users

Additionally, we decided to move our default options checkbox from the bottom of our pop-up to the top, as users didn’t find it intuitive to de-select the default box before editing the controls.

Needed to change placement of that checkbox

The most useful part of creating this low-fidelity prototype was that it took very little time to create, and started the ball rolling on improvements and new ideas for our design.

Mid Fidelity Wireframes + Prototyping + Testing

We took the data from our first round of testing and created a mid-fidelity prototype on InVision.

We then performed our second round of testing, and discovered that:

Users wanted the option to log in via Google+ or Facebook

Carousel menu helped users understand purpose of “My Pods” page

Layout of “My Pods” screen looked like an e-commerce store, we changed navigation of pods to carousel menu to clarify
We originally used breadcrumbs for keeping track of progress in on-boarding; users thought it was indication of page being swipe-able so we changed breadcrumb visual from dots to bars

We also found that users still weren’t opting to click on the default checkbox, so we opted to change this to a toggle option. User testing proved the toggle option to be a success, so we stuck with it!

High Fidelity Prototype

After all our iterations of the design, our UI Designer applied the style elements he had been working on to create a high-fidelity prototype. Again, note that our user flow mainly focuses on dashboard capabilities, but we did include some static pages for “community,” “profile,” and “store” to show basic ideas of what could still be developed.

The Evolution of our design (light control page)

06_Future Considerations

We presented our design to the client, and they were very happy with our user research and design recommendations. We all threw out ideas for what else could be included in future iterations, such as the ability to add more than one AVA Byte to the app, using a rewards system for sharing and buying others’ plant growth recipes, and content for a potential user guide.

AVA Byte: Creating a Mobile App for an Indoor Smart Garden was originally published in prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

AVA Byte: Creating a Mobile App for an Indoor Smart Garden

Top Stories