A portal that transforms LCOs highly manual process into a digital, self-serving printing solution.
I was a Product Design Intern at LCBO|next, an innovation lab for the The Liquor Control Board of Ontario (LCBO). As the sole designer, I designed and shipped LCO Bin Tag Printing Portal to over 450 LCBO Convenience Outlets (LCOs). For context, LCO’s are small “mom-and-pop” shops located in communities where residents do not otherwise have reasonable access to a regular LCBO store.
An example of an LCO
An example of a bin tag
LCOs rely on HQ's Print Services to mail shelf labels (also known as bin tags) every month. The printing shop was suddenly closing down and LCOs were scrambling to adjust to this sudden change.
A portal that transforms LCOs highly manual process into a digital, self-serving printing solution. Launched to over 450 stores, saving staff 15% of their time updating labels.
To better understand how our LCOs currently navigate the label printing process and the associated pain points, I conducted user interviews and gathered 3 major insights:
Working alongside the product manager, we devised a roadmap to iterate and launch 3 versions of LBT. Not only did this approach work well given our tight time constraint, but it gave me more opportunities to receive continuous user feedback and quantitative data to test assumptions and understand what needs to be addressed for the next launch.
V1 consisted of a search bar that retrieves results based on item number, name, or UPC. The user can choose a label size, click "print", and have a PDF download onto their device. This solution was by no means perfect, but it satisfied the users' needs while meeting the 2 week deadline.
V1 successfully met the fundamental needs for LCOs and was launched within 2 weeks. After launching V1, it was evident that the biggest piece of user feedback was regarding the waste of paper and time required to tediously print a separate page for an individual label.
“It seems like a waste of paper... ideally I want to print all my labels at once.”
Unlike V1 where a PDF of a single label is immediately downloaded upon clicking "Print", in V2, when a product is selected, they are added to a Printing List. When the user proceeds to print, all items in the list are printed so that multiple labels are printed on a single page. After a printing session, the printing list is emptied, and will then be archived in “Print History”.
Rationale: The Printing List is an integral part of the multi label printing feature which is a must-have according to user feedback. The way the Printing List works is similar to an online shopping cart which can be easily grasped and adopted by our users.
Iteration 1:
Print preview keeps users informed, reduces errors
No product image - hard to identify products
Infinite scrolling - long load times
Dual scrolling - not intuitive
Iteration 2:
Print preview keeps users informed, reduces errors
Product image makes products easier to identify
Pagination eliminates infinite scrolling
Jump to page elminates dual scrolling
Iteration 3:
No preview — had little value, cluttered the screen
“Download PDF” button label — more accurate
Input stepper — useful when printing multiple labels per session
Print History allows you to see all of the bin tags that have printed in any past printing session.
Rationale: Research indicated that most LCOs carry the same inventory year round. This means LCOs will be printing the same labels for most sessions. Viewing a print history allows them to find relevant labels easier.
V2 hit the mark with multi label printing, however, LBT didn't quite address the problem LCOs faced in terms of how they are working around price updates. As mentioned earlier, when LCOs couldn't receive updated labels in time, they would purchase blank labels and updated prices themselves. With LBT’s V2, LCOs were only able to print the live price of a product. To truly solve this issue, LCOs need to be able to print labels with upcoming prices ahead of time.
Previously, admin would email “Price Bulletins” to LCOs every 2 weeks to notify them of price adjustments. They look like this:
V3 implements a Price Update Portal available only to pricing administration where they can update upcoming prices on the LBT database.
On the user facing side, the current and upcoming prices are displayed for products that will experience price changes. This way, store owners can proactively print their labels with upcoming price changes.
Data collected from event tracking guided decisions throughout the entire design process. For instance, I noticed that new users were repeatedly selecting and deselecting items from their printing list. They were unsure if a product was successfully added to their list. They were expecting some form of feedback to notify them that the item has been added to their list.
I added a tooltip and badge to inform the user that the items they are selecting are being added to their list. This was something I never would've accounted for; quantitative data acts as a great indicator of our users' mental models.
Seamlessly integrates into workflow
Requires minimal effort from user
Requires a lot of engineering effort
Quantitative data is also a great indicator of success. The product manager and I tracked key performance indicators (conversion rates, weekly active users, activity per session, etc.) to determine the success of LBT.
After four months, my internship was coming to an end. Future features were set, however not implemented. These included:
It was up to me to know what to fight for, what to let go of, and how to make those decisions. For instance, my original designs included an onboarding experience. However, from a development standpoint, there simply was not enough time, so I opted for a PDF support guide instead.
It was very tempting to jump straight into design work when faced with such a tight deadline. However, I’m so glad I took my time to define the problem and understand my users. Without doing so, I would not have had a firm understanding of their technical literacy and would have designed a platform that they would not feel comfortable using.
Supporting version comparison visualization for construction specification to facilitate streamlined workflows.
Read case study ↗.png)
Equipping internal teams to scale with the the rapid growth of Mercury.
EmailLinkedin