Form elements — one of the clearest cases of the same input pattern built three different ways
Creating shared product patterns across teams that had been building independently.
Each product vertical at IAS had its own team, and each team had been solving the same interface problems on its own — rebuilding the same components slightly differently, with no shared ownership across them. That showed up directly in the product: a disjointed experience for the 80% of our users who were internal Client Services staff navigating between verticals every day.
I managed the Design System team and a cross-functional Community of Practice, while also personally delivering transactional and analytical tools for enterprise clients — I stayed close to real product work rather than only running the systems effort from a distance. I partnered with Engineering leads across the verticals to get the pattern library adopted, not just built.
Because each vertical team owned its own area end to end, they were often rebuilding the same interactions from scratch instead of reusing what already existed elsewhere in the platform. Users — mostly our own Client Services staff — ran into different solutions to the same problem depending on which part of the product they were in. That inconsistency wasn't a visual polish issue; it made the platform harder to learn, harder to maintain, and harder for any one team to improve without stepping on another.
Fixing the UI symptoms without changing how teams worked together wouldn't have lasted. A component library that only I maintained would have become one more thing for other teams to ignore or work around. So alongside building the library, I set up a cross-functional Community of Practice — a standing mechanism for the vertical teams to weigh in on what belonged in the shared system, and to actually maintain it going forward, rather than treating it as something handed down from a central team.
I started with a full audit of components already in use across the platform. Seeing four or five different versions of the same form field or the same card pattern side by side made the organizational problem obvious immediately — no one had to be convinced with a slide deck.
A first pass at naming the shared elements that were being rebuilt independently across verticals
Form elements — one of the clearest cases of the same input pattern built three different ways
Card components, unified into a single pattern
Switches
Tabs
Sandbox Pattern Library
Card Patterns
Page Templates
Visual Design QA
The library itself wasn't the hard part — getting independent teams to actually use and maintain something together was. The Community of Practice gave every vertical a seat in deciding what belonged in the shared system and what should stay flexible to their specific needs, and it gave Engineering a direct channel into those decisions instead of finding out about them after the fact. That shared ownership is what kept the system from becoming another silo that only the Design team cared about.
Beyond individual components, I guided the team to think about how users moved through the platform as a whole — how filtering behaved, how a table expanded, how an icon animated. Those small decisions, made consistently, added up to a platform that felt like one product instead of five.
Table expansion interaction — one of the shared patterns adopted across verticals
While I was managing the systems effort, I stayed personally responsible for shipping transactional and analytical tools for enterprise clients — turning conceptual wireframes into working, interactive experiences. Our platform's core job was making complex data accessible, and Client Services (80% of our users) needed fast, reliable ways to answer client questions. That gave us fast feedback loops on every iteration, and the longer-term goal was a platform intuitive enough that Client Services could spend more time on service quality and less on report generation.
Global navigation prototype
Customizable report builder — one of the enterprise tools I remained hands-on in shipping
User test notes
The component library solved a visible problem. The harder, less visible problem was getting teams that had always worked independently to agree on shared ownership of anything. What I learned here is that consistency across autonomous teams isn't something you can mandate from a central design team — it holds up only if the teams that have to live with it also had a hand in building it.
I didn't have formal authority over the vertical teams, so this only worked through influence and a mechanism — the Community of Practice — that gave people a real reason to keep participating.