Codeshelf offers a suite of warehouse automation products. It’s core product is an adaptation of what’s refered to in the industry as a “pick to light system.” The system is used to help warehouse workers pick multiple items for multiple orders at one time. Workers at a warehouse can follow lights on shelves and carts to easily see which items to pick and how many.
While the workers are picking, management is able to monitor activity to make sure the orders are on track for the day.
I’s also possible to review data on the operation in order to improve the warehouse’s processes.
Floor managers can use the mobile app to help workers get through various issues that may come up as they are picking orders.
Codeshelf is a small startup of 24 employees. I joined the company as head of the design studio. The founding team and I were adamant about making sure our product development process was design led. We also focused on creating a culture that encouraged all employees to utilize design methodologies. I worked with the CTO to define a version of the design process that would work with the limitations of the startup and mesh well with the terminology and processes used by the existing engineering team.
We took inspiration from our research on Toyota’s continuous process improvement (CPI) philosophy. While American auto manufacturers were focused on keeping a production line moving, Toyota realized that it was more effective to stop at the moment of an issue and identify the root cause. This was followed by empowering the workers and managers to collaboratively solve the issue. The result was a longer term, more effective solution to inefficiencies in the production line as well as more fulfilled and emotionally invested employees.
My team engaged with every aspect of the product line across UX, ID and IxD. I’ve compiled a number of case studies to show different aspects of our process. Two of them are below, I will be posting others as articles and linking them here.
Case Study #1: Exceptions
This project focuses on research and generating actionable user stories from the insights.
While workers are picking, there are a number of exceptions and edge cases that can slow down the work or affect the accuracy of an order. In an environment where workers pick rates are measured down to the second, it’s very important to keep them moving through orders. I worked with a number of different users in the system to identify the most common issues. There were some obvious quick fixes we could implement as new features but we knew we needed to dig deeper to come up with more impactful solutions.
I started by interviewing and observing people who use the system as well as internal Codeshelf employees who are very familiar with the industry and similar products.
Once we identified a number of major areas of pain, I organized a meeting that resembled an abridged version of Google Venture’s Design Sprint. I would facilitate this meeting biweekly for various projects. This particular project would later end up breaking down in to several other projects which were approached similarly with more granularity.
For the sprints, I would bring a group of employees in to our conference room where we would review research and insights. The group included co-founders, sales representatives, and engineers who touched the project. Since a few of us collectively filled the roll of product manager, I would designate a product owner to the group, usually one of the co-founders who had most contact with the specific problem.
One of the exercises was to break down the process of running the system. We then carved out areas within scope, where we identified exceptions. We collectively wrote user stories based on the various people involved. Example: Worker, Floor manager, IT, Codeshelf support staff etc. We reviewed these and selected stories that we considered vital to our MVP. In following sessions, we either tried to solve a specific story or set of stories, or we planned a project which would be handed off to a team of designers and developers.
Several months into this project we ended up with entire desktop and mobile tools that gave managers substantially more transparency into how our system and their warehouses were operating.
Case Study #2: Shorts
Here is an example of one of the many insights and solutions generated from this project.
While picking, a worker is instructed to add a certain number of items on to a cart. If there are fewer items in stock than the instructed number, some additional steps need to be taken. When observing the workers, I noticed that they were logging shorts by writing them down on a piece of paper that was taped to the cart. At the end of the day, the manager could review the list and make adjustments to the inventory, then notify customers. This meant that a number of orders that day would go out partially filled and inventory would go un-replenished for the rest of the day.
User stories:
As a worker, I need a way to record shorts quickly and accurately so I can limit my interruptions while picking.
As a manager, I need to know when a short has occurred and the nature of the short so I can address it.
The quick fix was a change to the hardware interfaces flow. We added a feature that allowed the worker to notify the system that they were unable to pick the intended amount. They could scan then change the number on the controller to record the amount that they had actually picked. A manager then had a more reliable way to handle the issues at the end of the day. The workers had an easier, faster way to log shorts.
This did not solve the root cause of the issue at the moment it occurred. We posed this question: What if the worker could notify the floor manager of un-stocked items but continue to pick items without missing a beat? The manager could work to have the items replenished from the back of the warehouse. She could also intercept the orders with shorts before they were shipped out and make sure they were completely filled.
I paired with one of the senior developers for a number of weeks, in order to work on a testable solution. We elicited feedback early and often, reviewing concepts with the internal team as well as with our customers. Our final results on this project also tied in to a number of other stories that came out of the exceptions project. These stories included: The need to help locate the workers so managers could go assist them; The need to see if worker’s rates dropped so the manager could proactively unblock the worker.
We worked through hand sketches of the interfaces and storyboards. We also used InVision to create linked prototypes of the features that were reviewed by users before the feature was fully developed.
