Designing UX Proposals That Survive, Advance, and Deliver

After more than twenty years in design and product, I’ve seen countless proposals fail. Some were brilliant, but didn’t survive the first meeting. Others moved a little further, only to stall in a committee or lose their place in the roadmap.

At some point we realized the problem wasn’t the quality of the design itself, but how the proposal held up across different dimensions. We started looking for patterns in the ones that did succeed. That reflection eventually shaped what we now call UX Vitals.

Mega-fail history: the design nobody asked for

Once we replaced a floating action button with a bottom bar. From a usability standpoint, it looked perfect, more accessible, more visible, more in line with mobile patterns.

But the new bar came packed with functionality no one had asked for. It solved problems that mattered to us as UXers, not to anyone else. We spent time in debates and presentations, selling the “big change,” while ignoring what we were actually prepared for: aligning different needs and perspectives.

In the end, it was costly to build, added debt, and from a business perspective it moved a few metrics, but nowhere near enough to justify the investment. A proposal polished in usability but weak across the dimensions, and a failure we still cite as a reminder to check UX Vitals before moving forward.

Borrowed principles, reshaped into our system: UX Vitals

UX Vitals borrows from methods like HEART, Lean UX, and the Kano Model, but it’s also shaped by our own practice, what has worked for us and what hasn’t.

What makes it ours is simple: every proposal should stand on at least three of five dimensions, experience, feasibility, impact, cost, scalability, and be framed in the right language for the audience.

That’s why UX Vitals isn't a theory for us. It’s the filter we rely on to check substance before we commit energy.

The 5 dimensions of a solid UX proposal

1. User Experience

Does this change actually improve how people use the product?

It should reduce friction, improve accessibility, and build trust. When this is missing, you may still ship something functional, but the gaps in experience surface quickly, turning usability into a real point of failure.

2. Business Impact

Will it make a measurable difference for the business?

A clearer flow that reduces support tickets, or a smoother checkout that lifts conversion, is what gives a proposal real weight. Without this, even a well-designed solution risks being sidelined, not because it lacks value, but because it fails to connect with what the business is actually driving toward.

3. Technical Feasibility

Can it realistically be built with the stack and the team we have?

For us in UX, this means aligning early with engineering instead of designing castles in the air. If feasibility is ignored, a proposal can look promising at first but soon turns into fragile workarounds or long delays that erode confidence in the design itself.

4. Cost and Effort

Is the value worth the time and energy required?

Part of our job is keeping proposals realistic. That often means shaping them into versions, an MVP first, improvements later. When effort is overlooked, teams can end up chasing over-designed solutions that look impressive on paper but drain resources and push out more impactful work.

5. Scalability

Will this solution still make sense as the product grows?

A pattern that works today should extend across contexts, align with the current design system, and stay open to what the product may need tomorrow. If scalability is overlooked, the design can look elegant in the moment but quickly turns into tomorrow’s bottleneck, creating debt that slows down future progress.

A proposal that balances at least three of these five dimensions has the substance to move forward. But substance alone isn’t enough. How you frame and communicate that proposal often decides whether it gains traction or stalls.

Beyond the dimensions: speaking the right language

You can’t talk technical details with a product owner, just like you can’t talk about long-term vision in a handoff with developers. Each role listens through its own filter, and a good proposal adapts to that reality.

• With a PM: “If we introduce this new flow, we can reduce support tickets and keep the release aligned with x goals.”
• With a Tech Lead: “This flow only requires a minor x adjustment and avoids rework in the checkout logic.”
• With a Developer in handoff: “Here’s how the new component fits the current design system, so it can be reused without adding custom styles.”
• With a Designer peer: “The new layout increases clarity in navigation and keeps accessibility contrast ratios consistent.”

The same change framed in four different ways shows how intention and substance only work if they’re spoken in the language of the listener. That’s what turns a proposal from an isolated idea into something the team is ready to move on.

Our Cheatsheet

Here’s the way we review our proposals. A simple checklist we use every time.

User Experience (friction, accessibility, clarity, design)

• Does it solve a real friction point for the user?
• Does it make the interaction clearer and more reliable?

Technical Feasibility (stack, dependencies, risks)

• Can it be built with the current stack and architecture?
• Does it avoid blocking dependencies or introducing critical risks?

Business Impact (conversion, efficiency, timing, success metrics)

• Is this the right moment to introduce the change?
• Does it move or redefine the success metric we actually care about?

Cost and Effort (resources, time, trade-offs)

• Is it expensive or does it pay off the investment?
• Is there a simpler version that gives us almost the same benefit?

Scalability (design system, adaptability, long-term debt)

• Will it hold up over time without creating technical or UX debt?
• Can it adapt if the product grows or changes context?

Language Fit (audience, framing, clarity)

• Is the proposal framed in a way that speaks to the right audience?
• Does it highlight what matters most to them (impact, feasibility, design, etc.)? </aside>

The Lesson Behind UX Vitals

Over the years, I’ve learned that the difference doesn’t come from how clever an idea looks on paper, but from how it holds up across multiple dimensions and how it’s framed for the people who make decisions.

Kaizen’s UX Vitals was born out of that realization: to stop pouring energy into beautiful but fragile ideas, and to focus instead on successful proposals that survive, advance, and deliver real impact.