Timeline
2 months
Role
Lead Product Designer
Platforms
Web (Desktop)
Tools
Sketch, Invision, Jira
BACKGROUND
What is FabFitFun?
FabFitFun is a female subscription box focused on lifestyle, beauty, health, wellness, and tech, offered in an annual or seasonal (quarterly) membership.
The membership includes a seasonally themed box of 6-8 full-size products, access to shop multiple flash sales with products at up to 70% off, the opportunity to reFill their favorite products each season at up to 75% off, an always-on Shop to purchase products between the sales, exclusive brand offers , custom magazine and TV content, and an online community forum of over one million other women.
Overview
Original Product Management
When this project started, products were only sold in flash sales, The Shop, and the seasonal box (it has since expanded to include other programs). The Merchandising, Style, and Data teams were the ones responsible for organizing and maintaining these products. They accomplished this labor-intensive manual process by using a combination of Salesforce, WooCommerce and WordPress, and Excel.
User Pain Points
A Situation Ripe for Inaccuracies
The teams used the ds.product_information table since it stored all products, attributes, and taxonomy, but there were many manual steps to adding and filling in missing product data. To add box and e-commerce products, users would have to first export a Salesforce report, resolve any duplicate SKUs, and then fill in any missing columns with information from WooCommerce. In the ds.product_information table, COGS, MSRP, and Sale Price were not exact, so users were forced to use another table to pull the exact numbers. This resulted in a lot of checks and cleanups to maintain accurate data.
Additionally, Donation SKUs were not entered in Salesforce at all, and the Style team had its own separate process to manage its SKUs and data. Since the product information was entered in multiple places, it led to potential conflicts and incorrect information in images, product names, and SKUs. That product information was then retyped each cycle, introducing an even greater opportunity for error.
The Problem
Many labor-intensive processes are used to collect data from multiple systems as a means to manage the products.
Disjointed Process for Teams
The Merchandising, Data, and Style teams all used different processes to manage the product data. This led to a high level of effort to maintain accurate data and no single source of truth.
No Centralized Location for Product Data
The teams used a combination of Salesforce, WooCommerce and WordPress, and Excel to manage products, leaving a lot of manual work and ample opportunity for error.
Security Risks
The teams were reliant on using the WordPress image manager to upload product images. While it was behind a proxy, there were still security vulnerabilities associated with using it.
Dependency on WooCommerce & WordPress
FabFitFun was built on WordPress and used WooCommerce to manage all products in the Box and Sales. The legacy code written on these platforms was hard to update and maintain.
Solution
Build a single source of truth to create and manage products sold through the e-commerce experience.
MVP Requirements
Fulfilling the Users’ Needs
There are two main users which were in need of the Product Catalog: The Merchandise team and the Data team. The Merchandise team sets up the products and determines which products go in each of the sale campaigns. The Data team gathers insights from the data for planning, machine learning, and reporting, They also tag products with their attributes for proper tracking.
One Location to Create and Manage Products
Eliminate the labor-intensive current process by connecting systems and teams' workflows by instead using a centralized source of truth.
Link and Manage Meta-Level Data
Access the information and meta-data of a product in one location. Allow for the standardization and maintenance of the taxonomy structure for all available inventory.
Eliminate Use of WooCommerce & WordPress
Create and store a catalog of product data to support the front-end display of products in sales and on the corresponding product detail pages.
Create a Safe and Stable Environment
Rebuild the sale experience from scratch without using WordPress or WooCommerce, therefore enabling it to withstand the heavy sale traffic and better protect user data.
Research & Inspiration
User Interviews
I talked to members of both the Merchandising and Data teams to uncover their workflows and exactly what each of their teams would require in the Product Catalog.
Merchandising Team: Mia Nunez, Digital Merchandise Manager
I interviewed Mia to discuss how they add and manage products, the data points required for product details, and how to standardize the structure of those data points across all categories. She also walked me through what aspects of WordPress and WooCommerce her team relied upon that they desired to be replicated.
Data Team: Mallory Coleman, Senior Analyst
I interviewed Mallory to understand the current taxonomy structure and determine the meta-data needed to be available to tag each product. She walked me through Akeneo, a Product Information Management (PIM) software, and pointed out which aspects she wished to have in her workflow.
Ideation
Mid-Fidelity Wireframes
After reviewing the research and requirements, wireframes were explored to determine the best UX to fulfill the needs of the teams. I solidified the input fields for product information across all categories as well as how they might look for creating a simple product or a variable product.
Iterations
Requirement Updates
Soon after development began, one of the engineers discovered a previously unknown technical constraint that prevented having separate flows for creating simple and variant products. In future mocks, these two flows were then consolidated into one generic flow to accommodate both types of products. The below iteration shows how the Product Catalog would have been designed if the flows had remained separate.
THE SOLUTION
Final High-Fidelity Mocks
After rounds of iterating, solving for technical limitations, checking the fulfillment of user requirements, consulting with the user groups, and determining the best user experience, the final designs for the Product Catalog were solidified. There are three main sections: Table & Grid views, the Product Information tab (for the Merchandising team), and the Product Meta-Data tab (for the Data team).
Table & Grid View Mocks
Product Information Tab mocks
Product Meta-Data Tab mocks
RESULTS
What Was Accomplished?
The goal was for all teams to be able to collaboratively work together on product data and use The Product Catalog as the source of truth for product data. The tool was intended to be an effective internal tool with capabilities to manage day-to-day work around both comprehensive product information and the details of specific e-commerce opportunities.
More Consistent & Accurate Information
Information is now consistent between the product cards in the sales and their product detail pages. Also, beforehand, product thumbnails would be missing from the sale because they weren’t previously uploaded in WordPress. Now, that is never the case.
More Frequent Sales = More Revenue
The Product Catalog has severely reduced the time it took to put together and organize a sale assortment. The Merchandising team can now set up a sale to have one every week instead of the two per season previously. This has greatly increased the company’s potential revenue.
Reflection
Final Thoughts
The launched MVP was massively helpful in both removing the dependencies on WordPress and WooCommerce while also improving the workflow to facilitate a sale. However, the requirements for the MVP only considered e-commerce products. There is a plan to add box customization options to the Product Catalog, however, there is different logic that needs to be incorporated. Had those requirements been considered at the beginning, my designs could’ve offered a roadmap to accommodate both box and e-commerce products.
There was also a last-minute requirement change based on technical constraints discovered after development had already begun. The original designs offered a different flow for adding a simple product versus a variable product, as shown in the Iterations section. However, the executed solution only has one flow with an input form that accommodates both types of products. Had we reviewed the designs with the engineers sooner, there is the possibility that a more elegant solution could have been achieved. Thankfully, the Product Catalog still accomplished its goals and offered an intuitive solution for our users.