How many customers do we have?

Design resolves business meaning every day. We just don’t have a practice for preserving it.

I’ve written before about a User object scattered across a product’s surfaces: the profile, the directory, the picker, the admin table. This is the harder version of that problem.

So if we zoom out from User, what we really run into is “Customer.” And customer isn’t one thing in your software.

In the CRM, a customer is an account: a company name, a domain, an owner, a segment, and a lifecycle that might run prospect, qualified, active, churned.

In billing, a customer is the entity that pays. That one lives closer to the Subscription: customer_name, customer_email, payment status, renewal dates, and its own lifecycle: trialing, active, delinquent, terminated.

The same word exists as two objects with two distinct life cycles governed by two different parts of an organization.

Jessica Talisman names the mechanism in a recent essay, Before the Structure: when two systems merge customer records and one stores a single name field while the other splits it into first and last, “the integration fails because the two systems answered ‘what is a resource’ differently and the answers were never reconciled.”

Other disciplines already have language for this problem. Domain-driven design calls it the bounded context: the same word means different things in different parts of a system, and you translate between them on purpose. The data world calls part of it the semantic layer: define a metric once so two teams stop reporting different numbers for “revenue.” The knowledge-graph and taxonomy people call it concept governance.

Claude responded: Kurt Cagle, who edits The Ontologist, works the same problem from the ontology side in a post called Structure vs.

Rewrote passage tightening mechanics and sharpening resonance

Rewrote passage tightening mechanics and sharpening resonance

Kurt Cagle, who edits The Ontologist, works the same problem from the ontology side in a post called Structure vs. Concept. He separates the concept from its structures. There is one shared idea of Customer, and there are many structural versions of it, each shaped by the system that needs it, each pointing back at the idea instead of competing to be it. The dependency runs one way. A structure knows what it stands on. The concept never learns who’s standing on it.

“That asymmetry is load-bearing,” he writes, and it is. It’s how you hold many versions of one thing without any of them having to win.

Talisman comes at it from the other direction, from how knowledge gets organized in the first place. Her conclusion is blunt: “No single universal scheme exists or ever will, because what is meaningful to one culture or domain is not meaningful to another.”

That plurality is permanent. You don’t get to one true Customer by trying harder.

Cagle and Talisman don’t agree on everything, but they agree on the shape of it: meaning is plural, and plural meaning has to be governed, on purpose, by someone.

The engineers, the data teams, the ontologists are all having that conversation. They have words for it and rules for it.

Design is the exception.

Object-oriented UX taught us to find the objects before we design the screens. Information architecture has always been about what words mean and how they’re organized. But that thinking lives in research decks and workshops, not in the system we ship. None of it governs how a customer is defined as it crosses from billing to support to analytics. None of it survives in the design system the next designer inherits.

Our idea of context is usually the screen: the profile, the directory, the admin view, the step in a workflow. That context is real and useful but incomplete.

Because the business doesn’t experience Customer as a screen. It experiences Customer as identity, payer, account, relationship, entitlement, risk, contract, support history, revenue, permission, lifecycle.

Those meanings exist whether design has a definition for them or not. And most of the time, we don’t.

So every time a feature lands, we do the same thing. We bring the visual parts and assemble the meaning along the way, by hand, in mocks, computed props, conditional rendering, copy decisions, and “I think we show email address here but not there.”

Design does resolve meaning. We do it every time we decide which customer name appears in the header, which email belongs in the row, which status deserves a badge, which action is available, which ambiguity gets hidden, and which ambiguity has to be explained. But we do it one surface at a time, with whatever context each designer can gather from their PM or dev lead, and the decisions rarely change the system. The next designer solves the same semantic problem again, from scratch, under a different deadline.

Our practice treats semantic resolution as individual judgment instead of shared infrastructure.

We stopped at the generic bag of pieces and ceded the rest of the territory to whoever owns the database, the service, the metric, the policy, or the roadmap. Then we wonder why we’re not in the room when the business decides what a customer is.

The data side can hold two definitions of a customer forever, one in billing and one in identity, and never reconcile them. The ontology can preserve multiple concepts. The semantic layer can expose competing metrics. The API can return what its bounded context knows.

The interface can’t do that blindly. The stack can stay plural. The screen can’t. Design is the one layer where the plural has to resolve to one, not in the database or the model, but at the moment of use.

A person looks at one screen. They see one customer. They act on one representation. They suspend, refund, invite, approve, export, contact, assign, or delete based on what we put in front of them.

The moment we render “the customer,” we’ve reconciled every definition we chose to include, exclude, rename, prioritize, suppress, or explain.

Look at what “customer” actually means inside one company.

A customer in the CRM may be an Organization.

A customer in billing may be a payer, an account, or the entity attached to a Subscription.

A customer in support may be the account receiving service, with contacts, entitlements, and history attached.

In analytics, “customer” may not mean a person or an organization at all. It may mean whatever the business has agreed to count: active accounts, paying accounts, subscribed organizations, unique users, or some carefully filtered metric in a dashboard.

Those aren’t display variants. They’re different answers to the same business word. A customer who lives as four records across four systems is four customers. Voldemort needed dark magic to split a soul. You just needed a CRM, a billing system, a support tool, and a dashboard to split Customer.

Before design decides what to show, it has to know which answer the surface is using.

And if the design system has no answer for those, the work will happen anyway. This is one reason the “seat at the table” complaint keeps ringing hollow.

Designers often say the business doesn’t listen to us. That we are brought in too late. That people treat us like decorators. That our opinions aren’t respected.

Sometimes that’s true.

But there’s another side to it.

When the business is deciding what a Customer is, what an Account is, what a Subscription means, what counts as Active, who can suspend whom, what state is reversible, what risk must be surfaced, what relationship grants authority, we have to bring something to that conversation.

Too often, we bring the screen.

A screen matters. A screen is where the business becomes usable. But if our systems only describe the visual layer, we shouldn’t be surprised when the deeper conversation happens somewhere else.

The business is arguing about objects.

Design is showing up with components.

That’s not a moral failure. It is an absence of practice.

We built mature systems for color, type, spacing, accessibility, responsive behavior, component states, contribution models, and visual governance. That work mattered. It still matters. A product without that foundation is chaos.

But we didn’t build equally mature systems for the business objects those components represent.

We can tell a team how to use a badge. We often can’t tell them what lifecycle state the badge is expressing, which service owns that state, whether the label is canonical or translated, whether the same state appears differently in another workflow, or what happens when two services disagree.

That’s where design loses leverage.

Not because we lack taste.

Because our systems don’t preserve the kind of judgment the business is actually organizing around.

The missing design layer is not another component catalog. It’s a way to see what each part of the business already says a customer is, where that meaning comes from, who governs it, and how those meanings should resolve when a person has to act.

On a real team it can be unglamorous: one page that lists Customer beside every system that defines it, who owns each definition, the lifecycle each one tracks, and a plain rule for which definition wins on a given surface. The CRM’s account, billing’s payer, support’s serviced account, analytics’ counted unit, side by side, with the conflicts marked and the resolution written down instead of re-argued in every new mock.

In one company, that may mean pointing the whole product at one canonical definition of Customer.

In another, it may mean preserving several definitions and making the translation explicit: identity customer, billing customer, support customer, account owner, subscriber, payer.

The choice is not the same everywhere. That’s the point.

Design doesn’t need to settle the pluralist-versus-monist argument for the whole business. But as designers, we should know which argument the business is making, where the conflicts are, and what representation is honest in the moment of use.

In most places the raw material is already there: a semantic layer, a service contract, a data dictionary, a lifecycle diagram. The gap is on design’s side, not the data’s.

Design shouldn’t own the customer.

But design should know what the company means by customer, where those meanings conflict, and which version of that truth a person is being asked to trust on screen.

Because the interface is where plural meaning stops being theory and becomes something a person acts on.