AI First Design System (AWS Fintech)

AI First Design System

When AWS Fintech started building AI into its products, nobody agreed on how AI should actually behave inside an enterprise tool. When should it make a suggestion? How should it explain its reasoning? What does a trustworthy AI interaction look like when the stakes are financial? There was no playbook. I wrote one.

The Problem

The existing design system was built for static interfaces. As teams added AI recommendations, conversational UI, and widget-level intelligence, each team invented their own patterns. Eighty product teams, eighty different answers to the same question. The fragmentation was visible to users and expensive for engineers.

The deeper problem was that nobody had defined what AI should feel like inside a high-stakes financial context. That was the real design problem.

The Team

I was the design lead on the evolution, working with engineers, accessibility specialists, and product teams across 80+ consuming teams within AWS Fintech.

What I Did

The work had three directions.

Defining how AI behaves. I led the transition from static components to the Phantom library, a set of agentic AI patterns covering inline recommendations, widget-level prompts, and conversational interfaces. The core design challenge was trust: finance professionals needed to understand what the AI was doing and why before they'd act on it. Every pattern was designed around that constraint. This gave 80 teams a shared language for AI behavior inside enterprise financial tools, and meant we were solving the hard problem once instead of eighty times.

Building the foundation. I led development of the Data Grid, the most requested component across the org. Before building anything I ran workshops with 10+ partner teams to validate what finance teams actually needed. Grouped headers, keyboard navigation, Excel copy-paste functionality. Things that sound small but were the difference between a tool people trusted and one they worked around. The Data Grid shipped to AA accessibility standards and was the first AA-accessible component in the org. It saved 1,047 developer hours and cut complex grid development time by 80%.

Scaling adoption without authority. Getting 80 teams to adopt new patterns meant doing more than shipping good components. I set up a contribution model that let 8 teams feed back into the system and ran 5 co-creation workshops across design, product, and engineering. I also consolidated 9 fragmented notification implementations across the org into one unified pattern. And I designed a stepped workflow pattern with sub-steps, non-linear navigation, and collapsible panes that expanded from 2 initial teams to products across Amazon. None of this happened through mandate. It happened because the work was good enough and the process was open enough that teams wanted in.

I partnered closely with the Cloudscape team throughout to ensure everything worked within Amazon's broader design ecosystem, which extended the impact well beyond AWS Fintech.

The Impact

• 40% reduction in developer effort compared to building from scratch
• 1,047 developer hours saved from the Data Grid alone
• 80% reduction in development time for complex grids
• 170 developer hours saved per team on adoption
• 100% of customers preferred the new components over legacy Cloudscape options
• Commitments from 80+ teams across Amazon
• 8 contributing teams, 5 co-creation workshops, 18 user interviews
• First AA-accessible component in the AWS Fintech org

Why It Matters

This project is really about one question: how do you design AI that people trust enough to act on in situations that matter? That question came up in every component, every workshop, every adoption conversation. The answer isn't a single screen or interaction pattern. It's a system. And systems only work when the people using them helped build them.

That's the work I want to keep doing.

‍

‍