Food management system

I joined the project 4 months in, so the feature backlog had already been established.

Because research took place 4 months late, its purpose shifted from open-ended exploration to confirmation.

The purpose of the trip was to better understand the environment in which our application would be used, validate assumptions we had made so far, and pivot on any features that needed changing.It wasn't an ideal situation - but better late than never! My design lead, the Engagement Manager, and one of our clients visited 3 organizations to observe their processes and current usage of the legacy system.

After my design lead returned from the site visits, I took 2 weeks to sift through all the notes, build out a wiki-style report with quotes and pictures, and condense that report into a PowerPoint presentation for the client. Below are some of the most important insights we confirmed and learned about the shopping experience.

Flexibility

Participating organizations use two different methods for checkout: manual and store concept. At manual locations, program staff step through each food category and enter the units selected manually. In the grocery store model, a customer shops in a warehouse, following an approved grocery list, and a staff member checks them out using a barcode scanner.

Environment

Users have to constantly shift their focus between the physical shopping cart, customer, screen, barcode scanner, etc. Additionally, some stores don't have much, if any counter space, which makes using the mouse very undesirable. Checkout is a high pressure situation - staff members are trying to get through each customer's order as quickly as possible

User Error

It's easy to make mistakes in this rapid-fire environment. Users may encounter several possible errors - some people would rather avoid them, while some prefer to cause them and get feedback. The current system uses audio cues (buzz/beep) to indicate errors when checking out.

Tech Literacy

This is an enterprise application - our users have different levels of computer proficiency. They are used to a function key based navigation legacy system; moving to point & click alone will be jarring.

Connectivity

Some organizations have unreliable internet access and some have none at all. A primary purpose of the mobile app is to support those groups with an offline mode. This capability brings a host of technical challenges surrounding data syncing and validity.

My main considerations when approaching the POS design were as follows:

I started by sketching out a variety of ideas; these were the top four.

We moved forward with option 4 — the drawers. Visually, it felt the most balanced, and the first two graphical options wouldn't have been as feasible to implement because Salesforce doesn't support those types of progress bar components.

How it works

Users see an expandable, scrollable menu listing the total limit, selected, and remaining for each category and sub-category. Remaining is highlighted in the badge component as this is the most important piece of data for a user to see quickly. These limits are inherently hierarchical (Category > Sub Category > Product), with different limits at each level. For example, Juice nests under Fruit, which nests under Fruits & Vegetables. We align with this mental model by visually indenting sub-categories when the accordion is expanded.

Why it Works

This combined navigation and status component provides consistent visibility into customer limits and current status. Users can choose to scroll through the entire list, or move category-by-category. The accordion component accommodates the data - there are at most 5 sub-categories to display.

Limitations

Because there are many categories, if one section is expanded, users lose sight of some of the lower categories.

The mobile application is significantly less complex than the Web UI because its purpose, scope, and user group are much narrower. It was also built (primarily) using native iOS design patterns and components rather than Salesforce mobile components, so there were different (and fewer) technical constraints. Read on to learn more about the primary flow:

• Select a household
• Browse categories & select items
• Review the order & submit
• View order history & details

There are several primary item selection patterns we observed through our research:

• Follow a prescribed grocery list
• Walk through the entire system to see what's in stock
• Choose a few specific items

I also considered the amount and structure of the data:

• Every category except Fruits & Vegetables has fewer than 35 unique products; Vegetables has 65.
• 5 of 11 categories have sub-categories
• Categories, sub-categories, and products are subject to change on a quarterly basis

The goal for these screens was to provide flexibility to adapt to every use case.

Please note: I designed the hi-fidelity wireframes for these screens, and my teammate translated them to visual comps.

Category Overview

The categories page is designed with simplicity, consistency, and select-ability in mind. The interface is meant to be clean and distraction-free. We know that not every household will want to 'fill up' their limits. Some households do partial issuance on a weekly basis, and some simply don't have the goal of taking every single item available to them, simply due to personal preference. Because of this, categories are not visually differentiate based on number of remaining items.

Materials List

The hierarchy is structured to support eye tracking (scan-ability), proximity of related information, and simplicity. Everyone knows the names of food, but not everyone knows the material codes associated with every item. Sorting alphabetically caters to the lowest common denominator. The interactive elements on this screen are purposefully limited to keep it simple.

Enhancements

• The uniform Categories interface makes it difficult to differentiate between states (complete / in progress / not started) and understand progress. To clarify status & progress, we could implement a user controlled checklist, which would make the screen more easily scan-able by enabling users to quickly differentiate between categories in different states.
• Constraining the ordering and filtering ability simplifies the UI, but is limiting. To provide more flexibility for different use cases and preferences, adding sort/filter ability is recommended

The review screen is an essential piece of any multi-step process. It gives the user the opportunity to ensure that the customer is receiving exactly what they asked for. Items are organized by category, and the categories sorted alphabetically, mirroring the Categories page. The user can access this review screen from any screen in the shopping flow, making it easy for users to check in as they go. This screen is purposefully read-only to simplify the interface.

The success screen is another essential way of providing system status. We provide two paths forward: print the receipt (a standard step in their business process) or return to households (to issue to the next person in line).

Enhancements

• The read-only order summary is simple, but limiting. The ability to change quantity from the review screen could accelerate the issuance process.
• There is no way to return to the transaction to edit it once it's been submitted because it is a rare use case. However, pulling in the ability to edit a transaction would help users who need to make minor corrections to an order do so much faster than deleting and re-doing the entire transaction.

A user views past orders for two main reasons: a participant wants to know what they got in a previous month, or the user herself wants to review the day's orders for accuracy. Enabling search by household was a no-brainer. The other key feature on this screen is the ability to filter by current location.

The details screen is intentionally similar to the review screen. This provides consistency and familiarity. As mentioned, users cannot edit transactions, but they can void them or print them.

This was my first real-world consulting project. It had a very real budget, timeline, and pre-defined requirements. While I grew a lot as a designer, I also grew as a consultant and teammate; an integral part of any project is learning how to work with functional and technical teammates to assess level of effort, technical complexity, and overall feasibility of the designs. Because, at the end of the day, a pixel-perfect design is nothing without client buy-in and working code. Here are some of my key takeaways:

"Good Enough"

There's always a spectrum of what's possible and never enough time, resources, or budget to get everything 100% right. The trick is to find the "good enough" point - to pick our battles, understand the user's needs and priorities, and do what we can to serve those needs while working within every other constraint.

Atomic Design

Coming into this project, I had no experience with the Salesforce Lightning Design System or iOS Human Interface Guidelines. In fact, coming out of college, I had very little experience using existing platform design systems at all. I gained an appreciation for building, maintaining, and customizing component libraries, and the importance of atomic design.

Accessibility

Government systems are required to be ADA compliant. A lot of the WCAG guidelines apply to how the code is structured, but the core principles of Perceivable, Operable, Understandable, and Robust are simply good design. I gained a baseline understanding of these principles through my work on this project, and a tremendous amount of empathy by conducting some of the accessibility testing for the mobile app.