So, last week @beep and I had a fascinating conversation with @petermcreaper and @mkeftz about the work they’re doing on @interplayapp; among other things we circled around the ideas Peter mentioned in his post about design artifacts… it’s worth a read. https://pete.studio/notes/design-files-are-disposable-artefacts.html
@petermcreaper’s thesis in that post is pretty straightforward: the intermediary design files accumulated in the process of developing a site — particularly one that’s heavily component and pattern based — are disposable, temporary artifacts and not the “source of truth.”
It’s a thing @gregddunlap and I talked about over the years WRT content models — it’s fascinating to (again!) see similarities popping up. With content, you accumulate an endless pile of spreadsheets and similar docs to iron out types, properties, relationships, and so on.
The workflow generally goes something like: Creator ideation -> Stakeholder review -> Creator refinement -> Implementation scoping -> Dev build. From that perspective, once implemented in live code the intermediary artifacts — spreadsheets, Figma files, etc — are dead weight.
In fact, some say those artifacts can be worse than dead weight if not carefully kept up to date when new features and changes are made to the system. The artifacts become a snapshot in time, before the ‘real’ thing was built, but are often treated as the current truth.
To that extent, a lot of @interplayapp’s magic is focused on making it possible to capture rich metadata in the design components themselves — so that notes about intent and usage live in code, then make their way BACK to tools like Figma when new designs need to leverage them.
@justafish did something cool like that years back on the @MSNBC project; Drupal tooling to re-export a content type definition spreadsheet every time the Drupal config changed, so that content strategists and editors referring to the spreadsheets would never fall out of sync.
The biggest challenge, I think, is the underlying assumption that “code running on a particular platform” is (or should be) the source of truth for UX, or content, or… well, anything other than “the current state of the executable.”
Code, by definition, is the absolute best source of information on what has been built and what it does… But it’s notoriously bad at describing its own goals — what was the intention of the feature? What situations is it expected to handle? And so on.
Often, the canonical content model and the one that’s materialized in a particular CMS’s configuration diverge from each other — fussy tweaks have to be made for performance, or things that are easy to express in a “pure” content model diagram require workarounds in a given CMS.
I’m nowhere near as comfortable commenting on the nuances of workflow for design system evolution (that’s very much @beep’s bag), but it feels like teams will need to learn to express and document “Intent, With A Capital I”… not JUST the details of the current state.
The huge advantage of “code as the source of truth” is that it makes a whole ecosystem of supporting tools easier to build — treating the goofy artifacts as disposable ephemera you regenerate if you need a “fresh” one means never wondering if MODEL-LATEST-final.XSL really is…
But it also means trusting that everyone is synchronizing around that metadata in the code, keeping it updated, noting the places where real-world usage is growing past original intent, and fuzzy stuff like that.
Without that careful attention, the code risks falling out of sync with reality just as the PSDs or the Figma files or the Wireframes or Spreadsheets risked falling out of sync with the code. A design system, like “the content,” evolves over time even if we pretend it’s static.