The folder arrives with a name like “Web catalogs” and sixty files inside. There are line catalogs, surgical technique guides, IFUs, brochures from a congress, and two versions of the same document, one ending in “final” and the other in “final_v2.” With that, someone has to design the product page for a medical device company. If they design it by looking at another company's website, the real data shows up later and doesn't fit.
Every PDF is opened before the product page is sketched
The first step is an inventory: each file, with the product or family it covers and the type of document it is. That requires opening them. The file name says little, and a line catalog and an IFU contain completely different kinds of information.
In a line catalog's tables, trade names, codes, sizes, materials, and variants sit side by side. Each of those columns is a candidate for a product page field. A surgical technique guide, on the other hand, walks through a sequence of steps with images and was approved as a single unit. An IFU has its own identification and revision. The inventory ends up showing what information exists, where it's repeated, and what's missing.
What gets broken down and what gets published in full
The criterion is how each document is used. What people look up one product at a time gets broken down: the code, the size, the variant, the material. That moves into product page fields, because a surgical technologist with a code on an order or a surgeon looking for a size shouldn't have to download a forty-page file to find it.
What's read from start to finish is published in full. A surgical technique guide is consulted as a whole, and an IFU has to keep its identification and revision exactly as they were approved. Those files remain documents, linked from the product pages they belong to. Which document gets published and which is the current version is decided by the company; the site's job is to show it in the right place.
The fields come from how people search
People look for a medical device along paths that have little in common: by code, by trade name, by brand, by anatomical region, by procedure. Each path needs its own field on the product page, entered only once, so the same product shows up on every path without being duplicated. At companies that manufacture and distribute, the brand is also what separates the company's own line from third-party lines, and it has to be visible on the product page, not in the footer of a PDF.
At SAI, an Argentine orthopedic manufacturer and distributor, the relationships were modeled before the screens. That produced a 106-field product page and five navigation dimensions with 86 terms (area of interest, anatomical region, product type, procedure, and brand) for a catalog of nearly 270 products.
One document, many product pages
A catalog that describes a whole family serves twenty products. Copying its tables onto twenty pages creates twenty places where an error has to be corrected. What gets stored is the relationship: each product page knows which catalog, which surgical technique guide, and which IFU go with it, and each document knows which product pages it belongs to.
With that relationship in place, updating a catalog stops being a manual search. The file is replaced, and the linked product pages keep pointing to the right document. The codes that were in the tables also stay on the product page, so the site search finds them, and anyone arriving by code sees the trade name, the family, and the related products.
Versions have to be visible
“Final_v2” isn't a version. Every published document needs its identification and revision recorded outside the file name, so the team knows which one is live and which one replaces it. When a new revision comes in, it goes behind the same URL and the product page doesn't change.
When it's time to load content, the same inventory becomes the publishing workflow. At SAI, Engineering fills in a bilingual template with the approved data for each product, and each product page is reviewed as a draft in preview, on the actual page, before it's published. Adding the next product doesn't require new development: the fields, the relationships, and the documents already have their place.
Services covered in this article
