One Project, Several Service Categories: A Gallery Pattern Without Duplicate Descriptions
A public project gallery usually groups work by service: for example "Kitchens", "Storage" and "Renovation". Real projects often belong to more than one group. The tempting shortcut is to create the project twice, once per category. Then the descriptions drift apart, a correction is made in one place only, and the gallery quietly contradicts itself. This article proposes a workflow for keeping one description and several category memberships. It is an example process, not an observed client result.
Core principle
The project is one record. The categories are labels pointing at it. A category page shows a card that reads from the single record.
Inputs
Use a hypothetical sample. A fictional studio lists a project called "Narrow galley kitchen with built-in pantry". It fits "Kitchens" and "Storage", and arguably "Renovation". Gather:
- A project record: title, one description, image set, and a short summary line.
- The list of categories with a plain definition of each.
- A proposed membership list for the project.
Decision branches
Step 1: For each candidate category, ask whether a visitor browsing that category would feel the project belongs. Use the category definition, not instinct. If the answer is "somewhat", decide whether the visitor would be disappointed or just mildly surprised. Disappointed means leave it out.
Step 2: Choose a primary category. This decides which category label appears on the project's own page and in any breadcrumb. Other memberships are secondary. Having a primary is a choice some teams make to keep navigation predictable. Teams with no breadcrumbs may skip it.
Step 3: Decide how the card appears in each category. Default: identical card everywhere. Exception: if a category needs a different emphasis, add a short per-category note field rather than a second description. For "Storage", the note might say "Focus: pantry layout".
Step 4: Decide ordering. A project in three categories can be placed independently in each. Keep ordering per category, not on the project record.
Stop conditions
Stop if a project would need a materially different description in two categories. That signals two separate projects or an unclear scope, and needs an editor's decision. Stop if a category has fewer than a handful of projects after assignment, because very thin categories may be better merged. Stop if membership exceeds what a visitor could reasonably expect; a project listed under every category stops being informative.
Worked example
The galley kitchen project gets primary category "Kitchens", secondary "Storage". "Renovation" is rejected because the definition says "structural or whole-room change" and this project replaced fittings only. On the Storage page the card shows the same title, image and summary, plus the note "Focus: pantry layout". Later the studio corrects the stated dimensions. Because there is one record, both pages update together.
Page behaviour to specify
The project page should have one address regardless of which category the visitor came from. Specify that the page shows the project's categories as links, and that the primary category is not hidden. Avoid asserting how search engines treat this; simply ensure you do not publish two pages with the same text.
Acceptance test
Pick one multi-category project. Edit one sentence of its description in the single record. Then open each category page where it appears and the project page itself. The test passes if the changed sentence is visible everywhere the description appears, the card in each category links to the same project address, the per-category note appears only where it was added, and removing the project from one category removes its card there without affecting the others. Also confirm that no two records in the gallery share an identical description. Log any duplicates found and merge them.
Conclusion
One record with several labels keeps a gallery honest and cheaper to maintain. Define categories plainly, pick a primary where it helps, use short per-category notes instead of copies, and stop when a project needs two stories.