Contentful Content Remodeling
/ CLIENTRicoh USA
/ PROJECT TYPEContent Modeling
/ DURATION2 months
/ DELIVERABLESMiro Wireframes
Airtable Model
/ BACKGROUNDFFW was engaged to do a “life and shift” of a legacy Sitecore installation into Contentful. The initial project team was under a great deal of pressure to deliver within a very tight timeline. I was brought in after the project launch to evaluate opportunities for improvement and optimization.
/ APPROACHWe began the project with stakeholder interviews and walkthroughs of their authoring workflow. Next, I reviewed the design system and mapped component into their Contentful content types. Unsurprisingly, the Contentful content types did not have parity with the design system so I met with developers to understand their methodology in creating the initial model.
I then created a project purpose statement to keep us oriented and focused.
We want to audit the existing content model so that we can provide meaningful updates and improvements to the content workflow experience. We will know we have succeeded when we reduce system redundancies, gain efficiencies in the editorial experiences, and provide in-app context and guidance to authors.
I began to track findings in Miro and the board grew into a sprawling network with documentation including:
Design System Intent
Current State Content Model
Contentful Reference (a sample piece of content)
Visual Reference (front end presentation)
Observations, Recommendations, and Rational
New Modeling
Wireframe (when relevant)
After walking the client through he board at a high level I formalized the model in Airtable, reviewed with client and development teams, then handed off the model for implementation.
/ REVIEW PERIOD
To ensure seamless handoff, both in person and asynchronous review sessions were held. The following documentation was shared with those who could not attend the review sessions.
Considerations
Content Model Consolidation: Consolidation of redundant content types and fields was a large focus for this review. Visual layout and design choices have been moved from child elements into parent containers. This consolidation will also set us up for content reuse and dynamic cross promotion.
Governance – Content Type Naming Prefix: In an effort to better distinguish between content types in a large list, emojis have been added to the prefix. These emojis are meant to convey meaning and can be updated to suit what is easily identifiable to your authors.
📄 = “Pages” are items that when published have a system generated page/screen that is visible to the end user. They all have urls, SEO, and taxonomy elements.
📁 = “Assets” are items that when published can be viewed alongside other content but do not have a page. Instead, they show content inline, in a modal, or as a downloadable. An example of an asset is 📁 VPAT and 📁EPEAT. These elements have has a repeatable structure but do not have a unique page generated for each item. It it important to note that they don’t need a physical media asset but are a content asset to the organization.
#️⃣ = “Vocabularies” store unique values to your taxonomy. Additional details about this content type can be found below.
🔗 = “Links” store CTA key value pairs and mega menu links.
🧩 = “Components” are containers used to showcase content across the site. They often support smaller referenced components (like cards or dynamic content referenced) and can have design choices enabled (like background color or layout).
♟️ = “Pieces” represent the smallest structured bit of content in the model. The are highly structured and must be unopinionated about visual layout or design – they can look different depending on what component they nest into. An example is ♟️ Content Card which can nest into either a 🧩 50/50, 🧩 CTA Card Stack, or 🧩 ICP Collection and take on very different visual style but the data of the card doesn’t change.
One offs:
⚙️ = “Settings” stores development configurations.
🔍 = “Navigation” contains items related to site navigation.
🔌 = “Module” plugs-in an external source for reference on a page.
📍 = “Location” Contains data for a specific physical location.
Metadata / Taxonomy: The concept of flexible taxonomy has been introduced into the model. Items noted with a #️⃣ emoji represent vocabularies found across content. Creating content types (and sunsetting existing metadata content type) will enable you to more readily update/add terms and reference content dynamically based on terms.
Cross-promotion: The ability to reference 📄 content within 🧩 content type has been recommend in a global way. This in conjunction with adding #️⃣ content types as references into certain areas will enable authors to directly reference content based on individual items or across a vocabulary term. Example: adding “Healthcare” from the #️⃣ Industry vocabulary into a 🧩 Featured Content Collection will dynamically pull together the most recent content associated with this term (this includes case studies, videos, articles, pages etc.).
Assets to Review
Source of Truth: The Content Model Spreadsheet acts as the source of truth for all details related to the content model recommendations.
Additional Context: Some items may have visual representations to aid in explanation. Available representations are noted on the spreadsheet in column M.
Review Guidance
Reviewing a content model involves evaluating its structure, organization, and effectiveness in achieving its intended goals. Here are some steps you can follow to review a content model:
50,000 ft view – Familiarize yourself with the purpose: Understand the purpose of the content model, its intended use, and the goals it aims to achieve. This will help you evaluate whether it aligns with the specific needs of the project.
5,000 ft view – Evaluate the content types: At a high level examine the different content types included in the model and assess whether they adequately represent the various types of content that need to be managed. Consider if any content types are missing or redundant.
500 ft view – Assess the naming conventions: Review the naming conventions of the content types and ensure they are clear, descriptive, and consistent. Evaluate if the prefixes (emojis) used to distinguish content types are helpful for authors to quickly identify and understand the purpose of each type.
50 ft view – Review templates: Evaluate the 📄 “Page” recommendations and assess if they meet the needs of the project and if there are any opportunities for improvement or customization.
5 ft view – Analyze the structure and hierarchy: Evaluate the organization and hierarchy of the content types. Determine if the structure allows for efficient content management, easy navigation, and seamless content reuse. Consider if there are any opportunities for further consolidation or simplification.
.5 ft view – Examine metadata and taxonomy: Evaluate how metadata and taxonomy are incorporated into the content model. Assess if the model allows for flexible and dynamic categorization of content. Consider if there are any improvements to be made in terms of the available vocabularies or the ability to add or update terms.
For the future – Consider content relationships: Assess how the content model enables the referencing of one content type within another. Determine if there are opportunities for cross-promotion and content reuse. Consider if the model allows for easy linking between related content.
/ ARTIFACTS + DELIVERABLES
Model Mapping
Model Field Comparison
/ OUTCOMESReduced redundancy and improved optimization of Contentful space by consolidating 45 content types and updating the remaining content types with field validation and help text.
