Jul 2020 – Aug 2021

WM Maps

Redesigning a decade-old operational tool used by WM’s route managers and dispatchers

 

Deliverables

High fidelity prototypes, developer specs

 

About Maps and the Execution Tool

At WM, the route managers, dispatchers, and drivers are the people who keep the business running. There is no WM without them. And yet, they’ve been using tools that have never seen a designer in their lifespans, and haven’t been updated for a decade or two.

A screenshot of the old tool used by route managers and dispatchers

Enter the Service Excellence workstream — a team created to products like the Execution Tool, a new platform for our route managers and dispatchers.

I was the co-product designer on this workstream. While I’ve worked on every feature within the Execution Tool, I led both the user experience and visual design of the portion referred to as Maps. Thus, this case study will focus on Maps specifically.

A mock of the new tool we’ve created

Let’s get into it.

Problem

As mentioned earlier, it has been a really long time since the Map tool has ever been updated. Its many issues can be summed up into these two points:

  1. This tool had a million different ways of doing one thing, which made it infinitely confusing and complex.

  2. The tool was a visual nightmare — lacking readability, white space, intuitiveness, and accessible features.

 

Discovery

To better understand WM’s business and our users, my co-designer and I sat in daily meetings to pick apart the current Map with some of our route managers. We learned both about the issues they have with the current tool as well as things that they wish they would be able to do.

 

Our Users

Route managers are in charge of building the routes that the drivers will use to complete their pickups and dropoffs. On the Map, they would need to be able to visualize where customers, drivers, container yards, and disposal sites are. They would also need to be able to create and adjust routes.

 

Rosie the Router’s User Journey

Design Principles

To guide our process, we established a set of design principles that would help us ensure that we weren’t repeating the mistakes of the previous tool.

  1. Accessibility

    A lot of our users started work before the sun rose. Some were color blind. Most used huge monitors that made reading small fonts very difficult. We decided that our design system needed to emphasize accessibility.

  2. Seamless integration

    Not only are there three different parts of the Execution Tool, but there are many different platforms that the field operations use to drive different types of data. The Map needed a consistent experience with the other features and platforms.

  3. Simplicity

    Our tool needed to be created so that anyone would be able to understand what’s going on. This would help reduce training efforts and transition pains from the old tool to the new.

 

Ideation

The three different features of the Execution tool are the Map, the Gantt, and the Tickets list view. All three needed to have a majority of the same functions. Additionally, these three products would need to be able to interact together, cross functionally.

For example, users who liked to manually route would use the Gantt because it provided the most information to easily be able to do so.

Other users who would rather trust the assistance engine could route more quickly on the Tickets list view.

And the Map was meant to bridge the gap between those two.

We used sketches, wireframes, and tons of brainstorming sessions to explore how. Here are some of our best ideas.

 

But what if we just opened the Gantt window to route instead of doing it on the Map at all?

Maps loses a significant amount of its value, and users will lose their progress on Maps if they go to another screen.

 

 We can drag some tickets from the side panel onto a driver to assign it to them. That’ll open a single Gantt route (i.e. an editing environment) that’s integrated into the Map.

But this is hard to develop, and you’d only be able to edit one route at a time.

 

We can follow the simplicity of routing on the Tickets view. We can select the tickets which will open a modal.

This works better for the assistance engine flow, but not as great for manual routing because it limits their ability to move the tickets around in the route.

So the idea is that the Map would take the ability to easily manually route from Gantt, and the ability to easily use the assistance engine from Tickets, and combine them together.

Designs

The Maps’ Default View

On the Map, users can visually identify where each customer, driver, container yard, and disposal site is. On this view, they can change icon sizes, change the Map view, filter out things that they see on the map, toggle on/off labels, and search.

Tickets & Map

Users can split their window by opening up unassigned tickets and map at the same time. When they do this, they can hover over certain tickets on the Tickets panel to see where they are on the Map, and vice versa.

Routing on Maps

Users can also route on the map by using the Lasso tool to drag a shape over an area on the map, and capture all of those tickets in the side panel.

Manual Routing

To manually route, users can select one or multiple tickets, and drag them to a driver’s name. This will open up a Gantt window, with the affected route at the top. Here they can resequence the tickets to optimize their efficiency scores.

Assistance Engine

On the other hand, users can also rely on the assistance algorithm to help them assign tickets to drivers. Rather than opening up the Gantt here, we follow the assistance workflow that belongs to Unassigned Tickets.

Implementation

The Execution Tool is currently in production. Requirements for the Execution Tool are broken up into different Jira tickets that belong to a number of sprint cycles. My co-designer and I work closely with developers to deliver prototypes through Invision Spec. We sit in weekly meetings with them to discuss scope and technical capabilities, and adjust the UX to match what is technically feasible.

 

Conclusion

This project was massive, and came with an infinite number of challenges and roadblocks. Yet I feel lucky to have been able to work on it, seeing as how the tools that our field operators were using before were so unpleasant.

It’s always fun to work on consumer-facing products and high tech, forward-looking projects. But I think it’s worth noting that there are people who get left behind and forgotten when we only focus on the flashy and braggable products of the world. Upgrading tools to make people’s lives easier — even if they’re people that you don’t think about every day — is important too. They deserve nice experiences in their jobs too.