Ordinem TCG

Ordinem needed to work in two places at once: as a tabletop game and as a digital one, sharing a single brand and a single set of mechanics. The brand and the design system were already in place. My role was to build on that foundation: extend the system where new patterns were needed, fix the in-game UI that players found hardest to follow, get the whole experience working on mobile, and design and build the public site. The through-line across all of it was the same: the game’s mechanics are genuinely complex, and every surface had to make them readable without flattening them.

The thread cost system is a core mechanic. It determines which magical resources, threads, are consumed when a card is played, and the original treatment of it generated more player complaints than anything else in the UI. Thread costs sat far from the cards they applied to, players could not see which specific threads a play would consume, and the relationship between a card and the resources it burned was left for the player to infer.

The redesign moved the thread pool close to the cards, showed only top-level counts at rest so the board stayed scannable, and put the detail behind hover: which threads a card would consume, and in what order. An expanded hover view gave players the full picture of everything available when they wanted it.

The reason it landed was less about the layout than the timing. The information was always there; what changed was the moment it appeared. This was the piece the game design team had been stuck on.

The board was designed for desktop, but a lot of players would meet the game on a phone first. Porting it was not a matter of shrinking the layout. A hover interaction like the thread pool has no equivalent on touch, the board had to reflow into something playable in a narrow portrait frame, and hit targets and reading order all had to be reconsidered for a thumb rather than a cursor.

I designed the mobile experience alongside the desktop one, deciding where the two could share patterns and where mobile needed its own. The same principle carried over: surface the right information at the right moment, adapted to how the interaction actually happens on each device.

I designed and built the site in Framer, structured around the four things players actually arrive for: Cards, Rulebook, Lore, and Play. Newcomers get clear entry points into the ruleset, advanced players get direct paths to card data without wading through marketing.

The card browser is the centrepiece, supporting active filtering, search, and archetype views. 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 sit dynamic graphic widgets, archetype tiles, thread costs, and weave resource visualisations, that tie the mechanics back to the brand’s metaphysics.

The first version of the card browser leaned on an off-the-shelf filter module, and it choked at scale. Rewriting the filter layer as a custom code component, while leaving the rest of the browser in Framer Workshop, dropped time-to-interactive noticeably and turned the browser into the thing the community came back to. I also tuned load priorities, motion, and component modularity to hold performance through peak browsing.

The judgement call was which part of the stack to isolate. “No-code” and “custom code” are not a binary, and the performance win came from replacing one layer rather than rebuilding the site around the problem. Owning the work from concept through to code is what made that call available to me at all.

The site is live and legible on arrival: learn fast, browse deep, play now. The card browser became a core engagement surface, and the CMS structure let the team keep publishing lore and rules without losing polish or waiting on design.

On the game side, the thread pool redesign and the board layout improvements went into development with mobile versions in production. The work was well received internally, particularly by the game designers who had struggled to identify a clear solution to the thread pool.

Ordinem taught me the importance of knowing when to show information, not just what to show. Second-by-second gameplay decisions need different information at different moments, and understanding game flow is what tells you which. You can have all the UI in the world, but presented at the wrong point in the decision, it becomes noise rather than clarity.

The same instinct turned out to apply to the build. Knowing which single layer to rewrite, and leaving the rest alone, was the difference between a browser that choked and one players kept returning to.