Catalog structure: choose categories and separate filters

Which catalog structure decision are you making?

A catalog structure decides which groups organize products and which properties remain selectable refinements. Your deliverable is a paper architecture for eight fictional furniture and lighting products: an axis choice, a two-level tree, separate filters and complete primary placement. No store, product record or stock level changes.

A category is a navigable grouping. A filter narrows a list using a supplied property. A tree shows parent and child groups rather than a customer's sequence of visits. Finding the same product through a second route does not create a second physical item or justify copying its stock record.

The starting menu mixes “Office / Wood / Chairs / White / Lighting / Bedroom”. Some labels describe rooms, some material or colour, and others product groups. The owner needs to decide what organizes the catalog before someone polishes menu names. A more attractive label alone would leave the competing dimensions unresolved.

The V1 owner objective is explicit: each product should have one primary product-type location while other supplied uses remain discoverable. This is a fictional planning constraint, not customer research or a universal ecommerce rule. The URL structure guide addresses naming and address review later. This worksheet creates no paths to deploy, redirects, canonical decisions or indexing claims.

What must remain unchanged in the eight product records?

Preserve P1 desk, P2 dining table, P3 office chair, P4 dining chair, P5 desk lamp, P6 pendant lamp, P7 bedside cabinet and P8 bedside lamp. Each ID denotes one fictional product record, not a quantity in stock. The material and colour fields are supplied exercise values, not observations of real merchandise.

Keep room use separate from product type. P5 is explicitly usable in office and bedroom; P6 in dining room and bedroom. These are multi-valued inputs. Do not select one room just to simplify a table or infer that the rooms form mutually exclusive groups.

P7 has unknown colour. Its wooden material does not establish brown, and its bedside name does not establish white. Leave the missing field visible as a question for the owner. Filtering by a known colour cannot settle the colour of an incomplete product record.

The CRO guide asks what prevents a customer completing a useful task. This exercise has not observed customers or diagnosed a real conversion problem. Its narrower task is to construct a consistent grouping proposal from declared inputs. Product dimensions, comfort, price, availability and actual user preference remain outside the source card.

Which axis should own the primary hierarchy?

Consider a room-first tree before choosing. Office could contain desks, seating and lighting; dining room could contain tables, seating and lighting; bedroom could contain lighting and storage. It provides an understandable starting point for a shopper thinking about a room. Nothing in this exercise proves that room-first organization is inherently wrong.

The trade-off appears in P5 and P6. Both have two supplied room uses, so a room-first plan needs more than one discovery reference for the same item. A reference is not a duplicated product. If an implementation later supports those routes, its product identity and stock rules would need separate technical checking.

Now consider type-first organization: Tables, Seating, Lighting and Storage. Room stays a filter. Select this option for V1 because the owner has asked for one primary type location plus retained multi-room discovery. The reason is the supplied objective, not a claim that a source or an audience study picked the winner.

Record the cost of the choice too. A shopper beginning with a room may need a room refinement after choosing a product group. A shallow tree is not automatically best for every buyer or catalog. The customer journey map deals with stages and questions across a task; this plan organizes the products themselves rather than retelling that journey.

• Tables
  • Desks
  • Dining tables
• Seating
  • Office chairs
  • Dining chairs
• Lighting
  • Table lamps
  • Pendant lamps
• Storage
  • Bedside cabinets

Where does every product have its primary location?

Count category levels rather than indentation blindly. Lighting is level one and Table lamps level two. A product record displayed under Table lamps is not a third category level. P5 and P8 can share that leaf because they are two distinct products with different IDs.

P1 and P2 occupy the two table leaves; P3 and P4 the two seating leaves. P6 belongs under Pendant lamps and P7 under Bedside cabinets. Every primary path must exist in the chosen tree. Do not create an undocumented category to resolve a placement while leaving the actual plan unchanged.

Preserve alternate bedroom findability for P5 by referring to Lighting → Table lamps with room=bedroom and the same P5 ID. For P6, use Lighting → Pendant lamps with room=bedroom and the same P6. Neither reference creates another SKU, product or stock entry in this paper model.

Check every source ID against the placement list. Eight original records should produce eight primary placement references. The multi-room arrays do not entitle you to count P5 and P6 twice. Conversely, placing P5 and P8 in one leaf does not mean merging their records. Shared grouping and shared identity are different things.

This one-primary-location convention belongs to V1. It is not a claim about the category limits or canonical handling of every commerce platform. The sporting-goods marketing guide uses product groups and interests for offers; that broader marketing purpose does not validate these fictional placement decisions or imply that stock was moved.

What do the filters and two paper routes actually demonstrate?

Write material, colour and room as separate filter names. Supplied materials are wood, metal, glass and ceramic. Known colours are brown, white, black and amber; P7 remains unknown. Room values are office, dining and bedroom, and the P5/P6 records retain both applicable values rather than being forced into one room.

For the first modeled task, “find a lamp for a work desk”, follow Lighting → Table lamps and refine room to office. The supplied records leave P5. P8 shares the table-lamp leaf but does not have an office use in this exercise. The result checks the plan's declared data, not whether a real shopper would recognize those labels.

For “find seating for a dining table”, follow Seating → Dining chairs and refine room to dining. The expected result is P4. Suitable here means its supplied intended-use label. No seat height, table clearance, ergonomics, style compatibility or purchase suitability was measured or approved.

Decide three claims explicitly. “White must be a top-level category” does not follow from the V1 choice; it is a colour refinement here. “Two room uses require two stock records” is rejected because both references keep the same product ID. “P7 is absent from a white-only match, so it is not white” is unsupported: its colour is unknown. Missing data are not negative facts.

These are expected paper paths recomputed from the supplied records, not observed tree-testing, task completion rates or sales evidence. A future owner can use the proposal to plan a real usability check, but this exercise has not run that check or established that customers prefer type-first browsing.

How should another person reopen and inspect the proposal?

On Windows, open Start, search for Notepad and launch it. Create a new blank document headed Catalog V1. Copy the mixed starting menu, eight product records and separate properties. Write the two axis alternatives, the supplied reason for selecting type-first and the extra room-refinement step that choice can require.

Add the two-level tree, three filter lists, all primary placements and the same-ID bedroom references for P5 and P6. Record the modeled P5/P4 task results, three claim decisions and the question about P7 colour. Press Ctrl+S, choose Documents, enter catalog-V1.txt and select Save. Close the editor.

Open Documents in File Explorer and double-click catalog-V1.txt to reopen the named file. Check that all eight source IDs have one primary placement, that the lamp IDs have not been merged or duplicated and that P7 still has unknown colour. Confirm P5 and P6 still retain two room values. This is local artifact readback, not an actual store or user test.

WooCommerce documentation supports the distinction between hierarchical categories and attribute-based filtering. Adobe Commerce documentation describes refining category lists by available attributes within its configuration context. Neither source proves our chosen tree or licenses treating its interface details as universal. No software installation, configuration, product import or live catalog change was performed.

A proposed fifteen-minute cognitive budget gives three minutes to source records, four to the axis comparison, five to placements and paper tasks and three to saving and reopening. It is a planning allowance, not measured user performance. In earlier public writing I discussed perfectionism delaying useful work; the application is finishing one inspectable plan before expanding the job. The image SEO guide addresses another product-content task, not proof of this catalog's discoverability.