Scope

This store-chain was still working with a logistics system dating from the 90s. If it ain't broke, don’t fix it, right? Well.. the UI, even though very functional once you got used to it, was not very user friendly, especially to new users. Besides that the old software was costing more money every year to maintain. Thus the store-chain wanted to get rid of said old system and build a new one.

Within this new system I was focused on re-designing product logistic processes for physical stores. I will highlight this one feature and explain the design process from start to finish. The goal of this feature was to provide an updated process for sending products back to the warehouse of physical stores. Also included in the scope was for the head-office to request products back to the warehouse. The scope of this process was quite big; 100+ stores with packages being shipped multiple times a week per store. The designs had to use an existing design system, while at the same time additional components had to be build on top of this design system.

The process

After conversations with stakeholders about the initial scope, my user research and business analysis started in the physical stores. I went hands on with the current process to see with my own eyes how this process worked and why things were done certain ways. This gave me a great opportunity to talk to the employees using the old system.

With first hand experience from the previous process and stakeholder requirements in hand I proceeded to create wireframes. With these wireframes I returned to the stakeholders and users to get their input. After this second feedback round I introduced the developers to the wireframes. Getting their input early is important. It could happen that technological limitations cause designs to change or shift completely. Besides that I think it’s important for a sense of ownership to be included in discussions early on as a developer. In this case it was also important to include the developers early to understand the limitations of the design framework/system the company was using.

Feedback & limitations:
In this case there were some technical limitations. I have to describe this in an abstract way:The box that would contain the products later. In order to send it securely, it has to be sealed off. The moment we seal this box, we cannot make any more changes to the process; the shipment has been marked as send in the system. This meant that any changes the user is able to do to the shipment (adding/removing products, changing amounts, writing down codes to secure the shipment) had to be done before the box was sealed off and the shipment was marked as send. It had to be clear to the user that this was a point of no return in the process.

Another request from the stakeholders was to be able to combine multiple types of products in the same shipment. Unfortunately this proved problematic. The logistics partner involved, the warehouse, could not accept multiple types of products in one shipment. Thus a balance had to be found. We opted to keep the same type of products in one shipment, but make the system more flexible in creating shipments an dividing products between multiple shipments. This way, instead of sending one big shipment (like in the old system), it would be possible to send multiple smaller shipments, multiple times a week. This gave all parties involed more flexibility.

Incorporating all previous information into prototypes and designs, I entered a weekly (sometimes multiple times a week) feedback loop with stakeholders and developers. I would have loved to include the users here more actively, but that was sadly not possible due to the business structure of the company using the system. After some major changes I used prototypes to conduct user tests with end-users to gather some more feedback and see where they would get stuck. Based on this feedback I made some more improvements.

Challenges I faced included:
- A strict deadline for the developers to deliver the feature to the customer
- The current process was based on old software in use for 15+ years, what to keep, what to change
- Technical limitations, based on time but also based on what the internally used front-end components could and could not do
- Limitations from the design system I was required to use and operate within