Master Catalog
- Timeline
- 8 Weeks
- Platform
- Desktop
- Designers
- James Sauceda, Ashes Holderfield
Introduction
The Challenge đź’Ş
What are we trying to achieve?
We want to create a place where dispensary owners can update all their products in one place. For instance, if a dispensary owner has multiple stores, they may have to log in separately to each store to update details. We want to simplify this process by offering one central location to make changes to all products at once.
The Approach 🎯
What was done?
- SME / User Interviews
- Personas
- Information Architecture
- Low fidelity Wireframes
- High fidelity Comprehensives
- Annotations
Personas
Roger manages inventory and buys new products for a big company with many stores. He works with suppliers who give him the newest information about their products and promotions.
Tanya manages pricing. She decides how much to charge for products so they sell quickly and don’t sit on the shelves too long. She also makes different prices for different groups like medical workers, military personnel and employees. Some products in a different locations need to be priced accordingly.
Information Architecture
We use diagrams to explain concepts to engineers. The first diagram shows the options users have when editing different types of products. The second diagram shows how we handle errors when users adopt a product, like if a product name is already taken or if a location is already being used for another product.
The Problem
This new feature is for people who run multiple shops and want to make everything the same to save time. People in charge of inventory, marketing and finance would find it useful.
The goal of this project is to make managing products easier. There will be a main catalog for the whole company, and each shop can connect their products to it. This connection lets you update the main catalog, which then updates the child products in each shop. You can do all this from one place across multiple shops.
The Iterations
We spent the majority of our time wire framing and annotating. We knew that in order for this project to be a success we needed to focus on the usability within the table and how the users will interact with their data. We decided to go with a nested table experience. Each Parent product would have the Child products nested inside. The Child products would potentially get their data from the Parent so that mass updates could happen with fewer actions.
We quickly moved on from the “Using Master” UI to a much more sophisticated set of iconography to explain the relationship between overrides and synced data. This will be explained in detail later.
The Handoff
Annotations
Documentation
Figma comments are great for explaining UI, but not for a series of events or complex user actions.
Here is how we explain the icons within the table and how we’re syncing/unsyncing between parent/child data sets.
Because “Store 2” and “Store 3” are “Linked” when you change the Parent data, the “Linked” Child data will also change. E.g. changing the price from $55.00 to $65.00 changes the 2 locations that are linked.
Great, we figured out how to edit and update Parent/Child data. But how do we assign a child to a parent? how do we make a parent?
The answer, The Adoption method.
The adoption method only has one rule. A Parent can only have one child per Location. In other words, they cannot have 2 children of the same location.
We cannot automagically group these products. This process has to be done manually. There are too many issues with the spelling and naming of products that it would be impossible to automate this. The next best thing is to make this grouping process as simple as possible.
The Adoption method allows the user to select a product that will become the Parent and this Parent will share its’ name with the children. Forcing a name change down to its children helps with the issue of consistency.
Once a product has been selected that Location’s products will be removed from the results. A Parent can only have one child per Location. This “drill down” effect will help the user by removing unnecessary results to choose from.
As the user moves thru this process they will be faced with a confirmation modal, asking them if they want to update the child values with the parents now or wait till later and create overrides? aka Link or Unlink? They will have to do this for all children unless we ask up front if they would like to Link or Unlink for all or ask every time.
The Results
Next Steps
Next is to finish our design process with the last step #5 Analyze. Need to observe our users once this feature launches, Are they using Master Catalog correctly? Did the user behavior change? What can we learn next and how do we improve?
And finally, come back to this case study with the evidence. We should find the metrics to determine if this project was a success or not. For example, On average how much time, money, & resources does this feature save our clients?
