A shared language
for 166 products
How do you unify an enterprise with no shared design foundation? Start with the people.
In 2017, State Street had 166 products and no shared language.
Product teams were operating in silos. Every product looked and behaved differently. There was no shared foundation, no design principles, no common components. And nobody had really felt the full weight of that problem — until we mapped it.
The State Street Corporation is one of the largest and oldest financial institutions in the United States. The objective was twofold: create a cohesive experience across existing digital tools and establish guidelines for future experiences. I led the design team at IBM iX through every phase of that work.
166 products. Five universal experiences. One design system.
Consistency at enterprise scale
- Product teams operating in complete silos
- Inconsistent design patterns across every product
- No shared components or design language
- Lots of manual and ad-hoc processes
- Lack of user experience investment
Design Director · IBM iX
An engagement at enterprise scale.
Observe, Reflect, Make
Design Thinking isn't a process — it's a framework. Three modes the team worked from at every stage of the engagement, from the first workshop to the last product team we onboarded.
In practice these three didn't run in sequence. Observation kept happening once we were making, and what we made kept reshaping what we'd already reflected on.
The engagement started with a week-long Design Thinking workshop I facilitated at our design studio in Cambridge. Multidisciplinary by design — State Street developers, business stakeholders, SMEs, and our IBM iX design team in the same room. The goal wasn't a deliverable. It was to get the people who knew the products into a room with the people who'd design the system, and not leave until everyone understood each other.
From the workshop we built four personas, including the developer who'd consume the system. We did empathy mapping. We followed up with research interviews to test the personas against reality. By the end, we'd identified My State Street — the firm's primary client portal — as the flagship the design system would be built around. Not because it was the easiest, but because if it worked there, it would work anywhere.
The team consolidated into a working group — devs, designers, SMEs — building two parallel tracks: a design language (typography, color, spacing, voice) and a component library (forms, navigation, help, icons). Out of that work emerged five universal experiences and a set of design principles that would govern decisions when product teams disagreed about a button.
What made this phase different was the SMEs. They weren't being interviewed anymore — they were in the trenches with us, whiteboarding, throwing post-its, becoming business partners in the work. The relationship was warm and the pushback was thoughtful: help us understand why this is better than what we have. We were taking something they'd lived with for years and modernizing it. Once they could see where it was going, they were on board — and because they'd challenged us along the way, the work was sharper for it. Watching that shift happen — the moment they stopped being the business partner and started being part of the team — is something I still think about.
Two floors of the studio ran in parallel. Upstairs, we were building. Downstairs, we were running Design Thinking workshops with other State Street groups — teaching the methodology to colleagues who'd never used it. Actual State Street users could walk upstairs and test what we were making. Constant playback reviews with stakeholders kept us grounded and honest. The reflection wasn't theoretical at any point. It was tested, challenged, and revised in real time.
And the design system was only part of what we were doing. We were teaching a 200-year-old institution how to use design thinking in its day-to-day work. The system was the artifact. The shift in how the company built software was the actual project.
Building meant translation. We worked closely with State Street's developers to make sure the design system was actually understood — that the language and components weren't just shipped, they were communicated. We also created Sketch templates so the internal designers could consume the system in their own tools. Many of those designers were people we were interviewing on State Street's behalf, hiring the team that would own the system after IBM iX left. Two architectures running together: code as the source of truth, Sketch as the layer the new team would design in.
Then adoption. I worked directly with the first few product teams to help them update their projects — lots of reviews, lots of questions, lots of close attention to whether they were applying the system in spirit and not just in pixels. They got it. Then they took what they'd learned and helped other teams. That's how adoption actually scaled at State Street — not a mandate from leadership, but a cascade of designers and devs teaching the next group. Some teams moved fast. Some took time. That's the honest answer about adoption at enterprise scale.
The work didn't end when the system shipped. I stayed through adoption, then moved on to onboarding new State Street projects for IBM iX — the relationship had deepened past a single engagement, and we became the team they came to for what came next. State Street was the last project I worked on at IBM before joining FM Global. It's still work I think about often.
From process to product
The design system wasn't just documentation — it powered a complete ecosystem. Here's what it looked like in practice: design principles that unified the team, a flagship experience rebuilt from the ground up, and a suite of products transformed by the new system.
A foundation, not a style guide
Before any component, before any color token, we wrote the principles. Five convictions that every design decision had to answer to — published on an internal site teams could reference daily. When 166 product teams disagree about a button, you don't argue about the button. You point at the principle that resolves it.
My State Street
My State Street was the north star product — the flagship experience that proved the design system worked at scale. We rebuilt it end-to-end, from the launch page to the data views, as a unified and cohesive experience.
The system at work
The true measure of a design system is how well it scales. Here's the system in action across two very different products — a legacy client portal rebuilt with the new language, and an Apple Watch integration extending the experience beyond the desktop.
A system that changed how State Street thinks about design.
IBM iX developed a governance program that would help State Street evolve its design system. Product teams began practicing design thinking — focusing on user flows and use cases rather than requirements lists. Design shifted from being requirements-centered to user-centered.