UX Is not a layer. It's a product decision.
UX design has always been about reducing the cost of wrong decisions before they reach the code. This article explores how connecting design work to business metrics changes everything, with real examples from the BIA assistant at Bradesco and a framework of three questions that reframe how designers enter any project.
6 min read
There is a conversation that happens at some point in every designer's career. Someone from product, business, or technology looks at your work and asks, with complete good faith: "but isn't this just the visual part?"
After nearly a decade designing digital products for major financial institutions, I've learned that question is not an offense. It's a diagnosis. It means UX is not yet connected to what the business actually measures.
And when it isn't connected, it gets treated like a layer.
What UX Actually Decides
Experience design is not about making the product look good. It's about reducing the cost of a wrong decision before it reaches the code.
Every flow you design is implicitly answering business questions: will the user understand what to do here? Will they trust it enough to continue? Will they need support afterwards? Will they come back?
These questions have measurable answers. Flow completion rate. Drop-off rate by step. Support ticket volume. Time to first value. Day-30 retention.
When UX doesn't make that connection explicitly, another team makes it instead, with less context about user behavior, and with metrics that don't capture friction until it has already become a problem.
The BIA Case at Bradesco
When I worked on BIA, Bradesco's virtual assistant, one of the most critical design decisions had nothing to do with the interface. It was about when in the journey the assistant should take over the conversation, and when it should hand off to a human agent.
That transition point looks like a flow detail. In practice, it determined three things at once: the user's perception of trust in the digital channel, the volume of transfers to human support, and the first-contact resolution rate.
A poorly designed handoff, one where the user arrives at the agent without context, has to repeat everything they already told the bot, and still doesn't get their issue resolved, is not just a bad experience. It's operational cost, channel abandonment, and erosion of trust in the digital product.
Designing that flow correctly required understanding the support operation, the real limits of the conversational model, and how users behave under financial stress. It was not a UI decision. It was a product decision with a direct impact on business metrics.
Why This Connection Still Isn't Obvious
Part of the problem is historical. For a long time, UX entered projects after the structural decisions had already been made. The product was defined, the architecture was set, and the designer received a list of requirements to "build the screen."
In that model, UX does become a layer. Because it entered too late to influence what actually matters.
The shift happens when the designer enters earlier, in problem definition, feature prioritization, in deciding which flow to focus on in the next cycle. Not as a guest, but as part of the decision.
That requires designers to speak the language of business. Not to abandon the user as the center, but to connect what the user needs to what the business measures.
Three Questions That Changed How I Work
Today, before any wireframe, three questions come first.
What does the business need the user to do? Not what the stakeholder asked for. The actual outcome: activation, transaction, renewal, referral. That defines what the flow really needs to solve.
Where does the user drop off today, and why? Friction has an address. Before proposing any solution, I want to know at which step people stop and what's causing it.
How will we know if it worked? Every UX delivery should have a metric attached to it. Not "we improved the experience," but: did the completion rate for this step go up? Did the support ticket volume for this flow go down?
When these questions enter at the beginning, design stops being judged by appearance and starts being evaluated by outcome. That is the difference between UX as a service and UX as strategy.
What Changes in Practice
Experience problems identified late cost more to fix. A flow that confuses users and is only discovered after launch requires development rework, another test cycle, and at best, an update that arrives after part of your users have already given up.
The same problem identified before the code, during the design phase, costs a conversation, a flow adjustment, and a round of user testing.
That is the business argument for UX entering early. It is not about design being important. It is about where the cost of discovery is lower.
