A Cannabis Startup Designs User Experiences for its Own Employees

At a SaaS startup that had recently doubled in size, the need for internal training tools became a top priority

Miah Ariel Jones
UsabilityGeek
8 min readApr 4, 2020

--

By nature, every cannabis adjacent business is young — medical and recreational legalization have only been around for so long — and even state cannabis compliance agencies are new at what they do.

If you’re a successful young startup operating in this space, you’re navigating multiple challenges: keeping abreast of the needs of a rapidly growing business, and keeping on top of the complications of compliance.

The Problem

Greenbits — a cannabis-industry startup — evolved from humble origins into a full-scale retail solution with point-of-sale, inventory-management, and third party integrations. The number of Greenbits employees nearly doubled in 2018 alone.

While such rapid growth was welcome, Greenbits also found itself caught in a pickle — their new employees had not been equipped with a straightforward way to learn about their product and platform offerings, many of which were still being defined. Their onboarding program was a good start, but fell short of explaining why the product behaves as it does — or what real-world scenarios it’s intended to work in support of.

This problem was most impactful on the Product teams, where Product Managers, Designers, and Engineers often found themselves imagining solutions that were not in-line with the overall product vision and lacked understanding of the product’s historical context. Without this shared understanding and framework for evaluation, they would continue to produce a fragmented experience that didn’t meet the needs of their customers.

The Solution

When I joined Greenbits in 2019, we envisioned a “Product Development Guide” that would serve as an internal tool for educating our employees about the world of cannabis retail, cannabis compliance, and Greenbits’ products. The Guide would also serve as a central hub for referencing Brand and Product guidelines, customer research, vision, and goals.

In short, it would be the blueprint for how our platforms and products are supposed to work.

Cool… but how is this UX?

This project was an important reminder that UX is everywhere, and considering the “user experiences” of your own employees can have a powerful impact on workplace culture, talent retention, productivity, efficiency, and product quality.

Why me?

Greenbits’ lead designer assigned me to this project for multiple reasons:

  • My pre-UX background in education and curriculum design made me uniquely equipped within the company to distill the opaquely complex into the easily, and enjoyably, digestible. It was my specialty as an educator, and it’s still my favorite part of being a product designer.
  • As a newly hired designer at Greenbits, I had the benefit of documenting the process of my own learning. What did I need to know, when I started? What questions did I have about our product development process? About the world of cannabis compliance and retail? Each of those questions, and more, became sections of the Guide.

Who was the Product Development Guide for?

Cross-functional teams drive product development at Greenbits, and are composed of product designers, engineers, product managers/owners, customer support specialists, and quality assurance analysts. All of them were considered as intended users for the Guide.

The Product Development Guide

Core Concepts

This section looked at the entire ecosystem of Greenbits’ products, and how they interact with each other. It also defined who we are designing products for, & what those products need to do for our customers.

The first concept this section sought to explain was the difference between retail and compliance — two equally important aspects of our product.

Retail vs Compliance

When selling or shopping for cannabis, employees and customers bring expectations from regular retail to the cannabis retail experience. Helping our employees understand retail considerations as separate from compliance helped them design front of house solutions that could function as seamlessly as, say, an Apple store.

What is Compliance?

Because each state regulates cannabis differently, each state may also have different rules about who is allowed to buy it, in what quantities, and under what circumstances. Deeply understanding these details helped our employees buy-in to the purpose behind certain tools in our product, or customer requests for ones that did not exist yet.

Customer Purchase Limits,” for example, is a feature that would protect cannabis retailers from looping customers who seek to abuse retail limits by leaving and returning to make multiple bulk purchases. Some store owners who have allowed this faced prison sentences, so it mattered that we got this feature right for our users.

In addition to keeping track of customer eligibility and purchase limits, businesses working in cannabis must keep track of the plants they cultivate, process, and/or sell. Traceability systems track cannabis materials through their life cycle, recording the chain of custody. Cannabis businesses are accountable to state compliance agents, and must be able to produce products or records thereof upon request.

Greenbits marketed itself as a safeguard against compliance violations like these, and our customers trusted our product to help them keep their compliance information organized and accessible. Understanding all aspects compliance requirements as a Greenbits employee was an important part of providing that service to our users.

Who are Greenbits’ users?

This section sought to explain the User Personas Greenbits designers had developed by researching their customers. In writing these sections, I also updated personas that had become outdated.

Greenbits had a lot of personas, but it needed to. As a complete solution for cannabis retailers, different parts of our product were optimized for different users. Depending on the feature or workflow, different personas would become primary and secondary users.

Organizational Archetypes

Organizational Archetypes described the conditions in which our products were used— the setting in which a user persona operates can influence their expectations and experiences.

Product Development Lifecycle

Without a defined product development lifecycle, all sorts of not-so-desirable outcomes might occur — solutions for one thing might break something else, or teams may work on solutions in a non-prioritized manner leaving our customers with urgent needs in the lurch. Even worse, teams may devote valuable time and resources developing a solution only to find that it wasn’t what our customers needed at all.

The lifecycle wasn’t so prescriptive that teams weren’t free to address bug fixes or small enhancements on their own, but it did provide avenues for bigger jobs to be folded into the more defined development process.

How the Guide is Used to Build Products

The remainder of the Guide aimed to synthesize concrete research from real-world observations, which we used to build product design requirements, grade our current solutions, and guide development of future solutions. If a team were to tackle upgrades to, say, the incoming inventory workflow, they would refer to the Receiving Inventory section of the guide.

A dispensary employee receiving inventory

In each product workflow section, we first outlined who we were designing this experience for and formally described their actions and expectations based on stakeholder interviews, site visits, and other research.

As different dispensaries can organize their businesses differently, there may be a variety of activities that are entailed in a singular task — i.e., not every user’s needs are identical. Story Maps are a great tool for quickly visualizing those various activities.

The activities documented in the Story Maps were organized and ranked in Key Path and Alternate Scenario Tables. By detailing the scenarios we were designing for in a narrative form, we could understand what actions and data to prioritize when creating a solution.

We organized these priorities into two tables — Key Path Scenarios, for the highest priorities, and Alternate Scenarios, for the secondary priorities.

Artifacts such as screen shots and screen recordings were included in the Current Product Experience column, and a health score was assigned to our current solution in the Health Score column.

In addition to story maps and scenario tables, we included the following in each product workflow section:

  • User Personas — the primary, secondary, and special-case Personas that these workflows should be optimized for.
  • A problem statement — the overarching reason that we are creating a solution for this workflow.
  • A vision statement — the vision that we have for our solution to the above problem statement.
  • Competition experience — collected research on our competitor’s approach to these workflows was placed here.
  • Product development history — the thinking and work that’s been done on these workflows thus far, to ensure new people understand the history of a workflow and how it’s evolved over time.
  • Past design proposals —designs that were not developed due to time constraints, budget constraints, or shifting priorities. Cataloguing them here to ensured future designers could reference them for inspiration or direct implementation in the future. It also protected us from doing re-work by investing time developing ideas that had already been proposed.

While taking the time to clearly articulate these complex ideas may have seemed like an unnecessary investment to some, it allowed us to spread customer empathy throughout the organization and was key in driving design-focused roadmap changes at the highest level.

It improved the quality of our product design moving forward, and reduced time spent re-articulating concepts and decisions that had already been discussed. Product team members frustrated by re-work and product roadmap confusion felt more engaged and empowered with more agency over their work. Overall, the Guide experiment was a success, and continues to be used by Greenbits product teams today.

Want to learn more?

If you’d like to become an expert in UX Design, Design Thinking, UI Design, or another related design topic, then consider to take an online UX course from the Interaction Design Foundation. For example, Design Thinking, Become a UX Designer from Scratch, Conducting Usability Testing or User Research — Methods and Best Practices. Good luck on your learning journey!

Credits: Humaaans by Pablo Stanley, remixed by me. Persona cards by Portland-based design team member Alexis Peterka, with updates by me. Greenbits design lead Seth Banks & senior design team member Karin Curkowicz provided invaluable collaboration & mentoring on the project.

All other graphic content by yours truly.

--

--

Miah Ariel Jones
UsabilityGeek

Miah Ariel is a product/UX designer based in Oakland, CA. She’s passionate about sci-fi, lumpia, & solving for social good. Say hi @ miahariel.xyz.