A structure for technical catalogs that need to grow, connect documentation, and let each product be found through the different paths people actually use to search for it.
The catalog grew. The structure didn't.
When does this solution make sense?
| When it makes sense | It's for | It's not for |
|---|---|---|
| A company with hundreds of products, or on its way to having them. | ||
| A company with IFUs, surgical technique guides, and certificates scattered across several places. | ||
| A company that gets inquiries from healthcare professionals searching by procedure, anatomical region, or code. | ||
| A company with a handful of products and no technical documentation: there's no catalog project there. | ||
| A subsidiary with no control over its own website. |
How this solution comes together
The filter comes last.
Before designing filters, the company needs to define what counts as a product and what it relates to.
The documentation sits next to each product page.
The team adds a new product without asking for development work.
- Product pages:1,308 → 3,227 clicks
- Catalog PDFs:1,391 → 324 clicks
- Product pages receiving visits:348 → 577
- Filtered catalog:2.6 s → 0.18 s
FAQ
Our products are in PDFs and that works. Why change?
A PDF works for printing and sending. But finding a product, comparing two sizes, or reaching the IFU means opening an entire document, and on Google the PDF competes with the product page.
Do the PDFs need to be taken down once the product page exists?
Not necessarily. Those that get visits are redirected to the product page that replaces them; those still in use remain linked from it.
Why filter by procedure as well?
The surgeon thinks about the surgery they're going to perform; the product family is how the company organizes things. Both paths have to end at the same product page.
Can the team add products without outside help?
Yes. The publishing process is designed along with the catalog: a template, required fields, and a validation path before publishing.