Overview
I structured the site around the four things players actually come to it for — Cards, Rulebook, Lore, and Play — cutting the distance between learning and acting. Newcomers get clear entry points into the ruleset; advanced players get direct paths to the card data they want without wading through marketing.
The card browser is the centrepiece: built in Framer with a mix of Workshop components and custom code so it could support active filtering, search, and archetype views without losing performance. Lore and the rulebook live in Framer CMS with content models for chapters, entries, and updates so the team can publish iteratively and version sections as rules shift — with a path to localisation built in. Around that I implemented dynamic graphic widgets (archetype tiles, thread costs, weave resource visualisations) that tie the mechanics to the brand’s metaphysics, and tuned load priorities, motion, and component modularity to keep the site snappy through peak browsing.
Outcome
A cohesive, high-clarity product surface that makes Ordinem immediately legible: learn fast, browse deep, play now. The card browser became a core engagement driver, while the CMS stack unlocked scalable lore and rules publishing without sacrificing polish.
What I learned
The clearest example came from the card browser itself: the first version leaned on an off-the-shelf filter module and choked at scale. Rewriting the filter layer as a custom code component — while keeping the rest of the browser in Framer Workshop — dropped time-to-interactive noticeably and made the browser the thing the community came back to. The lesson that stuck is that “no-code” and “custom code” aren’t a binary — the performance wins come from knowing exactly which part of the stack to isolate and when. End-to-end ownership, concept through code, is what made that judgment call possible.