Problem

A brick-and-mortar grocery store is struggling with declining foot traffic and sales. Their website isn’t set up for ecommerce. They are also facing competition from Whole Foods, Instacart, etc by not offering online ordering or delivery.

Solution

Enable the grocery store to stay relevant and competitive by building a clean and straightforward online shopping and delivery app.

Requirements

I determined these requirements from my research:

• Users can view items by food type

• Users can view items by allergy

• Users can view items by food diet

• Users can view items on a recipe basis

• Users can save items for later

• Users can view specific product information like pricing, options, and ratings

• Users can find products in store

• Users can repurchase items they’ve previously purchased

• Users can utilize coupons

• Users can add products to a cart

• Users can modify their cart to add and remove items

• Users can purchase items in their cart

• Users can create and log into an account

• Users can specify delivery time

RESEARCH

The user persona was provided for me, and several people I know happened to fit it pretty well so I utilized them for research. They were given a spreadsheet list of grocery items and told to categorize them however they see fit. A few insights came out of this (as represented on the sitemap): an essentials category, a diet type category, and the user story for flexibility in categorization (ex. ravioli was categorized under "frozen" as well as "canned goods").

DEFINE

The persona highlighted a lack of time and interest in grocery shopping, so in building the sitemap I focused foremost on personalization (for re-purchasing) and then saving time and money (essentials, shop by ad, shop by recipes). One thing I was careful to include, based on competitive research, was to make as little of the app require sign in/registration as possible. Users can browse and build carts without an account. Only when accessing personalization or checkout features are they prompted to use an account.

I then created a list of product requirements and a user flow. The product requirements sheet was pre-organized into a few groups of user tasks. I completed it based on a previous project involving reverse engineering screens from a finished online shopping UI, the competitive research and analysis, and the user research. I found putting myself in the user's shoes and making design choices felt surprisingly intuitive, because I had done so much pre-work.

WIREFRAMES

The product requirements sheet helped me to identify the core screens to be designed. I drew each screen on grid paper first, then digitized them, then iterated to a third version for the sitemap below. Doing everything on paper first felt tedious but ultimately it made things easier once I was in Figma because I wasn't starting from scratch and I already had ideas for changes to make as I digitized. Ultimately Figma was a better option than grid paper because it allowed me to get to the level of precision (or, fidelity) I desired.

Ideating on how the sketches could meet requirements is where the screens really started to take shape. As I fleshed out each screen, I updated the list of features/content for each screen and copied things to similar screens as necessary. I also did this when doing version 1 on paper: I designed the homepage first because it is often the user's first foray into the product, and the navigation I designed for the homepage ended up becoming a static global navigation. I re-used many elements over and over for ease of understanding and use.

PROTOTYPES

I worked on the high fidelity prototype and interaction design more than six months after the wireframes, so a lot changed based on what I had learned.

I went for a more image-focused look based on my personal experience with online grocery shopping. I also streamlined some of the information as to not overwhelm the user with too much. A major component is the use of pop-overs for "quick actions" when possible. Very few screens are actually full-size pages, and that was a deliberate choice for the most foundational pages. A quick view of the product, a quick add to the cart, and a quick log-in did not necessitate navigating forward to entirely new pages.

I was extremely careful to design all interactions that move the user forward in the flow as pages sliding in left from the right. Inversely, all interactions that move the user backward in the flow are designed as pages sliding in right from the left. Think about flipping forward a page in a book, and then flipping backwards a page.