How to Position System-Level Design Work So It Actually Gets Funded

If Your Design Initiative Needs Approval, You’re Probably Framing It Wrong

Most design initiatives don’t fail because they lack value. They fail because they’re framed like design work instead of business-critical infrastructure.

If you’ve ever presented a design system, pattern library, or cross-product initiative and heard:

• “This is great — let’s revisit later.”
• “Can teams just handle this individually?”
• “Do we really need this now?”

…it’s not a problem with your solution.

It’s a problem with how you positioned it.

The Reality: Directors Don’t Fund “Design Improvements”

They fund:

• Faster delivery
• Lower operational cost
• Reduced risk
• Scalable systems

So when you say:

“This will improve UX consistency…”

They hear:

“This is nice to have.”

What they need to hear is:

“We cannot scale our product portfolio efficiently without this.”

That’s the difference between alignment… and approval.

The Shift: From UX Proposal → Operational Strategy

Most designers present ideas like this:

“We should standardize patterns across products.”

But cross-product work is not a design task.

It’s an operational decision.

It impacts:

• How teams build
• How fast they move
• How products scale over time

If you frame it as UX, it will be deprioritized. If you frame it as infrastructure, it becomes fundable.

What You Must Frame Strongly

To get a complex initiative approved, four things need to be undeniable.

1. The Problem at Scale (Not at Screen Level)

Avoid:

“Designers are solving dialogs differently.”

Frame:

“Multiple teams are repeatedly redesigning the same workflows across products, creating duplicated effort and inconsistent experiences.”

Make it about:

• Scale
• Repetition
• Cost

You’re not fixing a UI issue. You’re addressing system inefficiency.

2. The Cost of Doing Nothing

This is where most proposals fail.

If you don’t define the cost, leadership assumes there isn’t one.

Be explicit:

• Duplicate design and engineering effort continues
• Inconsistency increases as more products ship
• Onboarding and support costs rise
• Time-to-market slows as the portfolio grows

You are not proposing improvement. You are preventing compounding inefficiency.

3. Patterns = Scalable Decision-Making

This is where you elevate the conversation.

Components scale UI. Patterns scale decisions.

Without patterns:

• Every team rethinks behavior
• Every feature becomes a new problem
• Every workflow diverges

With patterns:

• Teams reuse proven interaction models
• Decisions become faster and more consistent
• Engineering aligns implementation across products

This is how you move from a design system to an operating model.

4. Ownership & Governance (Make It Real)

If you don’t define ownership, your initiative won’t be taken seriously.

You need to show:

• Who defines patterns
• Who contributes
• Who approves
• How adoption is enforced

Otherwise, the assumption is :

“This will become documentation no one uses.”

Governance turns ideas into sustainable systems.

What You Should Push

Not everything needs equal emphasis.

Push hard on:

Cross-Product Impact

Frame everything at the portfolio level, not product level.

Efficiency & Speed

Tie your initiative to:

• Faster design cycles
• Reduced engineering rework
• Faster delivery

Risk Reduction

Inconsistency leads to:

• Usability issues
• Support overhead
• Product fragmentation

What You Must Determine Before You Present

Before you walk into a director review, you should already have clarity on:

1. Initial Scope

Don’t say “pattern library.”

Say:

“We will define 5–7 high-impact patterns in Phase 1.”

2. Phased Rollout

Directors fund execution, not ideas.

• Phase 1: Define + pilot
• Phase 2: Expand + govern
• Phase 3: Scale across products

3. Level of Investment

Be ready to answer:

“What does this cost?”

Even directional:

• Design: 20–30% capacity
• Engineering: 10–20% alignment

4. Success Metrics

Define how you’ll measure impact:

• Reduced rework
• Faster delivery
• Improved consistency
• Lower support load

How to Structure the Conversation

This structure consistently drives decisions:

1. Why we’re here
2. The problem (at scale)
3. Cost of doing nothing
4. Reframing (e.g., Components vs Patterns)
5. What the initiative is
6. Real example (before vs after)
7. Business impact
8. Phased approach
9. Ownership & governance
10. Decision & ask

This Applies Beyond Patterns

This approach works for any system-level initiative, including:

• Design systems
• Platform UX work
• Cross-product features
• Infrastructure improvements

If it requires:

• Multiple teams
• Ongoing maintenance
• Behavior standardization

…it must be framed as a scalable operational investment, not a design enhancement.

Final Thought

Most design initiatives don’t fail because they lack depth.

They fail because they lack positioning.

If you present your work as documentation, it will be treated like documentation.

If you present it as infrastructure for scaling the product, it becomes something leadership can justify investing in.

And that’s the difference between a good idea… and an approved initiative.