Attributes and families: what belongs together

Once every variant is its own item (see why a sweater with a leash hole is its own item), a range of dog sweaters is a few hundred items, and the question becomes how to hold them so you can create them in one go, state their recipes on one grid and read the reports a range raises. Intakes gives you two words for that, and the whole art is in deciding which differences go where.

• An attribute is a question you can ask of an item: Colour? Size? Sleeve? It has the answers you use, in your own words and your own order.
• An item family is a set of items that the same questions apply to. It declares which attributes its members vary along, every member answers every one of them, and no two members give the same set of answers.

That second definition is deliberately not “one product”. A family is the set of things the same questions apply to, and reading it that way is what makes the decisions below fall out one after another instead of being argued case by case.

A difference is an attribute if you would ever compare across it

A maker sells a dog sweater in a full-body and a half-body cut, with a long or a short neck, a full or a cuff sleeve, with or without a leash hole, in seven colours and five sizes. Which of those are attributes, and which are separate families?

Here is the test: would you ever want to compare sales across this difference? Which sleeve earns more? Does the half body outsell the full body? Which colours are worth restocking? If the answer is yes, it is an attribute, because that comparison exists only for attributes. The sales breakdown ranks one attribute’s values against each other; there is no breakdown “by family”, and nothing above a family to compare two of them on.

So the tempting layout — a family per structural design, Full Body Cuff Sleeve Dog Sweater with only colour and size as attributes — throws away exactly the questions a range exists to answer. Sleeve would no longer be an attribute anywhere, and “which sleeve sells” would have no answer at all. Body, neck, sleeve, leash hole, colour and size are all attributes of one family, Dog Sweater, and the family’s members are the combinations you actually sell.

Two things that look like costs of one big family are not:

• Not every combination has to exist. A family requires every member to answer every question and no two members to answer alike. It never requires every possible combination to be present. Create the members you sell; leave the rest unticked. An order for a combination that does not exist is reported by name, never guessed at.
• The grid does not get harder, only longer. The family recipe grid has one row per member, and its filters follow the attributes: filter to Half Body and set the yardage, filter to Cuff and set the sleeve amounts. Filling six hundred rows is a dozen filtered fills, not six hundred cells.

A boundary is forced when a question stops applying

The other direction has a hard rule rather than a judgement. Every member must give an honest answer to every attribute its family declares. The moment something has no honest answer to one of the questions, it belongs to a different family. A dog bandana has no sleeve. Thread has no size. A bolt of fabric has no body. Those are family boundaries whether you like them or not, and they are the reason the whole catalog is not one family.

Within a set where every question applies to everything, one family is always possible, and splitting it further is a choice about how things read, paid for with the comparisons above.

The subtle case: three fabrics, three colour attributes

The same maker sells the sweater in fleece, in lycra and in nylon. Each fabric comes in its own colours: seven fleece colours, three lycra, five nylon. The obvious layout is one Colour attribute holding all fifteen, with Fabric as a seventh attribute beside it. It is obvious, and it is wrong for her — and the reason is worth understanding, because it is the same test again with a different question in hand.

An attribute is a question, and the shape of its answer decides its scope. The question this maker asks of a colour is not “which colour sells” but “which fleece colour should I buy more of”. She buys fleece bolts by fleece colour and nylon bolts by nylon colour, and a white that sells well across all three fabrics tells her nothing about which bolt to reorder. When the answer is only ever per fabric, the attribute is per fabric: Fleece colours, Lycra colours, Nylon colours.

Two concrete things follow:

• The breakdown answers her question directly. Pick Lycra colours and the chart shows three bars with shares among lycra, and one line beneath for everything sold in no lycra colour. With one shared Colour attribute she would get fifteen bars with shares of the whole, and the three she wanted to compare scattered among the other twelve.
• Three whites are three values. Value names are unique within an attribute, not across the workspace, so Fleece colours: White and Nylon colours: White are different answers with their own sales. One shared White would sum them, which answers a question nobody asked.

And the forced boundary follows too. A family declaring Fleece colours cannot hold a nylon sweater, which has no honest fleece colour — so per-fabric colour attributes mean per-fabric families: Fleece Dog Sweater, Lycra Dog Sweater, Nylon Dog Sweater, each declaring body, neck, sleeve, leash hole, its own colour attribute and size. Which is the completeness rule giving the same answer as the question did. When the two tests agree, the layout is right.

What she gives up is fleece-versus-nylon as a single chart, since no attribute spans the three families. The three family rollups read side by side, and if she wants it on the dashboard the fabric can be the item’s category, which the category breakdown ranks. What she should not do is add a Fabric attribute with one value per family to get it back: every name would then say the fabric twice.

Naming the values

A value is one value when you would answer the question with the same word. Two dye lots of the same solid green are one Green. A green plaid is not a green that happens to be woolen; it is a different look you would never confuse with the solid, so it is its own value, named as you would say it: Green plaid, Tartan, whatever the fabric is called.

There is an anchor for that name, and it is the fabric itself. A sweater’s colour is its fabric’s colour, so use the bolt’s own value. The bolts are items too — a Fleece family varying by Fleece colours, by the same rule — and when the sweater’s White and the bolt’s White are literally the same value, the recipe grid’s fabric column can follow the colour and the reports on the two line up. Name the bolt first; the sweater inherits the word.

Resist a Pattern attribute (Solid / Plaid) until pattern genuinely varies within one fabric. Until then it would put Solid on every fleece sweater’s name for a distinction that only exists inside the wool.

Names read in the order you declare

A member’s name is composed from the family and its values in the order you put the attributes: Fleece Dog Sweater Half Body Crew Cuff Olive L. Every token is a fact, so choose the order in which you would say it — the structural differences first, colour and size last — and choose value words that are distinct across attributes, so a name never reads Long Long Yes. Reordering later is one drag, and the names catch up when you ask, never behind your back.

Listings can never be finer than families

One more thing decides layouts from outside the catalog. A marketplace listing points at exactly one family, and every question the listing asks a buyer at checkout — the cuff sleeve, the leash hole — has to map to an attribute of that family. So a family must contain every item one listing can sell. If a listing’s checkout options span body, neck and sleeve, those are attributes of one family, and no layout that splits them into separate families can be matched to it. The shop’s listings put a floor under how coarse the families have to be; the comparison test usually asks for the same thing.

The short version

• Attribute when you would compare across it. Family boundary when a question stops applying.
• An attribute’s scope follows its question: if the answer is only ever “per fabric”, the attribute is per fabric, and the families follow.
• Create the combinations you sell, not every combination; a family never demands the full grid.
• Name values the way you say them, and name a made thing’s colour after the material’s.
• A listing’s checkout questions must all be attributes of one family, so start from what the listing sells.

The rule that makes each variant an item is the previous concept. Families, attributes and the member grid are on the product page.