B2B SaaS
B2B SaaS
UX Design
UX Design
Dispatch Management - A redesign to create an SaaS module from an existing internal tool
Dispatch Management - A redesign from an internal tool to external SaaS tool
Summary
Dispatch Management was not a dedicated module, but, just a page built using existing sub-modules from different sections of the ERP system. Hence, it had all the right pieces (and some extra), but, lacked a holistic structure to it. It was not a mistake on anyone’s part, but, just an output of siloed requests being put together. But, when we planned to use it as a module to be used by our SaaS clients, I was clear that it needs a thorough redesign from usability and aesthetic standpoint.
Dispatch Management was not a dedicated module, but, just a page built using existing sub-modules from different sections of the ERP system. Hence, it had all the right pieces (and some extra), but, lacked a holistic structure to it. It was not a mistake on anyone’s part, but, just an output of siloed requests being put together. But, when we planned to use it as a module to be used by our SaaS clients, I was clear that it needs a thorough redesign from usability and aesthetic standpoint.
My Role
My Role
Lead UX Designer
Project Team
Project Team
Lead UX Designer (Myself)
Project Manager
Development Lead
Warehouse Users
Skills
Skills
User Research
Information Architecture
Wireframing
Prototyping
Understanding User Need and Data Availability
Based on internal user discussions and secondary research, I understood the key activities a dispatcher has to do -
Check the delivery drivers shifts and incoming drivers
Plan the deliveries for Scheduled orders
Handover (at start) and Collect (at end) the inventory and assets to Drivers
Collect Cash at the end of the day
To do these efficiently, they need to be aware of following information about the drivers - Shift Timing, Driver Status, Assigned area
I also looked into what data points are available across the sub-functions in the current version, which made it clear that there are many unnecessary elements on the page, hence, we eliminated those in the redesign
Based on internal user discussions and secondary research, I understood the key activities a dispatcher has to do -
Check the delivery drivers shifts and incoming drivers
Plan the deliveries for Scheduled orders
Handover (at start) and Collect (at end) the inventory and assets to Drivers
Collect Cash at the end of the day
To do these efficiently, they need to be aware of following information about the drivers - Shift Timing, Driver Status,Assigned area
I also looked into what data points are available across the sub-functions in the current version, which made it clear that there are many unnecessary elements on the page, hence, we eliminated those in the redesign
Creating User scenarios and Content structure
I worked with the business team to list out various scenarios and what information is needed for each. For example,
For a driver who is starting the shift, the dispatcher will need to see shift timing and assigned orders.
For a driver who is ending his shift, the dispatcher will need to see cancelled/on-hold orders and cash collected
To assist them in handing over assigned orders, we decided to show basic order details like ID, Zone and Timeslot on the page. This data was not currently available on the dispatch management, so it was brought in.
I worked with the business team to list out various scenarios and what information is needed for each. For example,
For a driver who is starting the shift, the dispatcher will need to see shift timing and assigned orders.
For a driver who is ending his shift, the dispatcher will need to see cancelled/on-hold orders and cash collected
To assist them in handing over assigned orders, we decided to show basic order details like ID, Zone and Timeslot on the page. This data was not currently available on the dispatch management, so it was brought in.
Designing the new interface
Structurally, I decided to use a 2-column structure, a scrollable list of incoming drivers on the left and information for the selected driver on the right. For each section, I had created empty states.
Structurally, I decided to use a 2-column structure, a scrollable list of incoming drivers on the left and information for the selected driver on the right. For each section, I had created empty states.
No design is final!
In the first iteration, I had created chunkier driver cards, which showed 3-4 drivers at max. But, after further discussion, it became clear that we needed to reduce the scrolling and show more results for Arriving drivers, as there could be 20+ drivers in the queue at some parts of the day. So, I created 2 additional variations. The final version now allowed to see 6-7 drivers without scrolling and made the section more compact.
No design is final!
In the first iteration, I had created chunkier driver cards, which showed 3-4 drivers at max. But, after further discussion, it became clear that we needed to reduce the scrolling and show more results for Arriving drivers, as there could be 20+ drivers in the queue at some parts of the day. So, I created 2 additional variations. The final version now allowed to see 6-7 drivers without scrolling and made the section more compact.
1st version
Final version
Further iterations (post-development)
Post development implementation, we added more functionalities on the module, which were being brought out from other modules like Cash handling. For these, there were modals, which I further redesigned and created a consistent design style to be implemented across the application over time.
Further iterations (post-development)
Post development implementation, we added more functionalities on the module, which were being brought out from other modules like Cash handling. For these, there were modals, which I further redesigned and created a consistent design style to be implemented across the application over time.
Impact
It is always great to hear from the actual user that a design change has made their work easier. Usability wise, we had eliminated unnecessary scrolls and unused data elements on the page. The modernised interface also reduced dependency on data tables, which allowed us to rethink similar upgrades across our ERP application.
It is always great to hear from the actual user that a design change has made their work easier. Usability wise, we had eliminated unnecessary scrolls and unused data elements on the page. The modernised interface also reduced dependency on data tables, which allowed us to rethink similar upgrades across our ERP application.
Created by Makrand Patwardhan