Project
Countr : Automated inventory & waste management
An example of design thinking but also the value of ethnography.
May 12, 2018
May 12, 2018
4
minute read
Design thinking
Product strategy
CLIENT
Vivonet
SERVICES
Product Strategy
ROLE
Lead Designer
Project summary
Countr was an experimental project for Vivonet where we wanted to improve the speed of inventory management, automate how it was pushed to the cloud, and improve the accuracy.
A quick note, for most of our customers taking inventory was a duplicative process that typically involved a printed spreadsheet, a writing tool, undistracted time, and then re-entering from the printed sheet to an often less than user friendly digital interface. Apart from the duplication of effort, this was a time consuming effort that was often riddled with interruptions from staff and customers.
A large part of inventory management is also the prevention or at the very least awareness of theft and waste. Vivonet set out to change the way our customers recorded inventory with two KPI’s in mind: Speed & Accuracy.
Exploration
There are a couple of core concepts as well as commonalities that came up when we began to consider our inventory management tool. Some were just logistics, like is a tablet durable enough to handle the day to day? There are tough cases for that. What happens in 0 connectivity environments, like walk-ins or freezers? Others were more esoteric, like how easy does it have to be, what do we do about human error, how do we account for user management?
With all that in mind we started with what we knew, like every store is unique, so we could only plan on basic truths, coolers/walk-ins keep things cold. Freezers keep things colder. Inventory moves at the speed of business, literally, like the number of let’s say burgers changes at the exact same frequency that you are making burgers. You get the idea.
So we took volatile items and recommended count times when they were less volatile. We added custom keyboards that were specific to the task at hand. We added inline calculation tools to help reduce human error. We created recommended travel paths to expedite the time spent in and out of closed areas. If we noticed counts in one area didn’t align with best practices we alerted the manager. We created a system that would reduce error as much as humanly possible.
We didn’t stop there though. We also wanted this to be the managers little red book of excellence, so we even included non inventory check lists to help ensure a smooth shift. We even threw in cross store gamification and leaderboards.
There are a couple of core concepts as well as commonalities that came up when we began to consider our inventory management tool. Some were just logistics, like is a tablet durable enough to handle the day to day? There are tough cases for that. What happens in 0 connectivity environments, like walk-ins or freezers? Others were more esoteric, like how easy does it have to be, what do we do about human error, how do we account for user management?
With all that in mind we started with what we knew, like every store is unique, so we could only plan on basic truths, coolers/walk-ins keep things cold. Freezers keep things colder. Inventory moves at the speed of business, literally, like the number of let’s say burgers changes at the exact same frequency that you are making burgers. You get the idea.
So we took volatile items and recommended count times when they were less volatile. We added custom keyboards that were specific to the task at hand. We added inline calculation tools to help reduce human error. We created recommended travel paths to expedite the time spent in and out of closed areas. If we noticed counts in one area didn’t align with best practices we alerted the manager. We created a system that would reduce error as much as humanly possible.
We didn’t stop there though. We also wanted this to be the managers little red book of excellence, so we even included non inventory check lists to help ensure a smooth shift. We even threw in cross store gamification and leaderboards.
the result
From a visual design perspective it was really simple, sometimes simple is good. From a product design perspective it was a massive effort. It was a ton of fun to work on and a joy to demo. I would bring in some Vivonet swag, and hand out iPads to execs and ask them to count the swag, and even asked them to make mistakes to proof out our intelligent error handling. We introduced it to several customers, we started with the ones we had really strong relationships with.
We moved on to some that we were walking a thin line with. The results spoke for themselves. We reduced inventory count times by 40%. We increased accuracy by 12%. We even reduced waste by 23% for a particular customer of ours and saved a relationship.
final thoughts
So here’s the deal, and I’ve neglected mentioning this until now. We (Vivonet) were partnered with JJ Bean. They had a store across the street from our offices and we used that as a test playground. The product team could run down and get coffee and do some usability tests and demo new shit we were working on. It was great. Testing there was excellent.
We then tried to shop this product with other customers. Wendy’s loved it. S’barro loved it. Then we went to Popeye’s. We did a dog and pony show for the executives and they all loved it. All but one. He invited us to his store. No matter how we protected the device it was not going to be a good fit. If you ever get to see a chicken shop do inventory it’s messy. Like fucking stick your hands in a vat of chicken pieces and pull them out one at a time covered in gelatinous bloody goo messy.
We needed to rethink a couple of things. I needed to rethink a couple things about how I built, more importantly who I designed for. Another life lesson learned not through failure per se but through lack of understanding. We often find ourselves doing the what, if we’re lucky we’re chasing a why, but where and who are soooooooo crucial. We, I, need consider all the W’s when we start projects.
final thoughts
The result
So here’s the deal, and I’ve neglected mentioning this until now. We (Vivonet) were partnered with JJ Bean. They had a store across the street from our offices and we used that as a test playground. The product team could run down and get coffee and do some usability tests and demo new shit we were working on. It was great. Testing there was excellent.
We then tried to shop this product with other customers. Wendy’s loved it. S’barro loved it. Then we went to Popeye’s. We did a dog and pony show for the executives and they all loved it. All but one. He invited us to his store. No matter how we protected the device it was not going to be a good fit. If you ever get to see a chicken shop do inventory it’s messy. Like fucking stick your hands in a vat of chicken pieces and pull them out one at a time covered in gelatinous bloody goo messy.
We needed to rethink a couple of things. I needed to rethink a couple things about how I built, more importantly who I designed for. Another life lesson learned not through failure per se but through lack of understanding. We often find ourselves doing the what, if we’re lucky we’re chasing a why, but where and who are soooooooo crucial. We, I, need consider all the W’s when we start projects.
From a visual design perspective it was really simple, sometimes simple is good. From a product design perspective it was a massive effort. It was a ton of fun to work on and a joy to demo. I would bring in some Vivonet swag, and hand out iPads to execs and ask them to count the swag, and even asked them to make mistakes to proof out our intelligent error handling. We introduced it to several customers, we started with the ones we had really strong relationships with.
We moved on to some that we were walking a thin line with. The results spoke for themselves. We reduced inventory count times by 40%. We increased accuracy by 12%. We even reduced waste by 23% for a particular customer of ours and saved a relationship.