Organise specification tables around the buyer's selection decision, not the number of fields available in a supplier spreadsheet. Readers should distinguish a product family, model, variant and ordering code, then compare specifications using consistent units and conditions. Resolve inconsistent data before designing pages; a tidy layout can conceal an error rather than fix it.
Start by identifying differences that change selection: size, capacity, material, finish or accessories. Shared properties may appear once if their scope is clear, while exceptions should remain close to the affected model.
Establish each item's identity
Use a stable code connecting catalogue content to the approved product source and quotation request. A marketing name alone is unreliable if it repeats or changes between languages. Establish whether a code identifies an orderable item or a family requiring further choices.
Product catalogue design and Arabic adaptation benefits from these relationships being explicit. Supply a structured family, model, ordering-code and property reference rather than leaving designers to infer relationships from image filenames. If a family image differs from a particular variant, label its representative status where needed. It should not become the sole technical reference.
Choose a comparison structure
| Data situation | Suitable presentation | Review condition |
|---|---|---|
| A few differences across similar items | One row per item in a shared table | Columns mean the same thing for every row |
| Many shared properties | Shared block plus a differences table | Exceptions remain explicit |
| Families that are not comparable | Separate tables or pages | No implication of technical equivalence |
| Choices with dependencies | Available-combinations matrix | Unapproved combinations are not generated |
Do not use colour as the only variant identifier. A page may be printed without colour or viewed on a display where differences are difficult to distinguish. Put units in headings only when they apply to every value beneath them. If measurement methods or conditions differ, explain that before encouraging a side-by-side comparison.
Worked hypothetical: six lighting variants
Consider a teaching dataset for a fictional lighting family with two power values and three finishes. All codes and values below illustrate organisation only; they are not real specifications or engineering recommendations.
| Ordering code | Illustrative power | Finish | Dimension approval status |
|---|---|---|---|
| L12-W | 12 W | White | Approved in the example source |
| L12-B | 12 W | Black | Approved in the example source |
| L12-G | 12 W | Grey | Approved in the example source |
| L18-W | 18 W | White | Approved in the example source |
| L18-B | 18 W | Black | Approved in the example source |
| L18-G | 18 W | Grey | Awaiting product-owner confirmation |
Two power options multiplied by three finishes produce six items only because this example assumes all six combinations exist. If a finish is unavailable at one power, remove that unapproved combination rather than generating it automatically. Missing dimensions for one code must not be copied from a visually similar item.
Keep an incomplete item in the internal completion register or defer its publication, according to the project need and product owner's decision. Wording such as “dimensions on request” should be deliberate and approved, not a way to hide incomplete data collection. Before release, select a table code and trace it back to the underlying specification to verify the relationship.
Control units and missing values
Distinguish zero, not applicable, unknown and not yet approved. An empty cell does not communicate which one applies. Agree a small set of explicit labels and explain them where needed. Do not convert units or round values without an approved rule from the product specialist.
When Arabic text, English terminology and Latin model codes appear together, inspect their reading order in the finished layout. Arabic and English content production can support consistent language; the product owner still approves specifications and units. A smooth translation is not sufficient if it changes the technical meaning.
Ask the reviewer to inspect difficult cases, not just the first product. Useful samples include the longest name, most columns, missing data, an accessory-dependent variant and a family with an exception. These reveal whether the template works beyond the easiest page.
When a comparison interface may be more suitable
For a large variant range, filters or selected-item comparison may suit a digital channel better than an extremely wide table. That is a separate user interface design scope, including selection states, empty results and incomplete data. Designing a PDF table does not automatically include an interactive tool or stock integration.
Clean the underlying data first. Interactivity cannot make inconsistent units or duplicate codes reliable. Test a practical journey: the reader finds an item, understands the relevant difference and transfers the correct ordering code into an enquiry.
Acceptance checklist
- Each row has a valid ordering code and clear family relationship.
- The product specialist approves properties, units and exceptions.
- The same item does not carry conflicting data elsewhere in the catalogue.
- Missing values are explicit and have not been guessed.
- Images match the item or are appropriately labelled as representative.
- Arabic and English retain codes, figures and technical meaning.
- The table remains readable in its intended viewing medium.
Avoid solving dense content by shrinking everything until readers must zoom constantly. Consider splitting the comparison around the actual selection sequence instead. Equally, avoid repeating every shared property if the repetition makes the few meaningful differences harder to find.
Frequently asked questions
Must every specification appear on every page?
Include what supports selection and refer to an approved technical reference where appropriate. Do not remove a suitability-critical qualification merely to shorten the page.
Can several finishes share one image?
Yes, if finish names and ordering codes remain clear and the image does not imply every combination exists. The product owner should approve the image-to-item relationship.
Who owns numerical accuracy?
The designated product-data or technical owner. The design team transfers and presents approved information within scope; it should not invent specifications or approve engineering suitability.
What should we send LAB?
Provide a representative complex family, approved specifications, ordering codes, images and known gaps. That allows a realistic template test before applying a layout across the whole catalogue.