You need to “learn to speak the language of business.” This is undoubtedly one of the most common pieces of advice given to those new to UX Design. Yet it is rarely explained with sufficient clarity.
Many people interpret it simply as a matter of vocabulary: learning to talk about ROI, OKRs, or churn rate during meetings with Stakeholders.
Others view it as a lack of quantitative data: “If you don’t speak in hard numbers, they’ll never consider your recommendations.” This leaves many design teams waiting for metrics that are often unavailable or rarely arrive on time.
I believe that speaking the language of business isn’t a matter of simply vocabulary or access to data. To me, it means describing a UX problem in terms of its consequences for the organization: costs, risks, revenue, or time.
The problem isn’t that they aren’t listening to you
A few years ago, I worked as a UX Lead at a financial services company. I had a highly motivated design team, especially when it came to defending their decisions to Stakeholders.
In one meeting, the Head of Product was pushing for an implementation for one of the company’s strategic products, an implementation the design team considered deeply flawed. One designer stepped up to defend the team’s stance with a single phrase: “We need to put the user at the center.”
Internally, the whole team cheered that comment. Unfortunately, it didn’t highlight any measurable consequences for the organization. It failed to tell the Head of Product or the other Stakeholders what would happen if the implementation proceeded exactly as proposed.
The decision-maker isn’t evaluating whether you are right about the design or the users (even though you probably are). They are weighing where to allocate limited resources. If your argument doesn’t fit into that comparison, it is excluded from the discussion before anyone even puts it on the table.
This usually has nothing to do with an organization’s UX maturity level, nor with a general lack of interest in users or in your professional judgment. Often, it simply means you presented data that the budget decision-maker cannot use, because it isn’t expressed in the terms they actually compare: costs, risks, revenue, or time.
How to gain greater Stakeholder buy-in
Each of the following examples presents the same UX finding in two different ways. The first version expresses only a judgment or opinion; the second highlights a concrete consequence for the organization:
- From “this is a bad experience” to “this will increase support tickets”
The first version of the finding is merely an opinion on the quality of a product or service’s UX. The second addresses an operational cost, one that has an owner, a budget, and someone accountable for it every month. - From “we need more research” to “we are about to commit six months of development time to an unvalidated assumption”
The first version sounds like UX is asking for more time. The second describes exposure to a risk that already exists, whether you point it out or not. No one approves extra time just for the sake of it, whereas anyone would approve mitigating a risk that has been clearly identified. - From “this UI design increases cognitive load” to “this UI design will increase the likelihood of users abandoning the task”
Few people outside the design or UX team are likely to know what “cognitive load” means or to have heard of Hick’s Law. The problem isn’t the technical term; it’s that the first version names the cause (the user’s mental effort) rather than the consequence. The consequence is where users drop off in the conversion funnel, something Stakeholders do monitor closely and regularly.
A design problem is prioritized alongside other design problems. A business problem (or risk) is prioritized alongside other business risks, and that is the forum that holds the budget. It is not a matter of inflating the problem, but of placing it on the list where decisions are actually made.
How to practice this week
- Take your most important UX finding of the month and express its impact in a quantifiable unit, such as dollars, hours, tickets, steps, or development days.
- Find out which metrics the decision-makers in your organization track.
- Provide a range rather than an adjective. Talking about “between 200 and 400 support tickets per month” invites discussion, whereas calling something simply as a “bad experience” shuts the conversation down before it even starts.
If you would like to apply this exercise to a real scenario of your own rather than in the abstract, let’s review how you present your UX findings together in a mentoring session.