The Highs & Lows of Designing a New Service: Cannabis Legalization in B.C. by Davis Levine & Meg Stiven
•Télécharger en tant que PPTX, PDF•
1 j'aime•130 vues
Presented at Impact: 2018 Canadian Service Design Conference, November 29 & 30, 2018 (Montreal, Quebec) Starting only 10 months before legalization, with undrafted regulations, and a politically sensitive topic, the cannabis project highlighted the highs and lows of service design and digital product development in government. With the announcement of cannabis legalization in Canada, the Liquor and Cannabis Regulation Branch partnered with the B.C. service design team to design the new application process for private retail sales. As with many design briefs, there was more to the problem than just designing an application. Our research reframed the problem from the need to design a single application process to understanding the end-to-end journey of selling cannabis in B.C. To be blunt, this project wasn’t smooth. You’ll get the real story of where we weren’t able to have the impact we wanted, how we felt the tensions of designing a service vs building a product, and the positive impacts on our practice from what we learned.
Recommandé
Recommandé
Contenu connexe
Dernier
Dernier (20)
En vedette
En vedette (20)
The Highs & Lows of Designing a New Service: Cannabis Legalization in B.C. by Davis Levine & Meg Stiven
Notes de l'éditeur
- Meg Introductions – Hi I’m Meg Stiven, and I’m Davis Levine … We work on the service design team in the British Columbia government, and today we want to tell you our story about designing the new licensing service for stores to legally sell cannabis in British Columbia. I wish we could say this story ends with a triumphant success, demonstrating the value service design and agile development bring to complex processes in the public sector. But unfortunately, this story is not that story. This is a story about failure. We’ve called this talk the highs and lows of designing a new service, not only because of the pun but because this project wasn’t the definition of success that we hoped for. We did have a lot of high moments [pause] (not that kind), but we also experienced a lot of lows. So let’s tell you our story….
- Meg The way our team approaches design problems in the BC government is through our B.C. Service Design Playbook. The 6 phases of the playbook have guided our practice in the public sector for the last 6 years. And over the last year or so we’ve added the “implement” phase in the response to the growing need of being able to transition from research and design into the delivery of a service. This was one of the first projects that really saw our service designers embedded on a multidisciplinary agile team working directly with developers and having to work out what it means to go through an end to end service design process while simultaneously trying to build a product.
- Meg In case you don’t participate in society or watch the news, recreational cannabis is now legal across Canada. And it’s really just been over the last year or so, that the provinces were trying to figure out how to regulate the sale and distribution of this previously illegal product. So back In January 2018, the newly renamed Liquor and Cannabis Regulation Branch, came to our service design team and said hey, you know that whole cannabis legalization thing? We want your help in designing the licensing application.
- Davis Of course we said yes! This was an opportunity to design a brand new service, and one that would have tremendous social and economic impacts for all levels of government and society. Who wouldn’t want to be part of that story? At that point in time the federal government hadn’t passed any legislation about cannabis or given a firm date for legalization, so naturally BC didn’t have any legislation, regulation or policy to say how this new thing would work. For Meg and I, we didn’t yet know everyone involved from the province’s perspective or understood the level of complexity this would entail…
- Davis But even in this uncertain environment, we were confident that with our service design approach and toolset, we could set the service up for success.
- Davis And notably, the product was being built using agile development in the Continuous Service Improvement Lab, known as the CSI Lab. The CSI Lab is a test bed for all things agile in the BC government, helping product teams build quickly and get outside of the classic IT waterfall process of government. There seemed to be no better place to run a project like this.
- Meg When we first started the project the client really thought they just needed to design an online form. [slide change] Our service design brains told us there was probably going to be a lot more to this problem than just designing a form. And yes, while this was a new service, the same group that was running liquor licensing would be running the cannabis licensing. I think that in many people’s minds the cannabis process could simply mirror what they did in liquor licensing.
- Meg So we started there with liquor and did what any good designer would do. We went out and did research. We mapped existing processes from liquor licensing and spoke with the licensing staff that would eventually be dealing with the cannabis applications
- Meg We spoke to people about their previous experiences applying for liquor licenses, and saw the stacks of paper they collected from this process.
- Meg And we also met with some local governments to understand their role in the liquor process and uncover what that future interaction for cannabis licensing might look like
- Meg Most excitedly we were able to visit existing dispensaries, spoke with cannabis consultants, and other businesses looking to get into this new market.. Lucky for us, there were no shortages of dispensaries already operating in BC, and especially not in Victoria. We had 6 dispensaries within 1km of the CSI lab already operating in the “grey market” This was the most interesting part of our research where we got to hear personal and intimate stories of why people got into this business in the first place when there was so much risk in doing so.
- Meg From the mom and pop pot shop to the large corporations. From existing dispensaries to new entrepreneurs. Our research gave us a good understanding of the different types of applicants that might apply for a license and what their needs would be.
- Davis We worked tirelessly for the next 6 months on a train ride rushing towards legalization. Designing in a space where the regulations were emergent and the number of stakeholders involved would make your head spin trying to coordinate. The level of complexity revealed itself week after week as everyone was trying to figure out how this would all work. Our team built the product as quickly as we could trying to design around complicated policy decisions balancing fairness, security, and public safety all while trying to make it as usable as possible.
- Davis But the train ride hit an unmovable deadline and in the end the client had to rely on a backup plan of a paper application. In our eyes, we failed. Yes, government was able to start accepting applications to support the legalization date, but for us, our intention of saving business owners and staff from the stacks of paper required in a paper process wasn’t realized. We felt accountable to the success of this service and more importantly we felt like we let the applicants down. While public servants don’t often openly speak about the failures they’ve had, there’s a new culture emerging that recognizes the vital role failure has in organizational learning. Failure truly has the biggest impact on changing how an organization works.
- Meg After we left the project, we reflected on these feelings of failure .Like any service designer would naturally do when trying to understand an experience, we mapped it out. What were the highs? The lows? The pain points? And the opportunities for us to learn? We’ve identified 3 impact lessons that were both highs and lows, which have impacted our practice.
- Davis Our first impact lesson is positive one we took away from this work and it’s to “Make the journey clear for users.” When designing a product or service ensure that the journey to a user’s goal is clear to them, even when that bigger goal is outside of your product. For our team, creating this journey from the start was a challenge because at the beginning, no one really knew how this would all come together
- But we knew we couldn’t wait to know everything, so we started out with some basic licensing requirements and created a very simple prototype to put in front of potential applicants. I remember sitting in the living room of a potential business owner going through this prototype and they turned to us and said “yeah yeah I understand the words I’m reading on the page, but where do I fit into this?” That was an Aha! moment. Because policy is a lot more than a list of rules and requirements, the policy is the service. So if people don’t see where they fit within the policy it’s not helping them achieve their goal. And for a service with so many unknowns for it’s users, we knew that we needed to design the application in way that took applicants through that journey to reach their goal of selling cannabis.
- When you zoom out and look at the licensing process as being one step to the user’s goal of selling cannabis, the first step in an applicants journey isn’t to submit an application form, the first step is...
- ... to register a business. Submitting the application was just one part of a much larger story.
- To communicate this end to end experience, we laid out the journey, step by step from beginning to end...from registering a business to reporting your sales. And it really was important to make this whole journey clear because our research told us that potential applicants had sooo many questions and concerns, and often they weren’t related to licensing. Making these connections clear to users isn’t as simple as it seems.
- For example, one of the major steps in this process is for local governments or indigenous nations to tell the province either yes or no for having a store open in their community. This typically requires applicants to go through a completely separate process for zoning and permitting. Even though this was a major part of the legislation and the applicant’s journey, the legal team told us that we weren’t actually allowed to tell applicants to go to their local government or indigenous nation. We could only say that it was a part of the process. This is a small example of the many challenges designer’s face in the public sector trying to balance the needs of users with things like legal opinions or political priorities. --
- But for the steps that the licensing area did control, we designed that journey into the application process itself. Rather than just developing an online form, the eventual design of the application would let the user know where they were at in the process and what would be required at a later date. So it’s important to make this journey clear to users and design the service so they don’t have to figure it out themselves, but as service designers how can you make sure that this journey can actually become a reality? This brings us to our second lesson…
- Meg “Position yourself where you can have the impact you want” As service designers, we need to really understand where we fit in an organization to understand the type of impact we can help create. We had these moments, in our little product room at the lab, where we were making big connections in our research analysis, seeing exciting opportunities to build value into the service, and wondering -- who do we tell about this? Who’s making the decisions that could take this idea forward? Whoever they were we knew they weren’t in the room with us. We were looking at processes and problems that impact the licensing experience but might not be directly built in the product. So was the client on the same page as us about the impact we’d be bringing as service designers? When our team looks at service delivery in government a problem that we’re faced with is the feeling that….
- ...EVERYTHING is the service. Where does the line start and stop? There are lots of elements that comprise a service, things like our online content, policy, software products, and especially the in person experiences at our ServiceBC locations. It all impacts the service experience. While we knew from the start that we were going to “design the licensing application” what did that really mean? Were we just there to design the user interface?or define the business processes? Or were we there to help with creating the policy that would become the service? These things are all connected and we know they can’t be easily divided when trying to create a great service for citizens. So who did we need to work with to create the value we saw from our research? Well, the licensing process actually involves many teams.
- In the Licensing Branch there’s the license processing team, the policy team, compliance and enforcement, communications, and our team, the product team. At the Ministry level there’s even more players involved like the security team, the financial integrity team, legal, and the IT systems team. Overseeing ALL of this and everything else related to cannabis, like impaired driving, was the cannabis secretariat. And remember how we mentioned vital the role of local government and indigenous nations as part of this process? So we had about 9+ different teams and another jurisdiction all needing to work together to create one seamless and efficient experience. [animate - have circles appear one by one]
- Where does service design fit into this landscape? To design a good experience, we knew we’d need to work in all of these spaces to some degree.
- Yet we were placed here on the product team within the licensing area. It became incredibly difficult for us to take that zoomed out, holistic approach. We weren’t positioned properly to help all these teams work through their problems.
- We were stuck within the tensions of trying to work on a systems level while also having to design the user interface. So we learned that for embedding service design into an organization, where you are positioned has a huge impact on your level of influence and scope of work. But maybe more importantly for developing a product we also learned that it’s not just where you as designers are positioned, but the position of your product team also has a major impact. And that brings us to our last lesson.
- Davis To develop a successful product in a large organization with multiple teams you need to…”Align everyone to the product team”. Because even though all these different teams are creating policy decisions for their separate areas, they all contribute to and impact how the product will work.
- Our product team in the CSI lab started off as a fairly typical agile team. We had a product owner, scrum master, a handful of developers and architects, Davis, meg another designer, and a content writer. We were tasked with taking all these different policies and creating a minimum viable product
- So we had our agile team working in the CSI lab building the product, but what about all the other teams, how were they working, and how were they contributing to the MVP? Each team was working in their own separate areas figuring out how things should work for their own needs, without seeing how everything came together.
- While each of these teams were off working in their own policy areas, we, the product team, became reactive - we were a dumping ground for all the business requirements coming from these different groups at different times. As more and more business requirements were pushed to the product, our team grew...[change] and grew….[change] and grew….[change] trying to accommodate this influx of requirements and get it ready for launch. But simply hiring more people was not going to solve the problem. And we know, as service designers, that stuffing business requirements into a UI is likely not going to create a good user experience.
- What we needed to do was go from this….
- … to this. Aligning all the teams to the product, because the product makes the connection between the policy and the user. The other teams needed to be clear on how their policy decisions impacted the product. But not only does everyone need to be aligned to the product, we all need to work in complementary ways. While our product team was working agile, we felt the effects when other key teams didn’t. The incremental development of an agile product needs to align with incremental processes of learning and decisions in policy development. This can be a tough thing to do, because being agile is not just about one software development team working in a different way
- Working in agile requires organizational change.. And in government, that’s a big task. So let’s recap our 3 lessons...
- Meg First, make the journey clear for users, even if large parts of this journey are out of your control. And ensure the design of the service reflects what this journey will look like
- Davis Second, Position yourself where you can have the impact you want - understand where you are in an organization and the impact that lets you create. Make sure you have proper alignment with your client to be clear on the scope of your work
- Meg And last, Align everyone to the product team. Make sure all the different groups or stakeholders are oriented to and connected with the product team so you are all aligned in what you are building. Look at how multiple agile teams can complement each other to work towards this common goal. Remember, being agile is not just about software, its a shift in how your organization works
- Davis And as we said at the beginning, failure can be the best driver for changing how an organization works. We know we’re in this state of growing pains trying to figure out how to do implementation and how to do service design within agile development. But we’ve been able to translate the pains we felt in this project directly into changes in our practice, quickly. This project has changed how we’re doing alignment with new clients so everyone understands the impact of service design. It’s changed how we as designers are working with developers and program areas, and this experience has given us the chance to take a fresh look at the BC Service Design Playbook and ask ourselves how our practice needs to continue to evolve to meet the needs of agile development. And lastly, it’s changed how we’re looking at ideal team composition and what kind of teams should be working in the CSI lab. In all of our projects, we are trying new things. It’s through these experiences on really complex projects where failures occur that we’ll all create better ways of working to make a government that works for everyone.
- Meg ….but to learn from failure you need to share your failure. You need to be vulnerable, own it, and talk about what went wrong. After this work ended, we could have shrunk away, moved onto the next project and never spoken the words “cannabis licensing” again. It’s only been through this vulnerability of admitting failure that our practice has changed for the better.
- Meg If you want to learn more about our team and the practice of service design in the BC government, check out gov.bc.ca/servicedesign. Thank you!