Leadership & DesignOps
Scaling design as a system, not a service.
Led DesignOps and system adoption across 12 product teams at SeamlessHR — operationalising design as infrastructure: how decisions are made, how knowledge compounds, and how teams stay coherent as the organisation scales. Principles built here are designed to hold beyond any single product organisation.
Philosophy
What I believe about design at scale.
- 01Design is infrastructure, not a service.
- 02Systems compound. One-offs decay.
- 03Operationalise decisions before they become bottlenecks.
- 04Onboarding is the fastest path to system literacy.
The DesignOps Stack
Seven layers that hold the system together.
01
System Operationalization
Turning the design system from a library into operating infrastructure — token architecture, governance model, contribution pipeline, and release cadence.
02
Contribution System (SOP)
A defined contribution pipeline: proposal → critique → spec → review → release. Anyone in product or engineering can contribute, with clear gates instead of bottlenecks.
03
Design Onboarding System
System-first onboarding (not tool-first). New designers learn the tokens, components, and patterns before tools — contributing back into the system within their first weeks. This approach reduced onboarding time by 30% and accelerated system literacy across every new hire.
04
Governance
Token hierarchy, naming conventions, deprecation policy, accessibility baseline, and version contracts between design and engineering. Decisions are documented, not personality-driven.
05
Team Capability
Capability maps, role-gap frameworks, structured PIPs, critique rituals, and performance frameworks. Raising the floor across the whole design function — not just the top.
06
Cross-functional Alignment
Bridging design and engineering through shared standards, design-to-dev rituals, and system contracts. Reduced rework and handoff friction across 12 teams.
07
AI Layer
Defining how AI interactions show up inside enterprise workflows as reusable patterns: trust, explainability, prompt frameworks, and shared interaction models — not one-off features.
Problems I'm Working Through
Active questions at the intersection of systems and scale.
AI in enterprise workflows without eroding trust
How do you embed AI decision-support into high-stakes HR workflows — hiring, performance, payroll — in ways teams will actually rely on? Trust, explainability, and human override are design problems, not just engineering ones.
Governance at multi-product scale
A contribution model that works for one product team starts breaking at twelve. The question isn't how to enforce standards — it's how to design governance that teams choose to use because it makes their work easier.
Design systems as infrastructure for intelligent interfaces
As AI becomes a product layer, design systems need to encode interaction patterns for AI — not just UI components. That means reusable prompt frameworks, trust states, and fallback patterns that behave consistently across products.
Related Case Study
Seamkit — the operating system underneath.
The token architecture, governance model, and adoption programme that DesignOps is built on.
Read the case study →AI Layer
SeamlessAI — patterns, not features.
Reusable AI interaction patterns built into enterprise workflows as a system layer — not one-off integrations.
Read the case study →