case study
A virtual inventory project
Roles: UX Researcher, UX/UI Designer
Challenges: Development from scratch, input data changes, outdated devices, no direct communication with developers
Introduction
To conduct annual inventories, employees at Leroy Merlin stores count available items on the sales floor and compare the balances with the system.
To streamline this process, we developed a mobile app for corporate Android phones. Employees on the sales floor and in the warehouse used the app to enter item counts and compare them to the values stored in the database. The app alerts employees to discrepancies and allows them to search for missing items or correct values in the system.
The results of the inventory count were checked by store supervisors who either accepted or rejected them. If the total shortage in rubles was significant, a second round of counting was required. Minor discrepancies were typically accepted as they were.
To streamline this process, we developed a mobile app for corporate Android phones. Employees on the sales floor and in the warehouse used the app to enter item counts and compare them to the values stored in the database. The app alerts employees to discrepancies and allows them to search for missing items or correct values in the system.
The results of the inventory count were checked by store supervisors who either accepted or rejected them. If the total shortage in rubles was significant, a second round of counting was required. Minor discrepancies were typically accepted as they were.
Supervisors primarily worked in the store office and used desktop computers. We created a desktop web application for them to process inventory results.
With the app highlighted the huge losses that needed to be re-counted, we saved about 25% of labor time needed for the annual inventory check, and about $30,000 per year both from labor costs and losses prevented.
I was involved in the process as a product designer. Together with the product manager, we formalized all the nuances of the process, which I then put into an interface and tested with users in stores. To do this I also went out to do inventory on the night shift — and it was an interesting experience.
With the app highlighted the huge losses that needed to be re-counted, we saved about 25% of labor time needed for the annual inventory check, and about $30,000 per year both from labor costs and losses prevented.
I was involved in the process as a product designer. Together with the product manager, we formalized all the nuances of the process, which I then put into an interface and tested with users in stores. To do this I also went out to do inventory on the night shift — and it was an interesting experience.
The beginning
Initially, the plan was to integrate inventory scenarios and features into the Outage Management web application. It was deemed logical to improve the existing main application, which is used to monitor and update the number of items in stores, rather than creating a new one.
We went through two iterations for the functionality implementation, where the first one was a draft, and the second one was a correction after a more in-depth research of the process and reworking of some hypotheses about data presentation.
We went through two iterations for the functionality implementation, where the first one was a draft, and the second one was a correction after a more in-depth research of the process and reworking of some hypotheses about data presentation.
Some of the initial screens. Click to enlarge
Upon further research, several problems were discovered:
Considering all of this, it was decided to build an inventory project as a separate, stand-alone web app, that will have only the information that the user needs.
When the decision was made to build a separate inventory project, a general user flow for the new application was developed.
- Stock complexity. The stocks at Leroy Merlin were complex, with a wide variety of areas and positions. During the inventory, sales floor employees counted only one area, while others were counted separately by different people. The instructions about what to count in one case and what not to count in another were confusing, and displaying all the stock was not necessary for everyday work but could be confusing for a once-a-year event like inventory.
- Database and soft legacy. During the inventory process, we faced difficulties in developing the inventory as an enhancement to everyday work due to the need for working with data in a different way. Transferring data, setting time limits, and turning on/off functionality created additional challenges. Therefore, it was easier to work with the inventory database and make corrections to it separately from everyday work schemes.
- Design system processes. A new design system was scheduled to be introduced, and it was decided after a discussion with the design department leads that the inventory project could be used as a pilot for the new design system. This would allow for the development of new components and facilitate the transition process.
- Outdated devices. All employees are provided with work devices that connect to internal services, but unfortunately, these devices are outdated and slow down work processes. This leads to employee frustration and hinders productivity. To improve the situation, we needed to find ways to optimize data processing and make the devices more efficient.
Considering all of this, it was decided to build an inventory project as a separate, stand-alone web app, that will have only the information that the user needs.
When the decision was made to build a separate inventory project, a general user flow for the new application was developed.
General mobile app user flow. Click to enlarge
Subsequently, we developed a new set of mockups while simultaneously receiving process updates regarding the forthcoming inventory, such as time limits for each stage and data storage requirements.
At first, we intended to maintain the display of the stock structure since it could offer extra information to the user in certain scenarios. However, it was later revised and made more intricate, which rendered the system too complicated for our specific use case. As a result, we opted to shrink it since preserving the structure for occasional use cases was not as essential, and simplifying it significantly enhanced the screens and flow.
At first, we intended to maintain the display of the stock structure since it could offer extra information to the user in certain scenarios. However, it was later revised and made more intricate, which rendered the system too complicated for our specific use case. As a result, we opted to shrink it since preserving the structure for occasional use cases was not as essential, and simplifying it significantly enhanced the screens and flow.
Finalizing mockups
Ultimately, we finalized all the requirements and tailored the new version accordingly, followed by conducting a brief user testing with a prototype, and making necessary adjustments to elements such as item cards and addresses.
After preparing a description of the specific molecules' states and adding more comments about use cases, I handed over the project to the developers.
Elements and screens' conditions. Click to enlarge
Desktop application
The development of the desktop application began after completing the mobile app phase.
While the mobile app was designed for sales floor employees to conduct item counts, the desktop app was intended for store supervisors to review and approve the initial counts and request re-counts if necessary. To start the development process, user scenarios for the desktop app were identified.
While the mobile app was designed for sales floor employees to conduct item counts, the desktop app was intended for store supervisors to review and approve the initial counts and request re-counts if necessary. To start the development process, user scenarios for the desktop app were identified.
Desktop scenarios for supervisors' app. Click to enlarge
The approach we took for the mobile app was to focus on developing the flow, rather than the scenarios, as it had a more complex flow, and nearly three scenarios, which was pretty easy to keep in mind. However, for the desktop app, the situation was different, as it had many scenarios, but each one had a simple flow, such as "click on the button => move a count to another tab". Therefore, there was no need to draw out the flow itself.
Then I began designing the individual screens for the desktop application.
Then I began designing the individual screens for the desktop application.
Results
We were able to complete the project within the deadline, but, unfortunately, were unable to conduct additional user testing.
With the mobile application, sales floor employees were able to perform the inventory more efficiently, and we were able to reduce the number of future corrections during the period after the inventory by 7%, which is significant considering Leroy Merlin is a large hypermarket chain with numerous employees and items for sale. The time saved and potential money saved from these corrections is substantial.
Furthermore, the desktop application for supervisors allowed them to initiate recounting at an early stage, which improved the rate of corrections, but we do not have the exact number.
With the mobile application, sales floor employees were able to perform the inventory more efficiently, and we were able to reduce the number of future corrections during the period after the inventory by 7%, which is significant considering Leroy Merlin is a large hypermarket chain with numerous employees and items for sale. The time saved and potential money saved from these corrections is substantial.
Furthermore, the desktop application for supervisors allowed them to initiate recounting at an early stage, which improved the rate of corrections, but we do not have the exact number.
