Today’s content architecture + design systems tidbit is a useful technique I picked up from the Python programming language: Duck Typing. In other words, “if it quacks like a duck, it’s a duck.”
When a complex content model is being paired up with a pattern-oriented design system, there are usually gaps and mismatches between the way content is broken into smaller useful pieces, and the way presentational and behavioral UX elements are broken down.
Sometimes — depending on which team locked in their foundational concepts first — one of the two systems ends up twisting and bending to fit the nature of the other. Patterns devolve into “templates for content types” or content types become “the stuff that populates patterns.”
A common example: the proliferation of “card” content types — standalone content fragments whose structure is built around various “card” display patterns the design system defines. Most of them just duplicate the title, tagline and image of the “full” content they link to.
A subtler form of the same problem: patterns that come with meticulous lists of what things they can be applied to. “Image Cards can be used to display articles, interviews, how-tos, products, product categories, bios, and…” etc etc.
In complex content/publishing scenarios that becomes unsustainable, or at least a huge pain to maintain, plan for, and expand. Adding a new content type to the mix requires manually picking through the pattern library and figuring out what might apply to it…
An alternative is to treat the relationships between those UX/design patterns and the content they materialize as a kind of contract: “Anything that can provide a title, a summary, and a destination link can be a Card; things that have a media preview can be Media cards as well”
In Python and other computer languages that support the “duck typing” concept, it’s a way of making small pieces more flexible. The system doesn’t have to contain meticulously defined lists of what parts “fit” together, just rules about what qualities or attributes are necessary.
In the world of content architecture, it’s an approach that can be useful when you have lots of content that can serve multiple roles in different situations.
“Should this thing be a Promo or an Article or a Resource, or…?” can lead to awkward, arbitrary distinctions. Framing it in terms of what they are expected to provide — the “content contract” they promise to fulfill — makes multi-role content easier to conceptualize.
Not many CMSs support that way of approaching things natively — so there are gaps to fill and rough edges to file off on the implementation side. But for certain types of content models it can dramatically simplify the list of types, and the way they’re surfaced in a design.