Cannabis Retail Store Licensing Service

Screen showing list of names


With the legalization of non-medical cannabis in 2017, the province of British Columbia required a new licensing service for non-medical cannabis retail stores.


The foundations of the new cannabis licensing process were based on the existing primary liquor license application. However, this process was a paper-based service that was already experiencing long delays for applications to be completed. A new digital licensing application was built to support this new process with the intent to also support liquor licensing in the future.

Who Are We Designing For?

Two primary end-users were identified for this service: existing illegal dispensaries entering the regulated market and prospective new business owners. We anticipated a majority of applicants would be already operating as illegal dispensaries, so a bulk of our research efforts were aimed at understanding their needs and experiences.

The staff who process the applications were also a group we were designing for. The new application needed to ensure the quality of information they received would help them make a decision on an application.

Team & Role

The retail cannabis licensing team was a cross-disciplinary agile team made up of service and UX designers, a content writer, developers, a product owner, a scrum master, and a policy analyst. My role was a blend of service design and UX design.


Time was the biggest constraint in this project. The team was rushing to launch on the legalization date with a 6-8 month timeline.

Design Process

The design process started off with first understanding the existing liquor license process since this was the foundation behind the cannabis licensing. We used this analogous service to learn about user needs and common pain points. We conducted research with liquor license applicants that were recently awarded their license in the last month so they could speak to the full experience.

To understand the existing back-end staff processes, I hosted a systems mapping workshop using business origami with licensing staff and subject matter experts to identify the pain points and challenges during the application process.

Even though the liquor licensing process was the foundation behind cannabis licensing, the policy to support cannabis licensing was brand new. This meant there were very few business requirements to start with. Rather than wait for all the policy to get developed, I created a rough prototype outlining some of the core requirements we knew would exist (i.e. You must be 19 to apply). I took this to dispensary owners to get their feedback and learn about their perspectives in entering into this new market.

Wireframe of webpage describing what is required to apply for a license
The is was the first prototype I built and tested with potential license applicants

As the policy slowly developed I facilitated a user story mapping workshop with the product team to outline the minimum viable product to apply for a license. This provided a common understanding of what the potential process would look like and helped the product owner to establish a backlog.

To work out the application structure and initial user flows I held a couple of collaborative UX sketching sessions with the other designers as well as the developers.

Picture of whiteboard showing sketch concepts
Collaborative sketching of the potential application layout with other designers

I was able to visit dispensaries across the province with our updated prototypes to test the application process.

While the end to end service was identified, the scope of time available really focused on building a single product view to submit an application.

Screen shot of prototype for the license application page
Prototype of license application business profile
Screen shot of licensing application
Developed page of the application business profile

Accessibility testing was built into our design process by testing the application with internal staff that used screen readers. While not representative of real applicants, this highlighted some major issues in the way the application was developed, and the team was able to address these issues early on in the project.

My involvement with the project ended shortly before the legalization date as the product team moved into an operational phase with a smaller team.

The full product had not been built yet, but the team had a fully designed prototype to work from and one remaining designer to carry on the work.

Personal Success

While the product development focused just on the application submission, my designs helped the program area understand the larger service from an end to end perspective rather than only thinking about the application submission.

This project was my first opportunity to brief two ministers, and perhaps the first time they were briefed on design and design research.


I believe the concept of our MVP was flawed by focusing on incrementally building the licensing application from beginning to end. Because time was a significant constraint, this approach introduced a lot of risk by relying on the completion of a set number of features by a certain date. A more effective and “true” MVP would have been the development of the core elements required to begin processing an application. For example, asking for the location of the proposed store and some important business details.

Another struggle on this project was figuring out the role of the service designer on a product team. The other service designer and I reflected on the tension that exists when a service designer is embedded in a product team. We found that it’s incredibly difficult to work across the whole service experience because they are set up to only focus on the product, which is only one part of the service. This leads me to believe that a service design role should operate at a program level or a level higher than the product team rather than being fully embedded with the product team.