As 'the ethical grocer', Farmdrop is an online grocery store that is focussed on high quality foods, sustainable packaging and environment-friendly delivery vans.
Farmdrop customers were missing products in their deliveries, analytics informed us it happened too often that orders were incomplete and business made it a priority to improve it. One of the key drivers identified for missing products are the mistakes being made during the picking process. Typically in food-warehouses customer orders are ‘picked’ by staff that take a trolley with a few crates (9 in our case) through aisles of products, pick products from shelves and place them into the correct customer’s crate. By using analytics we figured out it was during this process that too many mistakes were being made.
Being a startup, Farmdrop evolved their picking process many times, they started with a paper based system which was digitised onto tablets before I joined the company. The tablet showed step-by-step instructions to the hubber (warehouse staff) which products to pick, where the product is located and in which customer crate to put it. After completing the task the hubber would press a ‘next’ button on the tablet to move on to the next task. The system did not prevent the hubber from picking the wrong product nor stopped them when they put the product in the wrong customer crate. After making a mistake they would simply press ‘next’ and move on, being unaware of their mistake. The picking process is very monotonous and in such an environment human error can be expected.
To familiarise myself with the process I interviewed hub managers, observed hubbers and did several shifts myself to gain experience. It was during these shifts that I realised where mistakes were made and that the tools did not provide any validation to verify whether you did the correct thing or not. The interface was linear when the physical process was not. With that in mind I started to brainstorm about different technologies that could help us.
The first viable concept that made it to the prototyping stage was to replace the single ‘next’ button with nine ‘next’ buttons, one for each customer crate. Instead a digital button on the tablet, in the prototype these where physical push buttons connected through a Photon microprocessor, connected over wifi to a new tablet interface. The instructions for the hubbers were: “After you put a product in a customer crate, press the button in front of it to move to the next task.” This allowed us to verify the product went into the correct crate. When the wrong button was pressed we’d show a message alerting the hubber to amend it. The prototype worked really well and we were able to successfully identify and prevent products from being put into the wrong customer crates during tests. Unfortunately the solution was deemed not scalable for us to take to production.
The main thing we learned from the first prototype was that the process should allow for different options that we could then validate and not be linear. With that in mind I started looking at other technologies. Wireless RFID scanning could theoretically detect where the user’s hands would be, therefore detect what products are picked and in which crates they are put. A very interesting concept as the manual process of the hubbers wouldn’t have to change, they simply pick and the validation would happen silently in the background, only interfering when it goes wrong. After some short experiments we dismissed this idea as it could not accurately understand the user’s intent, I could accidentally wave my hand past some shelves or a customer crate and the system would think I picked the wrong thing even though I did not pick anything.
At the start of the project I did a competitor analysis to see what similar companies use in their warehouses. Most of them use a form of barcode scanning which was initially dismissed for Farmdrop due to cost and complexity. However with the knowledge we gained from the previous findings we now realised that it would provide a flexible and scalable solution to our problem. The physical buttons from the first prototype are difficult to scale as they require hardware to be installed in each location where we want an event to take place. The RFID solution is easier to scale as it only needs to have an RFID tag on each location, they are fairly cheap and can be bought as stickers. The downside of this solution is RFID is a wireless technology and events can be triggered without user intent. Barcode scanning gives us the best of both, scalability is as easy as printing stickers and an event is only triggered when the hubber actively decides to scan a barcode.
Giving it another chance I ordered a bluetooth barcode scanner and connected it to one of our tablets. Barcode scanners often can be used as external keyboards which made it very easy to create a prototype that could react to different barcodes being scanned. I arranged one of the trolleys from the warehouse to be send to our office. With nine customer crates, an Ikea shelving unit and a ton of barcode stickers I had completed my mini warehouse setup. This proved paramount in the iterative improvement of the concept and subsequent prototypes. It allowed me to test often and quickly iterate before testing again.
After a successful demo at our weekly show & tell I started to further improve the design through many small tests. The tests included both measured speed tests and usability tests. In the speed tests I measured the increase or decrease small changes had on the speed of picking. The usability tests where more focussed around users understanding the UI and feeling in control.
In total I test four different 'ring scanners' to and evaluated them on different properties such as scanning distance and speed, but also durability, available accessories etc. We ended up choosing the Zebra RS6000, which is really quick and has a large range of available accessories, making it a good product for us to use in our hub.
After various demos and sessions with both stakeholders and hubbers hardware was ordered and implementation started. The implementation when very smoothly without many hiccups, I did my best to document the solution well and write very descriptive tickets. The addition of a fully function prototype also helped in communicating to engineers. The new feature was released as a Beta app alongside the original application which was used for two weeks to find any remaining issues. After the Beta period the old app was replaced.
We have been monitoring our accuracy levels before and after the release. The total item accuracy started at 99.5% before we introduced the scanners. The target was set at 99.7%. When we released early April the accuracy improved to around 99.75%.