LCBOdesk
Help LCBO|next improve
By Amanda Du (Product Designer)
Problem Overview
Being a part of the innovation lab of LCBO, it was always our mission to be proactive and sought out new and innovative ideas. At the beginning of our term, the team noticed an issue: currently customers who report issues or suggestions are likely to blindly email or phone lab members which result in cluttered inboxes. And occasionally, there would be communication lost along the way – sometimes the information would come from our grocer customers, to our HQ staff, through our supervisor, and then finally to us. This inconsistency in issue tracking causes ideas and words to be lost in translation.
We knew something had to be done. We needed to build the trust between the LCBOnext lab and our customers.
Design challenges
How might we centralize feedback reports from our customers and eliminate miscommunication with our stakeholders?
How might we help the LCBOnext team efficiently solve these incoming requests and build trust with our stakeholders ?
Deliverables
Responsive Web-app
Customer facing widget
Duration
2 months (July 2021 – August 2021)
Team & Roles
-
Suvaena Laventhiran (Product Manager)
Amanda Du (UX/UI Designer)
-
Chamod Gamage (Full Stack Developer)
-
Kevin Tong (Full Stack Developer)
SCOPE
Being the only product designer, I knew I needed to really advocate for our users during this phase of the project. In order to really understand our clients and validate our assumptions, I decided to conduct several user interviews with our HQ staff and the IT Experts of LCBO.
Understanding our users – User Interviews
A big issue we noticed was that customers are either wasting their time contacting the wrong people and being redirected multiple times or they shy away from actively sharing their concerns with the LCBOnext team when they encounter issues. We wanted to validate whether or not the our clients felt frustrated over this issue.
Another assumption that we wanted to validate was the idea that customers were always left in the dark after reporting an issue – there was no way for them to track the status of their issue and see how long their issue would be resolved. As the lab, we assumed that this was a major pain point.
After speaking to our clients, lot of our assumptions were validated – we were correct. For instance, the frustration that our grocer partners feel when they are left in the dark about a specific issue is very real. After this, we were able to really solidify our goals for this project.
Product Planning
Finding the Gaps – User Journey Mapping
Once we had a better understanding of our users, I then used this information and created some user personas and journey maps. Long behold, we noticed that some touchpoints between the lab and the customers were completely nonexistent! I knew immediately that this was something we needed to target.
Now that we empathized with our users, and finalized the project scope, it was time to finally start the designing.
Design Decisions
As a result, we decided to create a widget that simply ‘sits’ on our products. This way, users can interact with the widget without leaving the application and comfortably return to their task once they completed their report.
Trial and Error – Design Iterations
On the customer facing widget, my creativity was limited – there are only so many ways one can design a form/help application. The main functionality we wanted on the widget was to allows the user to access all of their previous submissions (which shows them the lab's progress with their issue), and gives them the option to submit a suggestion or an issue questionnaire.
But here is where it gets more interesting! For the admin side, I was able to explore so many different ways of displaying information and really got to practice visual design. Here are the iterations that I needed to go through to get to my final design:
This was my first draft. To just test the waters, I wanted to try a very simple long ticket design with just the MVP functionalities such as a search bar & sort/filter features.
Although I really liked the branding, visually this did not give our team the information it needed. There was too much white space that could have been used for valuable information. It did not fulfil the design challenge.
This was attempt number 2. I wanted to get creative explore different ways I could present the typical ticketing system.
I tried to design some sort of digital filing system, but then I realized that the tab feature would be redundant as the sort/filter features do the exact same thing!
This iteration was when I started feeling more confident about my designs. I still found the tabs to be redundant, however I did come to appreciate the taller tickets compared to the longer ones.
These newly designed tickets tells the LCBOnext lab everything we need to know in one glance – it goes perfectly in hand with our design challenge!
And this is the final wire frame!
After receiving feedback from my peers and supervisor, I knew that this design was the most successful. Unlike the other designs, this one did not have nearly a third of the space unused and empty. However nonetheless, it is still very clean and has plenty of whitespace to balance the information.
I took out the tabs due to redundancy, and swapped out the long tickets for short but taller ones to decrease the amount of wasted whitespace.
Now we have an extremely well organized central hub of our customers' reports! This is where the lab can efficiently sort through and fix all the reported issues in a timely and transparent manner.
It was time to start prototyping and really polishing my designs.
The first thing we needed to decide was how to present LCBOdesk to our users. The first step we took was research existing solutions, such as other support desk applications to see what the industry norm was. To our surprise, none of them were ideal for our situation.
What we disliked about these apps was that there’s a lot of barriers for the user. In order to use these services, one must leave the page and create an account with the help desk platform. This can discourage users from reporting feedback at all. We wanted to make sure that wasn’t the case for LCBOdesk.
Widget vs Separate website – Customer Facing
There are two components that make up the LCBOdesk app: the customer-facing widget used by HQ staff and our grocer customers and the staff-facing app used by the LCBOnext lab.
FINAL Solution
LCBOdesk presents LCBO|next and its customers with a new opportunity to streamline the way they seek help. Presented in a widget primarily for desktop web applications, users are presented with a simple questionnaire to track concerns. The centralization of receiving, tracking and monitoring bugs/suggestions/feedback will help us further engagement and strengthen our support experience to stakeholders and customers in a more efficient manner.
*this widget is displayed as an mobile screen for the sake of this article – in real life application it is a widget (as seen in Design Decisions section)
Customer-facing widget: LCBOdesk
LCBOnext Admin Portal
From the perspective of the LCBOnext lab, LCBOdesk has an admin side, a dynamically corresponding side of LCBOdesk. This web application is where the lab members can view all questionnaires submitted by our customers and clients. Through this, the lab will also be able to manage all of our tickets more efficiently, which in turn will help us build a trusting relationship with our customers.
The User Acceptance testing
This one of the last things we were able to accomplish during our term. We were able to get feedback from our grocery team, supervisor, and our team. This wasn’t an extremely formal user testing, but rather a causal UAT. We just wanted to get an idea of how users interacted with the space, and what feature they are interested in adding.
Aftermath
Although the designs were done, tested, and iterated on, my job wasn’t over. There was still documents to be made and designs to be handed off. Soon after I wrapped everything up, I made a design specifications document for the developers. I also held a design review session where the developers were able to challenge my design and pick any edge cases they thought I may have missed.
And hey! I also created this – I wanted to share our work as a lab to anyone that is interested in applying or just learning about what we do as a lab :) It’s always a great idea to document your work, every step of the way.
Learnings & Takeways
Through this project, I was able to experience the end to end design experience; from product planning to the prototyping, it was an amazing journey. I learned so much about scoping and how fast paced decision making when it came to prioritizing. I can now carry my newly learned critical thinking skills to my next opportunity :)
If I were to do this again, I would definitely work faster, so I’d have more time to iterate on the feedback I got from our UAT sessions. There were many new features that our developers suggested us adding to make their work a lot more efficient. Unfortunately, with the short time frame, I wasn’t able to get that done. But on the bright side, that leaves something really interesting for the next cohort to take on!
You've made it this far 💚
Thanks for reading!
Over the course of our term at LCBO|next, we were lucky to be able to work on several impactful projects that made customers’ and clients' lives easier. LCBOdesk was just one example of the way that LCBO|next works - test, learn and iterate. Our term took place under unusual circumstances, but as an organization, and as a lab, we were able to keep things running smoothly by maintaining a focus on the concerns of our customers and staff. Thanks for reading — if you want learn about this project through a Product Manager lens, check out Suvaena's case!