Admin Reports Unification

The surface problem was the tech stack. The real problem was the team structure.

Design was solving the problem in a silo. When developers and product partners saw the work, it was in the same room as leadership. The design solutions weren’t landing, not because they were bad, but because the people who would have to build and ship them weren't involved in the design process. Product and engineering surfaced concerns in front of stakeholders, which made the team look misaligned. Every design presentation ended in the same way: friction, pushback, and rising concerns.

The first thing I changed was the working team structure.

I restructured the core team around a single, co-owned unit: one designer, one dev lead, one product owner, one data scientist. Every major decision was made together, before it reached a stakeholder room. By the time the team presented to leadership, most concerns were already resolved because the people who would have raised them had been involved from the start. This allowed cross-functional stakeholders to process the solution with more trust and provide more meaningful feedback.

The original designs might've been revolutionary but they were untested. We needed something that works.

Our design team invested heavily in exploring how this migration could solve existing pain points, elevate the user experience, and set a new standard for Amplify's admin reporting suite. But translating that ambition into something tangible enough to align product, engineering, and leadership proved to be the real challenge.

The second thing I changed was the design direction.

The designers had spent a year exploring the initial vision so resisted an abrupt directional change. So I gave the them two weeks: bring me evidence that users respond well to this, and we'll continue. If not, then we will pivot.

And so we pivoted.

Thoughtfully leaning on existing patterns of Amplify admin reports.

I reframed the design solution entirely — instead of designing a new experience, we aligned the migration to the design patterns already established across other admin reports for our other products. Less novel, more coherent. It was less exciting than a brand new reporting experience, but the right call for users who had to navigate across the whole Amplify product ecosystem and for our stakeholders to accept an adaptation to a working model.

Understanding the sunk cost fallacy, I prioritized consistency and user validation over protecting a year of invested effort. That's not a comfortable call — people's work felt dismissed, and some of that feeling was legitimate. But continuing to invest in an unvalidated direction would have compounded the problem, not resolved it.

We had to plan strategically around a tight timeline for a successful release.

The third change was how we shipped. With five reports to migrate — each carrying full feature parity — attempting to design everything before a single line of code was written was too risky. So we staggered the work: prioritize critical reports, design one report, hand it off, then start the next. While engineers built one report, design was already solving the next.

The third thing I changed was including user research into the design phase.

Each report carried complex tools and features, so I embedded UXR validation into every design phase. With each cycle, the team compounded its product knowledge and user insight — answering two questions that mattered most: for users with multiple Amplify products, does the experience feel consistent across all of them? And for users who only have mCLASS, is the new reporting experience better than what they had before?