Dropship is a tool that allows zulily vendors to ship directly to our customers from their warehouse or home. This is primarily due to the fact that some items are hazardous or too large in shipping size for our facilities to support.
Over the past couple of years, the number of vendors that use our dropship tool has increased exponentially; and our vendor specialists were struggling to keep up with change. Not only was our tool outdated, it was not reliable. In order to monitor our vendors to make sure all the correct items are being shipped, a redesign of the tool was desperately needed.
My role in this project was to recreate and fully redesign the overall tool. I worked closely with several vendor specialists and project managers to research, analyze, and design a dropship dashboard that catered to the primary user, the dropship vendor specialist (VS).
In my initial group interviews with the VSs, I noticed a common factor which was not being able to trust the data. This data includes everything from being able to track numbers, knowing when a purchase order (PO) is cut, and how long the vendor has to ship, and everything else that was necessary to do their job. But in order to understand the challenges they were going through, I asked them to hone in on a certain function or a specific data layout that they were unhappy with.
Although we cannot target all the needs and wants of each dropship VS, we highlighted certain goals that must be met in phase 1.
The main user for this tool is the dropship vendor specialists. Although other vendor specialists may use this tool, it will never be at the mass quantity of the first.
To understand and analyze the challenges and goals needed, we engaged the VS in group activities to see what kind of functions they would like to see, how the layout would look like, and do a voting system of what came out in top.
This gave me a clear indication to how the VS would like to see their data structure laid out and to understand more about what they do for their daily work. It was also good for them to communicate with each other to see what common issues and successes they have.
From these activities, I would then go over the top votes and compare their layout and mocks with mine. Do I see anything in common or differences? Is the workflow going to work in a certain situation? Why did one layout get more votes then another?
Understanding and being able to answer these questions helped me tremendous in the overall process. Not only was I able to understand what information needed to be surfaced immediately, but I was able to create a workflow that would increase productivity and save time cross departments.
The sitemap created showed the direct link between each pages and the functions that were allotted for each page. To summarize, a dashboard would be the center-fold of this project. Here we would have a top five vendors who have missed the estimated shipping time, and top five approaching. It would also include highlighted key stats that would dynamically change to which VS is selected.
Below that would be a robust table that pulls in all necessary communication, dates, time windows, flags, and more. Filters and a search function will be the heart of this table due to the vast amount of information it will hold. This allows each VS to quickly research and validate any updated information they would want, whether the vendor is in their oversight or a peer.
From there, secondary pages are leveled off and dedicated into displaying more granular information and primary functions. Pages are regarded towards vendors, all purchase orders, each product ID and order ID. Functions would include bulk upload, bulk cancel, add notes, and email vendor.