Content Modeling 101 for eCommerce

Information architects strive for the bigger picture of content modeling, organizing content, labeling content, and findability through search and navigation. The hunt for the perfect content model is the holy grail for information architects.

Topics that information architects will consider:

• Discovery: get a complete overview of the content used in the organization.
• Similarity: are all products structured the same, or do they have different properties and relationships?
• Repeating information: managing the same content in several places is a no-no.
• Future uses: are there use cases we should already prepare for in the (near) future?

Editorial users are creating and curating your content and product information. The process of enriching your product information and marketing content should be as friction-free as possible. You want inspired editorial users so they can focus on delivering awesome content and not complex editorial flows.

Things to consider for editorial users:

• Editorial experience: they create and curate content all day. The editorial experience is vital. It needs to be flawless.
• Content fragmentation in perspective can be great for re-use and re-purpose of content and content parts. However, too much of it can make it more challenging to work with from an editorial point of view.
• Channel-specific content like metadata for the web or 3rd party channel syndication should be clear and easy to understand.

Developers have different perspectives and are using and combining the content to build the customer experience - or the webshop. But also working with importing and synchronizing data to and from external sources. 

Developers consider topics like:

• Specification and definitions: a good overview of the content model makes it easier for developers to work with the content.
• Simple access to content: to build product pages, landing pages, or content pages in a modern frontend, developers want easy access to all the available content.
• Re-use of content: integration is all about synchronizing content across different systems. Being able to have easy access to specific content like you have with a modern GraphQL API is essential.

Communication between teams is also key. Domain-driven design (DDD) is more and more used and has one goal: streamlining the communication and collaboration between tech and non-tech teams. In this approach names used in the code matches the business logic described by the Content Model.

Freedom for designers to build a great customer experience in any channel. Designers are executing the vision of the information architects.

Designers focus on:

• Navigation: can I enrich the navigation with some images? Do I have the possibility to build multi-dimensional navigation?
• Search: how can I refine the search to narrow down the results for the customers?
• Content chunks and components: are specific parts of the product information available as neat content chunks or as a single blob of rich text?

Ok, customers should always come first. But here we are. When designing your content model, you need to have your end customer or user in mind. After all, they are the ones who your information architects, editorial users, developers, and designers are working together to serve.

Some considerations from the customer perspective are:

• Findability with navigation and search: customers want to find what they are looking for fast.
• Rich product information: make sure all necessary information is easily accessible for the customer to decide.
• Comparison: when you have multiple similar products, the customer needs to be able to make simple comparisons.
• Related and compatible products and content: what cables go with this guitar pedal? Which accessories are compatible with this coffee maker?

When doing content modeling for a specific channel or to power particular types of web pages, you model more directly to the elements on the screen. Instead of thinking about re-use, you design for display and maybe also some flexibility towards how the display should be adjusted.

Content modeling for a specific channel has the benefits of giving more control over the presentation of the content for that channel. Perhaps at the cost of content re-use and the principle of separating content and presentation.

Consider the simplified content model below for a car. We may have the following:

• The core product information like product name, SKU, stock, price, etc.
• Images and videos.
• Maker/brand logo.
• Selection with different display options for the logo (left, center, right).
• Rich text component specifying the specs: curb weight, wheelbase, and displacement.

You can easily make a pretty product page for this car with the information that most buyers are looking for. But let us compare this with the semantic content modeling approach.

When doing semantic content modeling, you are trying to describe the product information in as many details as possible and give as much context or information as possible. There is no information on how this will be presented on any channel.

Take a look at the screenshot below in comparison:

• Core product information is defined the same.
• Maker/brand is defined as a relationship to a Make item and this enables the reuse of make information between multiple cars. Also, you can easily find all cars of the same maker/brand.
• No information on how to display the maker/brand for any channel.
• Specs are defined as numeric values with a defined unit. Here we can easily get the values to present it on a given channel, but in addition, we can easily use this to compare, for example, curb weight between multiple cars i.e. search for cars that have a given curb weight or less.

With the semantic content modeling approach, you are freer to use the product information the way you need it now - and in the future. It is more structured and opens up more possibilities for future reuse.

The first part of the content modeling process is to discover all the content you use in your organization online, on all channels. Products for your webshop, marketing content for your website, content used in your App, and syndication content are just a few examples.

Getting an overview of all current and potential future types of content you are creating to market and sell your products online is a crucial first step.

Once you have an overview of all the content you have, it is time to look for similarities. Do you have product pages for your webshop, perhaps also for your website? What about in your Apps? Do you also syndicate your product information to 3rd party sites for listing there?

Identify if the product information you use across your channels has the same structure. Do they all have Titles, briefs, variants, pictures, properties descriptions, etc.? This might uncover that you have multiple different types of products that need to be described differently.

For example, the wheel stets page is structured differently than car accessories but you might sell both on your webshop.

Step #3: Identity Repeating Information

After identifying the different types of content, you start looking for repeating information. This could be the author of a blog post, the manufacturer of a car part, or a description of a wheel set.

The repeating information is what you should then split out in your content model to define what we describe as shapes.

Once you have the different shapes of products or structured documents, you can look at relationships. A relationship defines a link between two or more items. It could be ingredients used in a recipe or recipes created by a chef.

Relationships can be used together with catalog structure, topic maps, and grids to organize your information for maximum reuse.