One System, Multiple Teams

So, one project that really stands out is Compliance.

At a surface level, it sounds boring, right :compliance documents, approvals, paperwork. But the reason I bring it up is because of how deep the problem actually was, and what it took to fix it.

We had three types of people depending on this system. Students submitting their documents, faculty who help student in their compliance requirements, and clinical sites who onboarded students only after everything cleared. One process. Three people relying on it, at three different points in time.

At first, it was just annoying. We'd get a support ticket, fix it, move on.

Then a week later, a different ticket would show up, somewhere else in the flow. It kept happening. And that's not a good feeling, realizing the fixes weren't actually fixes.

Once my team and I sat down and traced it properly, we saw what was really going on: the system itself wasn't aligned. Every fix we made in isolation just moved the friction somewhere else.

So at that point, I wasn't just designing anymore. I was coordinating with the product owner, the project manager, the dev team, and customer support, because this wasn't something my design team could fix alone.

Everyone owned a piece of it, and nobody had actually mapped how those pieces connected.

And we had a deadline. There wasn't room to get this wrong. I had to scope it, what needed fixing now, what could wait for later, and get everyone aligned on that, fast.

When it finally shipped clean, that was its own kind of win.

And when we measured it against the old process, task completion time dropped by about 0%

But honestly, the number's not even the part I think about most. What stays with me is that the tickets stopped bouncing around the system. We didn't patch a symptom. We fixed the structure underneath it.