UX is not just Research Fantasy.

It's about You x Execution!

How to use the right terminology for your delivery work. Finally, there is a design framework that can help you claim credit and compensation for your UX execution and deliverables.

The delivery gap in design reality

BCG’s 2024 research reveals a harsh truth: over two-thirds of large-scale tech programs fail to meet their targets, primarily due to delivery shortcomings, not flawed ideas. Would execution work which saves that successful third be highly valued?

Not even close.

Execution work involves a series of mundane, stressful cycles. Workshops are occasional events; user research sessions are rare highlights amidst a sea of delivery grind. Yet, the industry’s focus - seen on LinkedIn or any design community is all about the Discovery phase. We see high peaks and breakthrough ‘wow’ moments positioned as the only “real” design work.

It’s like scrolling through Instagram, isn’t it? Everyone posts their restaurant dinners with perfect lighting which is a result of ten takes and a ring light. Rarely do we see the unglamorous home rice bowl, cooked in a rush just to get fed.

Design execution vs. UX strategy

This FOMO is costly. Talented execution designers, those doing meticulous crafting that actually prevents project failures, often start to believe they’re inadequate because their work doesn’t generate highlight reels worth sharing.

For outsourcing designers, this gap is even more painful. We’re tested on our ideation process during interviews, but once hired, we’re immediately placed on execution-only tracks. We arrive after the requirements are defined. After user research is done. After the Discovery is over. Our job? Deliver screens on deadline. Manage component systems.

I wasn’t just frustrated. I felt like I was reaching a dead-end, sweating through “execution” sprints while the industry only handed medals to the “strategic” thinkers. I had spent years honing accessibility, building scalable system under brutal constraints, and delivering hundreds of screens on time.

No matter how hard I try to show my abilities and capabilities, the industry always brushed it off: “Oh, you’re just a pixel-pusher ① ”.

Was I just repeating the same cycle with different clients? Moving from project to project without building toward anything meaningful?

For years, I grappled with a question that seemed to have no answer: If execution is the crucial phase where projects often falter, why can’t I convey the value of my expertise in this area? The struggle to gain recognition for execution excellence is not just my own, but a shared experience among many in our field.

Then I realized: the work wasn’t the problem. The industry’s “Discovery-obsessed” narrative was the problem.

Double Diamond doesn’t map to my powers

Every UXer knows Double Diamond. It’s taught in any UX course and referenced in onboarding decks. When recruiters ask “How do you approach design?” they expect to hear its four phases. I tried to apply it to my work, but couldn’t see myself within it.

Double Diamond focuses on activities that happen primarily WITH users. My work happens with requirements documents, technical constraints, and stakeholder dynamics, often WITHOUT access to end users.

Double Diamond had no category for where I actually added value:

• Clarifying ambiguous requirements
• Validating technical feasibility
• Navigating handoff complexity

BCG says two-thirds of projects fail at delivery. Yet the execution-facing work that prevents those failures? Invisible in the framework.

So I searched for a framework that would. I spent months searching by reading design articles, watching conference talks, and reaching out to communities. Most content still emphasized Discovery and Define, the phases I wasn’t doing. I needed a framework that recognized execution as more than just “building screens” and validated that delivery expertise is real expertise.

Then I found Zendesk’s Triple Diamond.

Triple Diamond brought me closer to the answer

Zendesk stated the traditional (Double Diamond) framework “tends to oversimplify the crucial ‘Ship’ phase”. So, they added a third diamond.

Reading this felt like a weight lifted off my shoulders. Finally, a framework that didn’t treat “Shipping” as a single button-press but as an entire journey of validation and rollout work. It was a validation of the work I had been doing all along.

If Diamonds 1 and 2 focus on designing the right thing, Diamond 3 focuses on designing it right and making it survive the real world. Execution wasn’t a footnote - it was a full diamond.

I pulled out my project notes and started mapping my reality to this new model:

• The Discovery Phase (Diamond 1+2): complete before I arrived.
• The Development Phase (Diamond 3): primary work window (design systems/component libraries, feature cycles).
• Validation and Rollout Phase (Diamond 3):...wait.

Here, I hit a wall. Diamond 3 usually implies Alpha/Beta releases and user testing cycles. But in outsourcing, I was rarely involved in testing and often exited before implementation was complete.

This framework gave execution its own diamond, yet it still looked like I was missing most of the journey.

Execution IS Discovery

Then I reframed the entire process, I realized I wasn’t skippingDiscovery and Validation. I was doing them inside the execution phase.

I reviewed my “Week 1 Checklist” from a recent project:

• Read requirements → Found unmentioned logic gaps.
• Evaluated design systems → Selected PrimeNG to fit the tech stack.
• Assessed risks → Flagged that “Fixed Price + Large Scope” meant zero room for pivots.

Suddenly, the light bulb went on 🤯

This IS Discovery work. It wasn’t user interviews, but I was discovering gaps in requirements, technical constraints, and execution risks.

This IS Validation work. It wasn’t usability testing with users, but I was validating what survives implementation and what breaks. I was conducting compliance audits and proposing viable solutions when constraints tightened.

I had been comparing myself to product designers and concluding I didn’t do Discovery. I was wrong. I do both, just at a different way:

• Product designers discover user problems → I discover execution problems
• Product designers validate with users → I validate with technical audits
• Product designers define problem spaces → I define risk factors.

I realized the problem wasn’t a lack of work, but a lack of correct terminology. I was conducting Discovery and Validation focused on execution needs.

The missing puzzle piece finally clicked in place. I developed a specific playbook to professionalize the delivery process.

Access full spreadsheet here: https://docs.google.com/spreadsheets/d/1v-vjplrxYLK4_Cfch44dIlVrCJyS3O_GR-MhpSiAMXg/edit?usp=drivesdk

Your execution is your superpower

If you are in outsourcing, stop being self-conscious. The pressure you face cultivates a rare market superpower: the ability to make things work when everything says they can’t.

Your value was always there. You just needed the correct terminology to claim it.

So, the next time someone calls you a “pixel pusher”, will you accept it? Or will you pull out your Execution Playbook and show them exactly how you saved their project from becoming part of the 66% that fail?