The language nobody taught you

There is a meeting that happens in every product organisation, and designers are often not in it. Not because they weren't invited. Because when they were invited, they didn't make the case for staying.

It's the meeting where budget gets allocated. Where headcount decisions get made. Where someone draws the line between what the company will invest in and what it will deprioritise. Designers often experience the output of that meeting as something that happens to them. A team gets cut. A project gets shelved. A roadmap gets reordered in ways that seem to contradict everything the design team just spent six months learning about users.

And the response, in most design teams, is frustration. Followed by a Slack message. Followed by a resigned shrug and a new sprint.

But the meeting was not rigged against design. Design just didn't show up in the room's language. And those are different problems with different solutions.

I spent a long time believing that good work would speak for itself. This is a belief that design education quietly installs and almost never corrects. You build a portfolio. You learn the craft. You develop an eye. And somewhere in that process you absorb the idea that the quality of the work is its own argument.

It is not. But the belief is understandable, because early in a career it is sometimes true.

At a large enterprise I worked at, I watched a research project get defunded three weeks before it was due to deliver findings that would have directly informed a major product decision. The research was rigorous. The methodology was sound. The team had done everything right.

But the research lead presented its value in design terms: user empathy, informed decisions, reduced rework. All true. All invisible to a CFO looking at a line item and asking what the return was.

The project got cut. The product decision got made without the findings. And six months later, the product failed in exactly the ways the research would have predicted.

That is not a research failure. That is a translation failure. But it is also not unusual. I have seen versions of that story at companies of every size, in every market I have worked in. The pattern is consistent: strong design work, weak business case, quiet defunding.

Business literacy for designers is not about learning to love spreadsheets. It is about understanding that every design decision lives inside a commercial context, and that context has a language, and the people who control resources speak that language fluently.

The language is not complicated. It has a small vocabulary: revenue, cost, retention, conversion, churn, margin, time to value. It connects decisions to outcomes in terms that are trackable. It answers the question "what happens to the business if we do this?" rather than "what happens to the user if we do this?"

Both questions matter. But in a resource allocation meeting, only one of them moves money. That is not a flaw in the meeting. It is the meeting's job.

The designers who hold influence are the ones who answer both questions in the same breath. "This onboarding redesign improves the user's first experience, and our data suggests that users who complete the full onboarding are retained at twice the rate of users who don't. That is worth measuring."

That sentence is not a compromise. It is the same design thinking, translated. But it lands in rooms where the previous version did not.

The resistance I hear from designers when this comes up is usually one of two things.

The first is that reducing design to business metrics corrupts the work. That design is a humanist discipline and the moment you start valuing it in revenue terms you have already lost something. I have some sympathy for this. But it is also a position that only works if someone else is making the business case on your behalf. And in most organisations, that someone is a VP who is two steps removed from the design work and defending it with half the information.

The second resistance is simpler: nobody taught me this. Design school did not cover CAC. My first job did not require me to understand margin. I have been hired to make things, not to run a P&L.

This is entirely true. But it explains the situation without changing it. The gap does not close by waiting for someone to teach you. It closes when you start treating the business context as part of the design brief, not a constraint imposed on top of it.

The senior designers I have mentored who made the largest leaps in influence did not learn business literacy from a course. They learned it by sitting in more rooms, asking more questions, and stopping themselves every time they were about to present work without also presenting the business question it answered.

The muscle builds slowly. But it builds.

The first time you walk into a design review and say "this reduces support escalations by an estimated 20%, which represents approximately 40 hours of support team time per month," and you watch the head of operations sit up slightly straighter, you understand something no portfolio can teach you.

You understand that craft without context is a hobby. But design with a business case is a strategy.

The meeting is still happening. The budget is still getting allocated.

The only question is whether design is in the room in a language the room understands.