James Sauceda

Master Catalog

Introduction

BLAZE is a technology startup that creates software for cannabis businesses such as dispensaries and delivery services. They help people who grow cannabis, make cannabis-related products, distribute these products, and sell them to customers.

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

Each shop creates their own products so it can be tricky to keep things consistent across the entire organization. They have to update each shop’s products individually.

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

Using figma comments we created digital annotations on top of our wireframes to help engineering understand the design decisions. This helps with any confusion and even provides a way for them to ask questions or suggest improvements within the UX.

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

Master Catalog is currently in beta and customer feedback has been overwhelmingly positive. A big goal for BLAZE this year was to take on the big fish, MSO’s (multi-state organizations) with lots of locations and products. Master Catalog brings us one step closer to better servicing our biggest clients.

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?

Written by James Sauceda

Connect with me on LinkedIn