The Material of Teaching · Cross-functional working session
In this article
- The decision: audit product names as part of the interface, not as copy — the usual failure is structural, not a vocabulary problem.
- The method: score names on consistency criteria (attribute order, label matching, descriptor presence), not just clarity and tone, so the real fault becomes visible.
- Who does what: research owns the naming structure; category owners own what the structure prioritises; content, PIM, and engineering apply it.
- The rule: when the same attribute is labelled differently across products, users miss it entirely — as if it weren’t there.
A model to adapt, not a fixed rule. The criteria, weights, and naming template here are a starting point. Different categories weight them differently, and your portfolio will need its own structure — deciding how it bends to your catalogue is part of the work.
The decision this article is about: in ecommerce, a product name isn’t copy — it’s part of the interface. So a naming audit shouldn’t be run like a copy review, asking whether each name is clear and on-brand. It should be run like an interface audit, asking whether names are structurally consistent across the listing, so users can scan and compare without opening anything. Almost always, the problem you find isn’t the words. It’s the structure.
The situation
A listing page works when users can compare and shortlist without ever opening a product page. They scan down the column, recognise the attribute that matters — size, type, finish, quantity — and eliminate options. That only happens if the same attribute appears in the same place, with the same label, on every name.
When naming is inconsistent, that breaks. The user opens one product page, then another, goes back, forward again — doing the work the listing page should have done. The product page becomes the workaround for a broken listing page. Baymard Institute’s research on product lists points the same way: hard-to-scan product information slows users almost as much as having no information at all, and titles in list views have to support comparison at a glance.
Several teams already shape these names, usually without coordinating. Category and product managers nominate what goes in a name. The content team owns wording and naming conventions. The product-data (PIM) team owns which attributes exist and how they’re stored. Engineering renders the name in the listing. Each optimises its own field, and the structural consistency — the thing the user actually needs — is owned by no one.
The trap
The reflex is to audit names the way you’d review copy: is each name clear, is it on-brand, does it read well? Score names this way and most of them pass. They are clear. They are on-brand. The audit comes back mostly green, and the scanning problem is still there — because clarity was never the failure.
The failure is structural, and it’s invisible at the level of a single name. Attribute order varies between collections. Size labels don’t match — “12-piece” in one place, “set of 12” in another, “large” in a third. A descriptor is explicit in one name and implied or missing in the next. None of it looks wrong when you read one product. All of it becomes visible when you step back and read the column.
For a junior researcher, this is the lesson worth keeping: when names don’t scan, audit the structure across products, not the words within one. The fault lives in the relationships between names, not inside any single name.
The method: score structure, not just words
The fix is to audit names against criteria that separate structural quality from linguistic quality, and to weight the structural ones properly. A workable criteria set:
- Clarity of meaning — does the name communicate what the product is? (Linguistic. Usually already fine.)
- Alignment with user language — does it match how users describe the thing? (Linguistic. Usually already fine.)
- Structural consistency — does this name follow the same attribute order and labelling as its neighbours? (Structural. This is where the failures hide.)
- Distinctiveness — can a user tell this product from the one next to it on text alone? (Structural in effect — identical names create a comparison dead end.)
- Scalability — will the structure still hold when the range grows?
Score a portfolio this way and a pattern emerges that a copy review would never surface: names lose almost no points on the linguistic criteria and most of their points on the structural ones. That gap is the finding. It says, in numbers, that the problem the team keeps trying to fix with better wording is actually a problem of inconsistent structure — and no amount of rewording will fix it.
The structural diagnosis also produces a concrete target: a naming template the whole portfolio can follow. Something like collection + function + material + quantity + size, applied in a predictable order. The exact slots are yours to define; the point is that there is an order, and every name obeys it.
Who does what
The naming structure is a shared object that no single team currently owns, which is exactly why it drifts. The audit’s job is to assign that ownership.
- Researcher — owns the naming structure: runs the audit, defines the criteria, sets the template (attribute order and labelling rules), and identifies where scanning breaks. Owns the system, not the individual names.
- Category / product owners — own what the structure prioritises. A name’s job differs by category: some categories need the name to fully describe the object, others need it to anchor a collection identity with specs handled elsewhere. Category owners set that weighting within the shared structure — the one place category-specific judgement belongs.
- Content — applies the template to wording, owns the naming conventions, and removes duplication so each attribute has one canonical form.
- PIM / product data — confirms the attributes the template needs actually exist and are stored consistently, so the structure can be populated rather than improvised.
- Engineering — renders names in the listing so the structure survives into the interface the user actually sees.
This is the orchestration point: the structure is one decision, owned by research; the weighting of what matters within it is a category decision. Separating those two — a shared system, with category-specific priorities inside it — is what stops five teams each optimising a different answer. Baymard’s research supports exactly this shape: consistency and predictable attribute order, with category-appropriate density, rather than one rule applied flatly everywhere.
The rule that prevents the expensive failure
The failure that costs the most is also the quietest, because it doesn’t look like a failure at all. When the same attribute is labelled differently across products — “12-piece” here, “set of 12” there — users don’t see two versions of the same thing. They miss the attribute entirely, as if it weren’t there. The information is present, technically, and functionally absent.
So the rule is one sentence: an attribute the user can’t find by scanning is an attribute that isn’t there. Consistency isn’t tidiness — it’s the difference between information that exists in the database and information that exists for the user. A name that’s clear in isolation but inconsistent with its neighbours has failed at the one job a listing-page name has.
For a stakeholder, that’s the question to ask of any naming review: did we check whether the same attribute is labelled the same way everywhere — or only whether each name reads well on its own?
The instrument
This article comes with a naming consistency scorecard — a spreadsheet that scores a set of product names against the structural and linguistic criteria separately, weights them, and shows the gap between the two. It surfaces the structural failures a copy review hides, with category-specific weighting built in so different parts of a portfolio can prioritise differently within one shared structure. Drop in your names and it shows you where scanning breaks.