AMZ

This work began with a question most internal tools never get asked: do the people closest to the spend actually have visibility into where it went?

AWS marketing teams were managing budgets across business units without the visibility tools the rest of AWS had built for its customers. Budget allocation, campaign pacing, and yield tracking lived in spreadsheets and email threads. Financial decisions that should have been data-driven were being made on instinct, and the teams closest to the spend had the least visibility into where it went.

The role was Senior Product Designer on the AWS Marketing Cloud Insights platform — a B2B dashboard system for marketers, analysts, and decision-makers managing campaigns across multiple channels. The challenge wasn't building dashboards from scratch. It was translating spreadsheet logic into interfaces that respected the user's mental model, while building something the rest of AWS could reuse.

The approach started with research. Stakeholder interviews with marketers and analysts surfaced what people actually wanted to see versus what the existing tools surfaced. User personas were defined for the three audiences: marketers running campaigns, analysts reading the data, and decision-makers acting on it. Each had different definitions of "the right view." Journey mapping identified where the existing workflow forced people to leave the platform — usually because they couldn't get a number they needed without exporting to Excel.

The design itself mirrored AdTech workflows that finance teams already understood: budget pacing, yield tracking, performance reporting. End-to-end flows were architected for the full budget lifecycle — allocation requests, approvals, real-time monitoring, and reporting. The platform consolidated data from multiple sources into a unified view, replaced manual reporting with automated dashboards, and gave teams the ability to build their own campaign performance views without filing a ticket.

The lasting contribution wasn't the dashboards. It was the data visualization UI library underneath them — pioneered for this work and reused across other AWS FinTech teams who needed to surface complex financial data without rebuilding the components from scratch. Feature adoption climbed 22% inside the first quarter.

Three takeaways shaped the work and travel with me into the next engagement like it:

Internal tools deserve consumer-grade craft. The people using AWS's own products are still people. Building for them the way you'd build for an external customer is the move that separates serious internal platforms from the ones everyone works around.

Design systems emerge from real work, not separate initiatives. The data visualization library wasn't a standalone project. It was the byproduct of solving the actual budget visibility problem and making the solution reusable. That order matters — systems built in the abstract rarely get adopted; systems extracted from shipped work usually do.

Translation is the design. Taking spreadsheet logic and making it navigable, taking financial data and making it actionable, is the actual work. The interfaces are just where the translation shows up.