Content types
We define what needs to exist as its own entity because products, courses, and events have different data and life cycles.
Services › Web design and development › Content architecture
Content architecture
We model products, documentation, courses, and other content before designing how they're displayed. We define what information exists, how it relates, and the different ways a person should reasonably be able to find it.
The structure is ready to take in new products, documents, languages, and content without having to decide all over again where each thing goes.
A product can have more than one way in.
Anatomical region, Procedure, Product type, and Brand lead to the product; the product leads on to documentation, technique, and training.
Before designing the filter, decide what it connects.
The architecture defines the pieces of the system and the rules that connect them. Then navigation, search, filters, and product pages can be built on a shared logic.
Documentation
IFUs, surgical technique guides, and product pages stay linked to what they describe, with a stable place even if the navigation changes.
Taxonomies and relationships
Families, procedures, anatomical regions, and brands connect content without duplicating it.
Navigation and filters
With the relationships clear, we decide what becomes a filter, what goes into navigation, and what is handled through free-text search.
Search
Site search reflects the ways people actually look things up: trade name, code, brand, or registration number.
A model for each content type
We define the fields for each content type, and every field has to justify the work required to maintain it.
How it's defined
The structure takes shape when the real material is on the table.
Inventory
We gather products, documents, categories, current content, and the ways each team organizes them.
We also uncover synonyms, exceptions, and relationships that are currently known only by people who work with the portfolio every day.
Model
We define which content types exist, what information belongs to each one, and how they link.
We work with real examples, including difficult cases: products that belong to more than one family, documents with several versions, or content that spans different specialties.
Paths
We test the structure using the different ways people search.
What happens if someone knows the procedure but not the product name. If they arrive from Google. If they have a code. If they need a specific document.
Validation
The teams that know each part review the model before it moves into interface design and development.
The architecture is documented so later decisions don't depend on remembering why something was organized a certain way.
Work · SAI
Nearly 270 products. Five ways to browse them.
SAI's new platform needed to organize a broad portfolio along with documentation, medical education, and other related content.
≈268products
5navigation dimensions
86classification terms
106possible fields on a product page
FAQ
We already have a content management system: isn't that enough?
The CMS stores whatever gets entered into it. Without a content model decided beforehand, it reproduces the mess with better typography.
Why filter by procedure as well as by product family?
Because many healthcare professionals know the procedure and anatomical region before they know the trade name. That creates another path to the same product page.
Can a product be found by code or registration number?
Yes, if they're entered as fields on the product page. Whether the registration is shown is defined by the company's regulatory team.
Who defines the structure of the product page: the agency or the company?
Both. We propose the model and the fields; Product, Quality, and Medical Affairs validate what goes in. The decision is put in writing.
How do own products and distributed brands coexist?
With the brand as one more dimension: people get there by procedure or by region, and the product page says which brand it belongs to.