Smart Ingredients

From discovery to launch

At NakedPoppy, as a DTC beauty retailer, our user growth was extremely dependent on social media where the algorithms are constantly in flux and outside of our control. We knew we needed to strategically court a new channel to give us more stability and control over our user growth, as well as connect with our target customer (ingredient conscious beauty shoppers) on a deeper level.

We had some success partnering with wellness professional networks to recommend our platform to clients making the switch to clean beauty products. We hypothesized that pursuing the same strategy with allergists and skincare professionals could connect us with highly motivated customers trying to manage skin sensitivities. To court these new customers, we needed to enable them to confidently shop for makeup and skincare free of specific ingredients.

Before we started problem solving and imagining features, we needed to learn more about the user and the problem. The basic framework used for developing this feature was the Double Diamond approach.

Problem Space

Challenge:
Make our product into a tool that can be used by people with skin sensitivities to confidently shop for makeup and skincare

First, we had to validate that there is a market worth pursuing and whether the problem is widespread / painful enough to make building a solution worthwhile. We took the following steps:

  • Talk to our wellness partners about their experiences with ingredient-sensitive clients (both frequency and severity of the issues they discussed)

  • Market research data - how widespread is ingredient sensitivity in beauty?

  • Look at data in our own customer base to gauge demand

    • Search terms

    • Customer service emails and returns

    • Social media comments


In short: Is this in fact a problem worth solving, and are we in a position to solve it? Yes.

Now that we know we want to solve the problem, we need to understand the user. Who is this person? Is this problem a serious pain that they are willing to pay to solve? How are they solving the problem now? What are their experiences, pain points, etc. We took the following steps to answer these questions:

  • Read through conversations with active customers who reached out asking for ingredient sensitivity assistance. When possible, we set up follow-up interviews with those who were willing to chat.

  • Market research interviews through userinterviews.com to interview 15 people in depth about their experiences

I presented findings to both the product development team (engineering, data science, design) and the marketing team. The questions that came from that discussion were extremely valuable for followup conversations with users and additional market research (e.g. What are the top 20 most common irritating ingredients?).

Using the data gathered in this process, I was able to consolidate the findings into a user journey map and a user persona, and save a list of specific test cases that we could use for the solution testing later.

(It is also at this point that I did competitive research. I wanted to wait until talking to users before defining who competitors are; without understanding how they are already solving the problem, I would have been basing my research off of my own assumptions rather than user data.)

Once we had taken the time to understand the user’s experience of the overall problem, we prioritized experiences of friction / frustration by how frequently they appeared in our research. The top three were:

For ingredient-sensitive people who know their allergen, they have to become ingredient experts and check labels for every single thing they buy to prevent a painful / unsightly reaction. This anxiety and friction is a huge obstacle to shopping.

This persona prefers to buy sample sizes or try new products in-store to patch test, even if they believe the product to be safe.

This persona checks the return policy before shopping for full-sized beauty products, knowing that a reaction is possible. They will only shop if there is a generous return policy.

Solution Space

Knock Out Low-Hanging Fruit

First, we noticed two of the top pain points were addressable right away without much engineering or design effort, so we implemented both right away to start gathering user feedback.

  • We asked our head of inventory operations to reach out to our suppliers to see if they offer sample sizes or sampling programs. She was able to double the number of sample SKUs available on our platform. Increasing sample availability was also a way to mitigate the risk of increased returns of full-sized products.

  • We updated the wording on our (already generous) return policy to recognize skin reactions specifically as a legitimate return reason. We also decided to call out the policy on key decision screens (Account creation page, product page near “Add to Cart”, and in checkout flow).

    • Risk: Will making our return policy so prominent result in other people taking advantage?

    • Followup: Monitor return rate; future possible solution was to show these return policy callouts conditionally, since we know which users have ingredient sensitivities

Label Checking Feature

As a personalized shopping platform, automating the tedious process of ingredient label checking fit perfectly into our existing platform and strategy. We already had an assessment to guide people to the right products; ingredients would just be one more dimension.

User story:
As an ingredient-sensitive shopper, I want to indicate which ingredient(s) I am avoiding so that I can exclusively browse products that are safe for me.

At this point, come back to talk to engineering, data science, and design to sketch out possible solutions and discuss feasibility. Regardless of the exact frontend experience, the basic flow would be:

At a high level, this solution was feasible, with one major consideration:

Cosmetic ingredients are not written in a standard way and vary widely from brand to brand. For example, the following ingredients are the same: Castor Seed Oil, Castor Oil, Ricinus Communis Oil, Seed Oils (Castor), etc.

For the “ingredient check system”, we needed to build a database reconciling ingredient groups for searching across product ingredient lists. This would require ongoing input from our internal chemist, as we were constantly adding to our 750+ SKU collection. We would need to build a simple interface for her (rather than having her interact directly with the database).

Pause to check in

This solution requires a relatively large effort, so we paused to ask if this was too much scope creep and did another quick risk assessment to determine whether to move forward, including a check in with our internal chemist to determine any legal risk around safety claims for this solution. As an ingredient-focused company, leadership decided it was strategically worthwhile to invest in an ingredient checking system.

Now that the direction has been discussed with stakeholders, it was finally time to write a Product Requirements Document, to define success metrics, flesh out requirements, and prioritize use cases. This document served as the jumping off point for UX design iterations while the engineering team figured out the architecture of the ingredient check system.

Wireframes (created by me) for ingredient microservice

Left: High-fidelity mockup created by our designer for usability testing; Right: Final state of feature

Test plan created by me to ensure ingredient checking system worked as expected; no QA department, so the whole team was assigned to pitch in to ensure product quality!