There Is No Such Thing as 'Done' when UX is a Product

We’ve all seen the file names. onboarding_v1.fig, onboarding_final.fig, onboarding_REALLY_final_v2.fig, FINAL_FINAL_vdone.fig, final_this_one.fig.

It’s a symptom of a mindset that’s been baked into UX culture; the “Hand-In-Your-Homework” model. We research, we ideate, we design, and then we “hand it over” to engineering. Once it’s in the codebase, we move on to the next task. But if you look at how the rest of a tech company operates, that’s not how anything else works.

In the software world, code is never “done”; it’s only deployed. Engineers have SREs monitoring server uptime. Product Managers obsess over KPIs. Developers manage technical debt like a living organism.

Yet, for some reason, we still treat the interface—the only part of the product the human actually touches—like a static painting rather than a living system. We’re trying to change that conversation. Calling it UX Intelligence, and it starts with a simple realization: UX isn’t a service. It’s a product.

The “Pet” vs. The “Homework”

When you finish a homework assignment, you turn it in and forget about it. When you have a pet, you have to keep it alive. You have to feed it, walk it, brush it, make sure it doesn’t wander into the neighbors yard and scare squirrels like my dog Freyja or eat a cup of sugar-free pudding out of the trash like my pup Fragonard. I don’t love any product as much as my dogs, but I do try to take as good of care of them.

Treating UX as a product means taking care of the “food, water, and vaccines” for the interface. I have a massive amount of respect for the designers who spent weeks in the past meticulously hand-crafting buttons and style guides—god bless them, because that is a special kind of patience. But today, AI and automation have given us the tools to handle the vacuuming and the fine-tuning.

If we automate the “boring parts” through robust design systems and AI systems, we aren’t just saving time; we’re freeing ourselves to be strategic. We move from being pixel-pushers to being the people who maintain the dogs without needing a vet for every nail trim change. We can eliminate the wireframe monkeys, micro-copy editors, and research attendees in exchange for systems architects, content strategists, and data analysts.

Defining the Conversation Early

The core of the UX Intelligence approach is realizing that we are the architects of the user conversation. We shouldn’t be “skinning” features after they’ve been conceived in a vacuum.

We try to get in at the earliest stages of product conception and stay with it. We use user needs to establish the architecture, the language, and the governance standards that guide the build. We’re designing the content structure and flow before a single line of code is written. By the time development starts, the “steel thread” of the experience is already visible. We aren’t just making things look pretty; we’re setting the rules of engagement for how Cloudflare speaks to the human on the other side of the screen. We work side-by-side with partners to ensure the UX is moving seamlessly forward, managing each experience with the care of a dedicated product manager.

Monitoring the “Uptime” of Joy

You wouldn’t run a server without monitoring its error rates. So why do we run interfaces without monitoring user frustration?

In a UX Intelligence model, user testing isn’t a one-time event or a checkbox to tick before launch. It’s a heartbeat. We hold ourselves accountable to measurable outcomes:

Task Completion Rates: Are they getting where they need to go, or are they hitting a wall?

Aha Moments: We want users to know, use, and love the product. How quickly can we get them to that realization of value?

Support Deflection: Sometimes, a simple text update or a well-placed warning modal can save Customer Support thousands of dollars. That’s a UX win that shows up on a balance sheet.

Sentiment Analysis: What do they feel about us even if they are doing something else?

UX Tech Debt is a Real Metric

Engineers refactor code to prevent a crash. We need to refactor experiences to prevent “churn.”

Inconsistent patterns, confusing copy, or legacy journeys are “UX bugs.” To solve this, our team has to own its own backlog and work in a scrum style—planning, sprints, and retros. We don’t just live in Figma; we live in the logic of the product. If a feature is “deployed” but the metrics show users are struggling, the job isn’t over. We iterate. We polish. We fix the flat tire and move on.

Process is Not a Deliverable

There’s a mantra I keep in my head: Process is not a deliverable.

While it’s tempting to feel like talking through our thoughts and strategy is “moving the needle,” stakeholders don’t buy our design thinking—they buy the results it produces. A good idea not shipped is as useful as a chocolate teapot. One mission is to go beyond credit for ideas and enable everyone to execute at the pace of technology, becoming “force multipliers.” Build internal tools and custom components that replicate our expertise so that everyone in the company can make better design decisions and help us take care of the interface product. It’s not about hoarding ideas and talking through our eloquent thought process, it’s about doing what’s best for our product, the user experience.

We build the infrastructure to automate ourselves out of the repetitive tasks so we can focus on the strategic planning that puts us in a position to drive business OKRs.

The Rocketship

The journey from a “steel thread” to a full-fledged rocketship isn’t a straight line. It’s a series of iterations, maintenance cycles, and constant learning. And honestly, as soon as we make something fly, the possibility to make it travel through time and go under water is already on the horizon.

By treating UX as a product, we stop asking for “sign-off” and start looking for “opportunity.” We stop handing in homework and start taking care of the pet. The interface is the bridge between a business goal and a customer’s needs—and it’s our responsibility to keep that bridge from collapsing.

Because in this mindset, there is no such thing as “final_final_v3.” There is only the version that’s live, and the one we’re making better right now.