The Current Solution (i.e. the product as it exists today)

Fig is a powerful tool that brings dietary restriction management to users’ fingertips. Users are able to input personal (and often complex) restrictions into their Fig profile and then scan product barcodes to quickly identify if the product works for their allergens.

❌ The Problem

Users are only able to create and use the tool for one person. Fig hopes to expand their current features to better help users share, organize, and manage multiple personal diets OR the dietary restrictions of others.

Fig strongly believes that eating and enjoying food is a social activity and they hope to support this belief through their platform.

✅ The Goal

Fig’s main goal with this feature addition is to develop a more robust tool to alleviate the daily frustrations around managing the dietary restrictions of multiple people.

Over time, Fig hopes to create new features and work toward a freemium revenue model.

OK, so what does this problem look like in real life?

Step 1: Maria goes grocery shopping for her family

Pain Point: It’s taking forever to cross reference the ingredient label to each physical list of her children’s allergies.

Step 2: Setting up the Fig app

Pain Point: She can only make an account for herself, so she inputs her whole family’s dietary restrictions into her Fig profile.

Step 3: Maria scans and evaluates product information and safety

She scans a bag of pretzels. Immediately a product drawer opens and tells her that:
1. The product does not match her Fig profile
2. What the problematic ingredients are

Pain Point: Maria has a good mental grasp of which ingredients relate to each child, but she doesn’t know what GALANGAL is or who it relates to.

Given the time constraint, I needed to get realistic with scope

Our project roadmap consists of two major functionalities...

Multiple Fig Profiles

ability for users to create and use multiple profiles

Shareable Fig Profiles

ability for users to share and receive profiles created by others

My main recommendations were to:

✽

Focus on building and shipping multiple Fig profiles first

Having multiple Figs is a dependency for the shareable Figs feature. Learnings from market findings could redirect design for shareable Fig profiles.

✽

Conduct user research on needs and expectations for both problems

The design for multiple Figs could be informed by future considerations for shareable Fig profiles.

Understanding the User

Methodology

As someone with the most basic of dietary restrictions, I created an inventory of assumptions about how people currently manage day-to-day tasks regarding food. These assumptive journeys helped structure research questions. In order to receive insights from a diverse set of participants, we interviewed both current Fig users and non-Fig users with dietary restrictions. Empathy and exploratory research were conducted via 1-on-1 phone interviews across 9 participants. Findings were then grouped using affinity mapping to concentrate on common and high-impact areas.

Research Findings for Multiple Fig Profiles

Primary caregivers, often mothers, have the highest need for multiple Fig profiles

One family member is generally responsible for most grocery shopping, although other food-related responsibilities may be split

Families with overlapping restrictions hope to minimize meal variation with “foods that are safe for everyone”

Families that have different and severe dietary restrictions often eat different meals or different variations of the same meal

“Safe” foods are physically separated at home - each person has their own “safe” food baskets

Research Findings for Shareable Fig Profiles

Communication of restrictions is highly dependent on social situations and relationships

Individuals with moderate or lifestyle restrictions would likely NOT adopt this feature

Fig profiles would primarily only be shared to extended family members or close friends

Often times, participants are conscious about sharing their restrictions in fear of “being a burden”

Participants often simplify their restrictions to their most common ingredients (i.e. Low FODMAP = no garlic, no onion)

All participants mentioned that they bring their own food to social events

There is considerable uncertainty and distrust around consuming food cooked by others mainly due to lack of understanding surrounding the scope of restrictions

Friends/family members have difficulty understanding and identifying allergen derivatives

Participants find that others do not fully understand the scope of their dietary restrictions

Milk allergy is often confused with lactose intolerance
“Organic” and “non-GMO” products are incorrectly deemed safe by family members

Participants report that others do not understand the severity of consequences

Participants often prefer to share what they can and like to eat instead of what they can’t

Back and forth communication surrounding restrictions is difficult and frustrating

Participants focus on preferences rather than restrictions when sharing dietary information, especially when it comes to young children

Participants rely on brand specificity when shopping for products as brands usually specialize in certain restrictions (i.e. daiya = top 8 allergen free)

Visual aids and product/brand specificity are helpful to share with family and friends

Participants often communicate substitutions for common ingredients

Family/friends often send photos of products and ask “can you eat this?”

The research brought to light an important blind spot we had about managing multiple dietary restrictions

I assumed that users would want to find products that worked for multiple or all members of their family. Although this assumption wasn’t completely wrong, our research indicates that many users don’t have the luxury of shopping for overlapping items. This begs the question...

HOW MIGHT WE...

Design a flexible solution for two key use-cases:

Users hoping to find products that work across their entire family
Users that need to look for safe products for individual members

The user flows needed to expand and accommodate multiple types of decision making

The current scanning task flow (left) is intuitive and simple. However, we needed to create a flexible flow to accommodate multiple profiles. The expanded scanning user flow (right) highlights the decisions the users must make to obtain enough information to make purchasing decisions.

Ideating on the Solution

Introducing multiple Fig profiles would modify flows for the majority of user tasks throughout the application (total 7 user flows).

Although all design decisions were evaluated across all flows, the remainder of this case study will focus on the app’s primary user flow - scanning products.

Lets reframe the HMW in context of the existing product

Research Finding #1

Users hope to find products that work across their entire family

Design Insight #1

HMW help users quickly identify if products work across ALL Fig profiles at a glance

Research Finding #2

Users often need to look for safe products for individual members

Design Insight #2

HMW segment information to allow users to deep-dive into individual Fig profiles and ingredients

Design Patterns + Competitive Analysis

As I began brainstorming ideas, I turned to existing patterns that felt familiar to minimize in-app learning.

Instagram allows for easy switching of accounts, but profile functionalities do not overlap between accounts.

Gmail also allows for easy switching of accounts, with the majority of account/profile functionalities not overlapping. However, Gmail does allow for users to create one “mega-inbox” to view all emails from one screen.

❌

These pattern would be too heavy for Maria as she’s quickly scanning items in the grocery store for 3+ profiles.

I began to think about the profile data to help brainstorm how to visualize it - essentially the Fig profile data is a simple matrix

Each Fig profile has Yes/Maybe/No ratings across 5,000 different ingredients. When an item is scanned, the ingredients in the item are pulled out alongside the ratings for each profile.

So, how can we best access this segmented database, but preserve functionality without switching accounts for each scan?

Designing and Iterating

Using the user flow, I built out lo-fi wireframes to how users may navigate information after scanning products at the grocery store. Remember, scanning is how most of our users like to use our platform.

Final low-fidelity explorations were then shared with the team (PM, Marketing, Dev) to discuss further business goals and constraints. Two final explorations were then prototyped and tested.

Exploration 1

One pager with ingredient tags

This exploration was abandoned early on due to accessibility concerns.

One-pager allows for a shallow sitemap and minimizes back and forth

The high level overview is very clear - beneficial for large families

❌

Information overload + confusing hierarchy. There is too much information on one page - users don’t know where to look.

❌

Glaring accessibility concerns. Icons are too small, color is the only indicator of product match.

❌

Long-scroll tradeoff. Although the one-pager minimizes back and forth, it increases the amount of scroll.

Exploration 2

2-Step Process

This exploration tested extremely well in usability testing with all users being able to complete the task at hand. However, it’s important to note that the this task is usually completed in a fast-paced, chaotic environment.

High-level overview to allow for quick scanning for all Fig profiles

Photo, icon, color, and text visual cues to increase accessibility

Prominent photo reminder of how the user has branched and through what lens they should be reading information

Flagged ingredient first to minimize user overload

❌

The product team is uneasy to nest ingredients due to potential liability issues. Historic data suggests that users are also hesitant to trust only overviews.

❌

82% of scans yield yellow or red results - users are always reviewing ingredients to see why. This design could induce thumb fatigue.

❌

Important to keep ingredients ordered by dominance (identical to packaging) as users may make purchasing decisions based on ingredient volume.

❌

Custom modals may not be worth dev lift

Exploration 3

The Toggle

This exploration was most popular with the team, even prior to testing. I had some initial design concerns, which were tested and remedied with iterations.

One-pager allows for a shallow sitemap and minimizes back and forth

Quick high-level identification of all profiles with ability to scroll left and right to view more profiles

Toggle option to quickly view ingredients for each fig profile/ individual

❌

Scalability concerns. When shared Fig profiles are introduced, L<>R scroll may be difficult.

❌

Accessibility concerns. When users are not selected, color is the only indicator of safety.

❌

Who’s Fig profile comes first? How should the Fig profiles be ordered? How do we determine who is most important to our user?

❌

Profile photos need moderation. Too much lift for backend developers at this moment

We have a Winner!

After team discussions and some quick and dirty usability testing, exploration 3 moved on to high-priority revisions for the MVP.

The Final Solution (for now...)

The Fig app recently went through a complete re-design, which meant a whole new design system. As I iterated on my solution, I prioritized using existing components that were being utilized and could be pulled across all flows.

Future Consideration: What happens if users have 10+ profiles?

Our research indicates that this would be an edge-case. For now. Currently, users would only manually create profiles for users within their immediate/ extended family or people they cohabitate with (2-6 profiles).

However, when the feature expands to shareable Figs, we’d have to consider the # of profiles effective in a L<>R carousel and brainstorm solutions to allow users to scan for a set of people at a time.

A Quick and Necessary Reflection

Advocate for Research

Due to tight timelines and a lean design model, processed-backed research was not fully prioritized. The compromise was in-depth exploratory research, expedited and nimble testing of mixed-fidelity wireframes, and preference testing through social channels. Exploratory research revealed some blind-spots and allowed us to confidently move forward with design decisions.

But balance constraints

Certain design decisions were unable to be tested due to constraints and led to longer team-discussions with no final conclusions. As a team, if we had minimal convictions, we’d move it into the “release and test” bucket. A prime example was a mini-feature that is currently underutilized (~0.64% across all users).

Usability, feasability, then everything else

As a designer, I prioritize functionality but also have an affinity for “pretty”. With a lean dev team, that meant adios to custom modals, half-height bottom sheets, and no profile photos for the MVP 🥲. But, by working within those constraints and referencing the existing brand guidelines, aesthetically pleasing emoji icons were built (win!).

Utilize team member expertise

Although product itself is amazing - the best thing about Fig is the team. I was able to recognize the passion and integration that the team had with their users and truly valued their past user insights and experience with in app analytics. Being able to have conversations about previous performance helped navigate difficult design decisions, both for design and for business goals.

This design is currently in development and is scheduled to be released in late 2022. This feature is one of the first feature releases for Fig+, the premium version of the app

View Handoff File (FIGMA)

FIG: Food is Good

LETS GET SCANNING

We have a Winner!

Future Consideration: What happens if users have 10+ profiles?