Harvest to hand
Farmers Market Mobile Application
American National Insurance
Goals
- Redesign the existing Harvest to Hand app to appeal to user needs
- Promote markets and vendors that partner with American National
- Create an environment that promotes markets and vendors.
- Highlight vendors and markets by promoting unique recipes.
- Ensure that the app works the same regardless of market
Original Version
- Primarily a market finding service that was dependent upon market managers signing up online.
- Markets were divided by categories, though many categories were offered at a single market.
Discovery
Competitive Landscape
A majority of the competitor market applications were either other market finding applications, or were geared towards providing detailed information on certain kinds of products, such as pesticide contamination.
User Research
We conducted several user interviews and performed informal contextual research. Our research concluded that there are not different user types, but different scenarios. Users tended to vary between these different scenarios depending on their location, the types of available markets, their personal lives, the season, their method of transportation, and their available time.
Scenario 1: Day trips to the market
Scheduled trip to a favorite market, usually with a lot of options.
Scenario 2: Lunch break trips
Quick trips to a nearby market, often within a specific time range.
Scenario 3: Spontaneous walk-by
Unintended trip, often during nice weather seasons, and with users without time constraints.
Scenario 4: Foodie’s regular grocery trip
Regular trips for those concerned with organics and pesticides, or who have favorite vendors.
Proposal
We matched the research with our technical capabilities, timeline, and client desirables to define the core capabilities of the new app:
Core Capabilities
- Recipe database & custom creation
- Vendor inventory
- Shopping lists
- Updating Schedules
- In-App Notifications
Userflows
User type:
Shopper vs Non-Shopper
As we developed the application and did additional research, we realized that there are no distinguishable types within the shopper user audience—users that go to markets to browse or shop.
We determined that we had to design for the non-shopper users, specifically the market managers and market vendors.
In order to ensure that the information in the app updates for the shoppers, there needed to be a portal where the market vendors or managers could control content.
User type:
Market Manager
& Vendors
The challenge was to balance the requirements needed by the vendor or manager with their busy day-to-day activities when at a market. When asked, some vendors said that they would delete an app if it required too much time to figure out or took away from time engaging with customers.
Most of our designs were made so that users could set up information before market day, and engage minimally day-of.
Vendors and market manager were broken into separate users because:
- Vendors go to several markets in one week
- Market managers typically only manage one market
Design
Low Fidelity
After the discovery process, we did several paper iterations to refine our user flows.
Find Vendors selling ingredients in a recipe
A user finds a recipe she likes and wants to see if she can get ingredients from any vendors at her current market.
Example
1. User taps on a recipe image to drive to the individual recipe page
2. User taps on ingredient to show vendor drop-down
3. User taps on vendor to show that vendor’s profile page
Testing API functionality - Vendor Check-In
We also used paper prototypes to test out how APIs would be called from various parts of the app.
Example
In order for a user to add “eggs” from a recipe to her shopping list and then find vendors selling “eggs,” the recipe API, the vendors’ inventory database, and the shopping list database all have to pull ingredients from the same database. The vendors selling “eggs” also have to be present at a market and have “eggs” in stock.
This led to the “Check In” functionality (shown below), in which a vendor does not appear as selling an item at a market unless they are scheduled to be at that market, or have manually checked-in to that market.
1. Vendor taps on “Check In” from home screen and gets a confirmation modal.
2. Modal prompts vendor to check inventory for the market he/she just checked in at.
3. Vendor can rapidly toggle items as in or out of stock by tapping on the item’s image.
Content Categorization & Database Iterations
Inventory Syncing
In order to keep the app in sync despite these differences, we ended up thinking about item categorization the same way nature does--by species. The database will store and call an item by:
- its “species” value (its standard name, like “apple”),
- any optional subspecies value (any standard variety, like “Macintosh”),
- store any unique varietal information (like “Grandpa Bob’s”) as supplementary information.
As a result, a vendor can have unique varieties and still pop up in shopping lists and recipes that call for that item.
Manipulating Item Database & Creating Varietal Options
When a vendor adds an item to her inventory, she is first forced to search for the item.
If the item does not exist in the database, like a non-food based item, she can add a completely new item.
If the item already exists in the database, the vendor selects that item and is taken to a screen where she can add any variety information to it; the rest of that item’s information is locked.
Keeping Clean Data
While we were hesitant to remove users’ control over their items, we also recognized that this system would solve for several other problems, all of which would be frustrating for shoppers to navigate, and detrimental to the vendors whose mislabeled items are not being promoted. These problems included:
- duplicates
- misspellings
- poor photography
- single vs plural
Consistency vs Vendor IP
We also chose to tie a vendor’s varietal information to the vendor herself, instead of adding that variety to the larger database. Not only does this keep the database clean, it also protects the vendor’s proprietary information.
From here, we were able to craft a database that played nicely with our recipe API and keyword search functionality.
Vendor: Searching database for an item & adding to their inventory.
Mid-Fidelity
Template Consistency & Testing
Given the size of the application and our short time line, we endeavored to ensure that most of the pages contained similar elements or layouts (templates).
This also improved usability as well, as the users we tested on were able to quickly determine where information was based on where it was located on the screen. We were also able to test designs on native mobile screens.
Shopper screens.
High Fidelity
Our graphic designer created style tiles during the low-fidelity parts of the design phase, and applied them to the mid fidelity wireframes as they were finalized.
Testing
Unfortunately, the time line and budget did not give us adequate time to fully test out our application with a significant level of rigor. Many user flow errors were revisited and discussed during development, and changes were made as needed.
Many of these changes were also the result of changing technical requirements, including where the user-generated content will be stored, such as the custom recipes and inventory items, or how well the keyword search actually works.