Building the design system behind BMO's commercial banking platform
As Senior Product Designer on BMO's O-LBB platform, I lead the design system and cross-platform interface work behind one of the bank's core commercial banking tools.
Overview
A system that has to hold, not just one screen.
BMO's commercial and business banking teams rely on the O-LBB platform for day-to-day operations. My work centers on two things: shipping consistent, well-crafted interfaces across the platform's surfaces, and maintaining the design system that keeps those interfaces cohesive as new features ship.
Context
Why design systems matter more at bank scale.
Large regulated institutions like BMO run many product teams building against the same platform simultaneously. Without a shared system, interfaces drift — inconsistent spacing, divergent component behavior, duplicated patterns. That drift shows up to commercial banking clients as a product that feels stitched together rather than designed.
Constraints
Designing inside a regulated, multi-team platform.
Regulatory
Commercial banking interfaces are subject to compliance and accessibility requirements that shape what can change and how quickly.
Scale
The design system has to serve multiple product teams working in parallel, not just one team's roadmap.
Legacy patterns
Existing components and flows had to be extended and rationalized, not thrown out and rebuilt from zero.
Cross-functional
Every system decision gets reviewed by engineering, compliance, and other design teams before it ships.
Process
What the role looks like day-to-day.
- Lead development of cross-platform digital product interfaces with a focus on component consistency and brand scalability.
- Manage and maintain BMO's digital design system to ensure UI cohesion across the O-LBB platform.
- Work directly with engineering so system components translate cleanly from Figma into production code.
- Review new feature designs from other teams against the system, flagging drift before it ships.
Key decisions
Adoption over completeness.
Componentize high-reuse patterns first
Rather than trying to systematize everything at once, I prioritized the patterns every team touches most often — the fastest way to make the system feel indispensable.
Documentation engineers actually use
Built system documentation that engineers reference during real implementation, not a Figma library that only designers open.
Shared review checkpoints
Pushed for new features to get checked against the system before they ship, not after — catching drift when it's still cheap to fix.
Where it landed
Ongoing — the work continues.
- The design system is the shared reference point for commercial banking product teams building on O-LBB.
- New features ship with consistent, reusable components rather than one-off implementations.
- This is my current role — the system and the platform are both still actively growing.
Reflection
What I'd tell another designer facing this.
Design systems at this scale succeed or fail on adoption, not documentation. The system only works if the teams building against it find it faster than building their own version — that's the bar I design to.
Next case study