2018 - 2019
Meta
Web, Ops, Infra
In this context, "routing" referred to the way an internal tool tried to sort user reports into the correct queues so the right contractors and specialists could work on them.
There were hundreds of new reports every minute, some legally time-sensitive. So when something in the internal plumbing would break, it caused headaches and legal risk at multiple levels.
So one day when a project manager approached me saying there were hundreds of new reports suddenly showing up in the wrong queues, we set out to fix it as quickly as possible.
I came up with a bandaid coding solution, but it caused a bunch of other (slightly lower-risk) misroutes. Sometimes when a tool breaks in this way, it means an engineering redesign is necessary. And the best way to diagnose whether or not a redesign is needed is research who uses it, how they use it, and why.
Shadowing sessions. Luckily, there was a contractor building across the street full of people that used this tool on a daily basis. So we (me and a few project managers) set up several shadowing sessions to observe how contractors would use this tool to process reports and wrote down our (often surprising) observations.
Tech Support Tickets. I searched through our tech support database using keywords like "misroute," "wrong queue," and some words unique to our vertical in the company. I discovered dozens of tickets reporting this issue dating a few years in the past, plus a GOLDMINE of spreadsheets documenting the misroutes.
Data & Analytics. I ran through these spreadsheets, and compared them to the behavioral observations we made from the shadowing sessions. Patterns started to emerge, and the real problem became less fuzzy.
Technical Deep Dive. I searched through the codebase to get a better understanding of how the machine sorted reports into queues, and found the logic scattered across multiple areas, some of which had been recently deprecated (aha!)
From the research process, I gathered information from both users and engineering to:
1. Shed light on the black box of what was going on inside the tool, and
2. Find out where we could have the most impact with the least amount of effort.
Below, you can see my notes from this process, which led me to discover that the reason these misroutes kept happening was because there were SIX attributes that determined which queue the report would end up in, rather than a simple one-to-one mapping.
Some of them were automatically added by the tool, some of them were manually added by the user, and the logic was scattered throughout different codebases.
It's tempting to want to design everything until it looks magnificent with a fancy new interface, but for this project, that was not the case. Because of the heavily-involved research part of this process, we learned that we did not need to design anything extra; only tweak an already-existing design to solve the user's problem.
This was fantastic, because it saved time, effort, and reduced friction of needing to get the users to learn how to use a new interface.
Due to the discovery of those six attributes that told the machine where to route reports, all I had to do was write one line of code to tweak one of those attributes. This logic dog-eared only the reports that were important to our vertical, then the tool would dutifully sort them into the right queues.
Sometimes the best design is no design.
