Receiving Large Deliveries
Lightspeed Commerce is a retail management software provider. I lead design for the inventory space, and previously designed across the product's e-commerce, POS, and reporting areas – just to name a few. Lightspeed commerce acquired Vend in 2021.
When new stock arrives in a retailer’s store, it’s crucial for that stock to be counted and recorded in-app to keep inventory accurate. However the existing flow had not been touched since initial build and was inconsistent with the design system and it was painful to manage deliveries over 800 line items.
GOALS
💼
Business Goal
Driving retention by increasing trust in X-Series as an easy to use, accurate system of record.
💁🏻♀️
User Goal
How might we help cashiers and store managers record loss so they can keep inventory numbers accurate
💁🏻♀️
User Goal
How might we help business owners understand why inventory is being written off so they can act to reduce loss
💼
Business Goal
Drive retention by increasing trust in X-Series as an easy to use, accurate system of record.
💁🏻♀️
User Goal
Easily count and record the receiving of deliveries of any size.
🎨
Design Goal
Update the UI to be consistent with the design system of the rest of the product.
🔧
Engineering Goal
Migrate from Angular to React as Angular was "end of life".
PROBLEM
When new stock arrives in a retailer’s store, it’s crucial for that stock to be counted and recorded in-app to keep inventory accurate.
The existing flow was inconsistent with our design system and to… The existing flow for me, editing order details, finding products in the list to record QTY was … inconsistent with our design system, and UX, and prone to sync/upload failures especially for large deliveries of stock.
To increase ease of use and drive accuracy, our team re-designed the in-app receiving workflow, making receiving new stock into Lightspeed faster, easier, and more reliable.
CURRENT USER JOURNEY MAP
Mapping the current user journey helped us understand the different ways users count and record new stock arriving in store, and the needs and pain that accompany those different workflows.
Easily find a product in the list
Some merchants work their way down the order, entering QTYs as they count the products. These users don't have much trouble navigating the list as they just scroll down it. If users mark QTYs off a packing slip enter all the QTYs in bulk later on they might work down that list or need to search to locate a product in the list to edit the QTY.
If users are pulling products out of boxes and counting products as they're pulled out, these users also need to be able to jump around the list easily to record the QTY.
What if the product is not in the list?
Merchants might receive products that were not originally ordered, or ordered later. These products need to be added the list and a QTY recorded against that product.
UX Needs
-
Receive a product already in list
-
Add new product not in list and add to bottom of list
-
Data entry easily
-
Scan easily
-
Go down list and tab through
WIREFRAMES
UX CHALLENGES
Inaccessible search bar (current design system)
When orders are too long, the search bar that usually live at the of the order (in our design system) dissapears and is unaccessible until the entire page is loaded. How do we make
SOLUTION DISCOVERY: IDEAL USER JOURNEY
Flow 1: Recording a single loss event
Flow 2: Recording multiple loss events
Where should users record loss?
Consider the conditions around recording loss: Who’s making the adjustment? When are they making it? How many adjustments will they make? Options: Products Page, Inventory Counts, or the Stock Control page?
Where should users view loss?
Considered other examples of entities being created, viewed and reported on. Sales for example are recorded in the Sell screen, records of sales are viewed in Sales History, and users gain insights about sales in Reporting. Following that same pattern, records of loss should be viewed in a product history of sorts for which we have an Inventory Movements page for each products, and users can gain insights about loss in Reporting (future work).
SOLUTION DISCOVERY: WIREFRAMES
Wireframes to test smoothness of flow and feel in context.
Adjustment page in Inventory area
Best suited for a manager who is recording loss in bulk. They’re working off a list or pile and doing data entry and want to save that and update inventory.
Products page 🏆
Best suited ad-hoc adjusting of one product at a time and is scalable for bulk adjusting in the future.
You find a broken product > You’re holding it on your hand > Look it up on the Product page > Adjust inventory / record loss
Decided on the Products page as the flow was solution was a slimmer slice to design and delivery, optimised for time in value rather than time to value, could learn after release and iterate based on learnings. Decided on Inventory Movements to display movements.
SOLUTION DISCOVERY: HI-FIDELITY DESIGNS
Iterating on details in high fidelity
Information architecture: how do we break up the steps?
Entering hi-fis I found myself considering some foundational information architecture questions. Weighed up 2 or 3 steps. I decided on a 3 steps for review stage and accuracy rather than less steps but was actually hard and increased chance of mistakes
Negative quantity field
How to display a negative number, compared to “enter QTY” elsewhere, do we get them to type the -, would they try to? What’s consistent?
USER TESTING
User testing usability risks
Our quantity fields have never allowed negative numbers however this quantity field was trying to communicate the reduction of a product.
User tested to validate the assumption that users could comprehend and be able to use the negative quantity field 🎉
-
Users also better understood the 3-step modal flow as it was easier to adjust and review a focused list of products especially when some products contain 100 variants (colour and size) 🎉
FINAL DESIGNS
RESULTS
-
Upon soft launching the feature we saw early and organic adoption for this feature.
-
(Get updated numbers) As of today, we’ve seen over 900 merchants tracking adjustments.
-
6k adjustments were made, multiple times by each user (not just testing it out once)
-
Leading cause of inventory adjustments is internal use
“THIS UPDATE IS GREAAAAAAT!”
Owner
Homewares, Singapore