UX Leadership Framework
Scaling design inside
complex organizations
How I approach maturing a UX practice inside complex enterprise and product organizations — from diagnosis through strategic influence.
Where I start — reading the org
Before touching process or tooling, I need to understand the organizational terrain. In enterprise, design doesn't fail because of craft — it fails because of structural misalignment. I run a fast but rigorous diagnostic across four dimensions.
Design's org position
Structure
Stakeholder landscape
Politics
Current design capacity
People
Decision-making flow
Process
Where does design sit, and who does it serve?
Is UX embedded in product teams, centralized under a CDO, or shared-services? Each model has different leverage points and failure modes. A centralized model has authority but risks distance from product reality. Embedded teams move fast but fragment standards. I need to know the model before I can work within it — or propose changing it.
Who are the power centers, and what do they believe about design?
In corporate enterprise, design rarely has budget authority. I map who does — and whether they see UX as a cost center, a differentiator, or an order-taker. Product, engineering, and business stakeholders all have different definitions of "done." Understanding their incentive structures is as important as understanding their workflows.
What is the team actually capable of — and what do they think they are?
I assess craft, but also confidence and self-concept. A team treated as executors for years will have learned helplessness. Rebuilding that requires different interventions than a team that's overconfident without the craft to back it up. Research capability is almost always the biggest gap.
When does design actually touch a decision — and when is it too late?
I trace a feature from inception to shipped. Where did design enter? This reveals the actual process, not the stated one. In most enterprise orgs, design is brought in after requirements are locked — which means UX is decoration, not design. Shifting this is political as much as methodological.
How I think about organizing design teams
There's no universal org model. The right structure depends on company size, product complexity, and where design sits in the value chain. I've operated in and led across all three primary models — and I know when to advocate for a shift.
Centralized
Standards-led
Embedded
Velocity-led
Federated
Scale-led
Centralized — design as a shared capability
All designers report into a central design org and are allocated to projects. Common in enterprise, agencies, and consultancies. Strengths: consistency, craft development, clear career pathing. Weaknesses: designers feel distant from product decisions, context-switching is high. I've led centralized orgs at scale — the key is a strong partnership model with business units and a clear intake process.
Embedded — design within product squads
Designers sit inside cross-functional product teams. They own their product area end-to-end and build deep domain knowledge. This is the default model for software product companies. The risk: design fragmentation. Without a center of gravity — a design system, shared principles, a design leadership forum — embedded teams diverge.
Federated — hub and spoke
A central team maintains the design system, patterns, standards, and research practice. Embedded designers operate within product teams but stay connected through communities of practice and shared tools. This is the model I advocate for at scale — it preserves velocity while preventing fragmentation. It requires investment in design operations to function.
What I always build regardless of model
Design system
Not a Figma library. A living governance model connecting design decisions to engineering implementation.
Community of practice
A recurring forum where designers share work, debate decisions, and build shared vocabulary across teams.
Research infrastructure
A way to get user insight into decisions — even if it's lean. Without this, design is opinion, not evidence.
Design metrics
Connecting design outcomes to business performance — not just usability scores.
How I run the UX process inside enterprise
Enterprise UX process isn't about methodology — it's about creating conditions where good design decisions can be made consistently. I think in terms of four phases, each with distinct outputs and stakeholder interactions.
Discovery & framing
Before the brief
Concept & alignment
Making it real
Validation & refinement
Pressure-testing
Delivery & continuity
Handoff isn't the end
Discovery & framing — before anyone opens Figma
The most valuable work I do often happens before any design artifact exists. In enterprise, this phase gets cut constantly — because there's always a deadline, a demo, a stakeholder who wants to see screens. My job is to protect this phase and make it legible to non-designers. I frame it in business language: risk reduction, assumption mapping, opportunity sizing.
AI in this phase
Research synthesis & analysis
I use AI to synthesize interview notes, surface patterns across research data, and pressure-test assumptions before they harden into design decisions. What used to take days of affinity mapping compresses into hours — without losing the analytical rigor.
Concept & alignment — making it legible across disciplines
Design concepts in enterprise need to work at multiple fidelities simultaneously. A flow diagram for engineering. A high-fidelity prototype for an executive review. A whiteboard sketch for a PM debate. I run alignment sessions not as presentations but as working sessions where decisions get made. Alignment isn't a sign-off — it's shared understanding.
AI in this phase
Figma + Claude for early concepting & rapid prototyping
Claude and Figma together compress early exploration significantly. I use Claude to generate structural thinking and content frameworks, then move directly into Figma to make them visual. I've established this as a team workflow — and as a player-coach I use it myself on the work.
AI-assisted prototyping means working, interactive concepts reach stakeholders in hours rather than days. Decisions get made faster, direction locks earlier, and teams spend less time building the wrong thing at high fidelity.
Validation & refinement — testing assumptions, not aesthetics
In most enterprise orgs, "user testing" means showing screens to internal stakeholders. I work to change that — connecting design decisions to actual user behavior. But I'm also pragmatic: not every decision needs a study. I help teams distinguish between questions worth testing and decisions that can be made with existing data or expert judgment.
AI in this phase
Synthetic user testing engine
I built a synthetic user testing engine that simulates user personas against early design concepts. It gives teams a way to pressure-test assumptions before committing to full research rounds — compressing the validation loop without removing rigor.
View in portfolio →Delivery & continuity — handoff is a beginning, not an ending
In enterprise, design quality erodes between handoff and deployment. I build continuity processes: embedded design QA, design-dev pairing, post-launch review cycles. I think about design debt explicitly — naming it, prioritizing it, making the case for addressing it in roadmap conversations. Design doesn't end at handoff. It ends when production matches intent.
How design builds organizational authority
Design influence in enterprise is earned, not assigned. Title doesn't create authority — track record and relationships do. I've learned that the most effective design leaders operate across three modes simultaneously.
Upward
Speaking executive
Connecting design decisions to business outcomes, risk reduction, and competitive positioning. Translating UX into the language of investment and differentiation. Showing up in the rooms where strategy is made.
Lateral
Being a trusted partner
Building genuine relationships with product and engineering leadership. Understanding their pressures. Being the design leader who makes their jobs easier — not who creates friction. Influence without authority requires deep trust.
Downward
Developing the team
Creating an environment where designers can do their best work. Clear expectations, honest feedback, room to take risks. Design culture is built through daily behavior, not values documents.
The levers I use to shift design's position
Make design visible at the right altitude
Communication
Win early, on something that matters
Credibility
Build shared language with product
Alignment
Make design visible — at the right altitude
Most design teams communicate at the wrong level. They show screens to people who should be seeing outcomes. I build communication rhythms that meet different audiences where they are: leadership gets impact, cross-functional partners get decisions and rationale, the team gets context and direction.
Win early, on something that matters
When I enter a new org or take on a new leadership role, I identify one high-visibility problem I can solve well and fast. Not a big redesign — a targeted, well-framed intervention that demonstrates how design thinks differently. That kind of memory is worth more than any strategy document.
Build shared language with product and engineering
Design friction in enterprise is often a language problem. When design says "user flow" and product says "user journey" and engineering says "workflow" — and none of them mean the same thing — decisions slow down and blame accumulates. Shared vocabulary, shared artifacts, shared principles. Sounds soft. It's one of the highest-leverage things a design leader can do.
Where is your design practice today?
Maturity isn't a judgment — it's a starting point. Every org I've entered has been somewhere on this spectrum. Knowing the level tells you what to focus on first.
Reactive
Developing
Established
Strategic
What I focus on at each level
Reactive → Developing
Foundation
Developing → Established
Growth
Established → Strategic
Leadership
Moving from reactive to developing
The priority here is visible wins and process clarity. I establish a repeatable way of working, create basic design artifacts the org can orient around, and identify champions in product or engineering who will advocate for earlier design involvement. I don't try to change everything. I find the highest-leverage point and move it.
Moving from developing to established
This is where I invest in infrastructure: a design system with governance, a research practice, DesignOps support, a community of practice. I also work on the career model — designers need to see a path forward, or the best ones leave. And I'm making the case for design to be in planning conversations, not just execution.
Moving from established to strategic
At this stage the work is about embedding design thinking into how the organization makes decisions — not just how it builds products. I'm in conversations about market positioning, platform strategy. The design system has its own roadmap. Research informs strategy. And I'm building the next generation of design leaders who can hold this without me.