The Label in Figma Should Match the Column in the Database

A few years ago, we were building a demo for an oil company. The idea was relatively simple. The customer provided real operational data through Excel files, including information about ports and ships. We built a small optimization algorithm on top of that data to explore ways of reducing loading and unloading times.

Our designer started working on the interface. One of the fields was:

Ship name.

Perfectly reasonable.

So we implemented ship too. We talked about ships in meetings. We wrote about ships in presentations. Ships became part of the language of the team.

A couple of weeks later, the customer arranged tests with four people from the industry. They looked at the demo and asked:

Why does it say "Ship name"?

They didn't call them ships. They called them vessels.

Technically, this wasn't a disaster. It was still a small demo. Changing a label and some code wasn't particularly difficult.

Changing the team was much harder.

For weeks, everyone had learned to say "ship." It appeared in conversations, presentations and decks. I repeatedly had to remind people that we needed to say "vessel", especially when talking to customers. And occasionally "ship" still made it into customer presentations.

To us, the words were almost interchangeable. To people who had spent their careers in that industry, using the wrong one made us look like outsiders.

The problem wasn't the label.

We had built a vocabulary before we understood the domain.

Every translation has a cost

Imagine a company building a platform. The CEO talks about customers. Product talks about users. Design talks about clients. Frontend talks about accounts. Backend talks about organizations.

None of those names is necessarily wrong. But now every conversation requires translation.

When the CEO says "customer", everyone else has to understand which concept in their part of the system that corresponds to. When a developer reads a ticket containing "client", they need to know whether that's the Account, the Organization, or something else entirely.

Most of these translations happen so quickly that we barely notice them. But they still consume context.

Worse, translations can fail.

So my preference is very simple:

Don't translate unless you have to.

If something is called a Vessel in the domain, call it a Vessel in the company. Call it a Vessel in Product. Call it a Vessel in Figma. Call it a Vessel in the frontend. Call it a Vessel in the API. Call it a Vessel in the backend. Call it a Vessel in the database.

Or, as I often tell teams:

The label in Figma should have the same name as the column in the database.

There are technical reasons why different representations of data sometimes need mappings. A database model and an API DTO don't necessarily need to be identical. That's not the kind of mapping I'm trying to eliminate.

If the database has an attribute called name, the DTO can have an attribute called name. What I don't want is name becoming vesselName, then shipName, then displayName simply because different parts of the organization invented their terminology independently.

That's not abstraction.

It's translation overhead.

Start with the domain

This is why I like doing a domain workshop early in a project.

The interesting thing is that most product teams already explore the domain. They just do it several times.

Product managers create user stories. Designers create personas and user journeys. Engineers start thinking about entities and database models.

Three disciplines investigate the same world and produce three different representations of it.

I'd rather bring that work together.

A domain workshop isn't a single two-hour meeting where someone draws a few boxes and declares the domain solved. For a complex product, it can take multiple sessions over several weeks.

The result is surprisingly simple.

Boxes and arrows.

The boxes represent the important concepts in the domain. The arrows describe their relationships. I deliberately don't care about database keys, field types or whether a relationship will eventually be implemented as one-to-many.

We're not designing a database yet.

We're describing the world the product operates in.

That domain model sits above Product, Design and Engineering. Everything else can derive from it.

And it remains a source of truth.

If we later learn that something has the wrong name or that two concepts relate differently than we thought, we update the domain model and communicate that change to the team.

The model isn't documentation of the software.

The software is one implementation of the model.

Let the domain choose the words

Finding the right vocabulary often requires someone who actually knows the industry. That's something we were missing in the vessel example.

We were still preparing a sales demo, so we hadn't involved a domain expert. Had we done that at the beginning, "vessel" would probably have entered the project's vocabulary on day one.

And establishing a vocabulary is much easier than changing one.

This matters especially in specialized industries. Is it a ship or a vessel? A smell or a scent? What does olfactory mean in the fragrance industry? What terminology do dentists use every day?

The best term isn't necessarily the one that sounds most intuitive to the product team.

It's usually the one the domain already uses.

Large, established companies are often surprisingly good at this. Their industries have existed for decades and their terminology has evolved with them.

With younger companies, I more often see generic terminology. Everything becomes a User, Customer, Item, Unit, or Object.

Those words feel flexible. But sometimes that flexibility is a warning sign.

If your vocabulary could describe almost any business, you may not understand your particular business well enough yet.

A better vocabulary can reveal a better product

This goes beyond communication.

A better understanding of the domain can change what you're able to build.

I saw this recently while working on an existing platform. The product had evolved over several years, and people talked about partners, brands, customers, participants and organizations in different places.

When I joined the project, I struggled to understand what all of these things actually were. So we modeled the domain.

One of the important realizations was that what the old system treated as fundamentally different types, particularly brands and partners, were actually organizations playing different roles in a particular context.

That sounds like a naming exercise.

It wasn't.

In the old model, one type of organization could create something while another could only participate in it. Those capabilities were tied directly to what kind of entity the organization was.

Once we separated the organization itself from the role it played, an interesting possibility appeared: either type of organization could potentially take either role.

That opened up an entirely new part of the market without requiring us to duplicate the underlying product logic.

A domain-modeling exercise had exposed a potential expansion of the business.

That's why I don't think of domain language as documentation work.

The words you choose influence the abstractions you see.

And the abstractions you see influence the products you can build.

The whole organization should speak the same language

This isn't something I want only engineers to learn. And it isn't something I want only the product team to learn.

Ideally, the entire organization speaks the same domain language.

If the CEO happens to talk to a designer, why shouldn't they immediately understand each other? If Sales talks to Product, why introduce another vocabulary? If Engineering joins a customer conversation, why make them translate what they hear into completely different internal concepts?

The benefits show up everywhere.

Tickets become easier to understand. Slack conversations need less context. Meetings contain fewer misunderstandings. Code reviews become easier to follow. Customer presentations sound like they were created by people who understand the industry.

And onboarding becomes much easier.

A simple glossary containing the important domain terms and abbreviations can make an enormous difference during someone's first weeks. Instead of learning the vocabulary of Business, Product and Engineering separately, they learn the vocabulary of the domain.

Shared language reduces the need for coordination

I've sometimes said, somewhat provocatively, that 90% of the friction in product teams is communication.

That's not a statistic. But I don't think the exaggeration is as large as it might sound.

Look at how much time organizations spend making sure everyone understood what everyone else meant.

Status meetings. Alignment meetings. Handoffs. Refinements. Follow-ups. Presentations of decisions made by another department. More meetings to resolve what happened in the previous meetings.

Some of that coordination will always be necessary. But strong teams can eliminate a surprising amount of it.

A shared vocabulary helps. So do strong conventions and shared values.

If everyone understands the domain in the same way and has agreed on how common decisions are made, something interesting happens:

Different people start making the same decisions independently.

That's when a team becomes fast.

Not when everyone types faster.

When fewer things require coordination in the first place.

I don't particularly care what the methodology is called

There is an obvious connection here to Domain-Driven Design and its idea of a ubiquitous language.

I didn't arrive at this approach by implementing DDD from a book. I've used techniques such as Event Storming, and there are plenty of ideas in Domain-Driven Design that overlap with how I work.

But I'm generally not interested in following methodologies by the book.

Books are written for particular situations. Your job isn't to reshape your situation until it matches the book. Your job is to understand the useful ideas well enough to apply them to your situation.

I ended up modeling domains this way for a much less interesting reason:

It kept solving problems.

Communication got easier. The software got easier to structure. Onboarding got easier. Product decisions got clearer.

So I kept doing it.

And then there are coding agents

There is now another participant in the product-development process that benefits from the same approach.

Coding agents.

Imagine giving an agent a task involving a Partner. The ticket says Partner. Figma says Brand. The API exposes /organizations. The database calls it Company.

Before the agent can solve the actual problem, it first needs to discover your organization's translation table.

That's the same problem a new employee has.

But there is an additional reason why precise domain language is useful for LLMs. These models have been trained on enormous amounts of existing knowledge.

If I'm working in maritime logistics and consistently use established maritime terminology, I'm giving the model additional context about the world I'm operating in.

Ship can mean many things in many contexts. Vessel, surrounded by ports, loading operations and maritime logistics, is much more specific.

Instead of teaching the model our invented vocabulary and repeatedly steering it back toward the domain, we can use terminology that already carries meaning.

We're making better use of knowledge the model already has.

Once again, something that made collaboration between humans easier turns out to make collaboration with coding agents easier too.

Name the thing once

Naming things is famously difficult in software.

Maybe part of the reason is that we keep naming the same thing over and over again.

Business gives it a name. Product gives it another. Design needs a label. Frontend creates a type. Backend creates a model. The database needs a table.

Then we write code to map all of them back together.

I prefer a simpler approach.

Understand the domain first. Find the words people in that domain actually use. Agree on what those words mean. Document their relationships.

Then carry that language as far through the organization and the product as you reasonably can.

There will always be abstractions. There will always be technical boundaries. There will occasionally be legitimate reasons to translate.

But translation should solve a real problem, not be the default consequence of departments working independently.

So yes, I mean it fairly literally:

The label in Figma should match the column in the database.

It's not because databases should dictate design. It's not because designers should care about schemas.

It's because both should describe the same world.

This is how I build Vuesion

These aren't just ideas I write about. They're principles I've been building into Vuesion for more than eight years.

See how Vuesion works →