Dynamic Delivery Fees

BACKGROUND & RESEARCH

An MVP was launched to enable different delivery fees based on fulfillment center, delivery day of the week, and delivery time of day. The MVP replaced a time-consuming and highly-technical process involving spreadsheets, and had been in production for several months. This meant that the users had some actual experience utilizing the tool and were ready to give feedback for the next major release, which I was brought in to prepare for.

I spent a lot of time talking to the users about how they used the tool and what sort of tasks they attempted. One of their major points was that the view for the fee schedule was too confusing (it previously being a series of info cards organized into columns). Users also couldn't easily determine between custom or default fees, how (or whether) a fee overlapped with a potential customer incentive, and they found the small fee editor side panel overwhelming.

Additionally, there was a looming question of how the application would scale once there was the forthcoming requirement to manage different incentives for customers (to motivate them to choose low volume delivery timeslots).

SKETCHES & WIREFRAMES

The priority was to address concerns about the fee schedule view. Considering the problem of having overlapping, time-bound events, I sketched an idea based on the Outlook calendar. I worked this idea through several iterations, playing with color, shape, texture, and depth in order to keep each item on the calendar distinct yet related to each other. I showed multiple concepts to the users, developers, and product team in order to work out the best viable solution.

The final version of the fee schedule clearly distinguished between fee types, between fees and incentives, and highlighted concurrent events without sacrificing horizontal space. This was very important because the users had been worried about scrolling both vertically and horizontally and getting confused about where they were on the page and what exactly they were looking at.

I also refreshed the rules editor by expanding it to its own full page, and enabling users to managing fee rules line-by-line instead of all at once. This was important because managing the fee rules involves a working with a complex series of dropdowns, and mistakes were easily made. By "locking" each rule unless explicitly chosen to be edited, small adjustments could be made with confidence. I also added a small panel to display the default fees set for that particular location, for easy user reference and editing.

The users were excited to have an "upgraded" version of a tool of which they had become accustomed. They appreciated that the design was based on Outlook, which afforded it a certain familiarity that most people in corporations could probably attest to.

For a future iteration, I would focus on adding more detail to distinguish between different events, as well as adding depth to the fee schedule blocks for interactivity (and support editing directly on the screen). I would also want to enable the users to compare fee schedules between different fulfillment centers and copy rules between the two. Finally, I would modify the fee editor to support "smart" rules - suggestions based on sales volume data for that location, and overhaul the display entirely to feel less stark.