Carde.io
·
Lead Product Designer
·
Oct 2024 - jul 2025
led design across four interconnected products for a trading card game platform — building a role-based architecture and unified design system that served players, game stores, and enterprise publishers simultaneously.
↓
55%
Fewer errors on Unified Admin Panel
2
Enterprise publisher partnerships
Platform still active
Serving Universus Gaming Network
01
Business context
The trading card game market had grown dramatically, but its software infrastructure hadn't kept pace. Local game stores were running events on spreadsheets. Game publishers had no standardized way to manage their retail partner networks or card design workflows. Players had no centralized hub to find events, track scores, or connect with official communities.
Carde.io set out to build the connective tissue for the entire TCG ecosystem — a suite of interconnected products serving every stakeholder from card creation to tournament play.
02
Problem Definition
Surface Problem
Each product had its own usability gaps and incomplete feature set.
Real Problem
Four products. 6+ user types. No shared language, no scalable architecture, and no coherent system.
The previous design approach had treated each product in isolation. What the organization needed was a designer who could think across all four simultaneously: establishing the system logic, the permission model, and the design language that would make the ecosystem coherent at scale.
Without that foundation, every new feature would compound complexity. With it, the platform could serve an enterprise publisher, a one-person game store, and a competitive player through a single coherent product family.
Why did this matter?
The TCG software market set a low bar. Competitors couldn't handle mid-round scoring changes, didn't support draft formats, had no seating management, and required multiple tabs to show basic event information. Users rated Carde's early product higher than competitors despite it being less mature — which meant execution quality and systems thinking were the differentiator, not just feature parity.
03
Goals & Success Metrics
Design Goals
Establish scalable design system across branded IP skins
Architect a role-based permission model serving 6+ distinct user types
Reduce event management complexity for LGS owners and judges
Design a publisher portal that formalized the store-to-publisher relationship
Create a publisher-side card design workflow capable of supporting a professional publishing organization
Business Goals
Secure enterprise publisher partnerships
Demonstrate platform viability to investors
Expand from one publisher partner to multiple
Build a platform sophisticated enough to earn a second development contract
Become the number one TCG events platform, tapping into a $21B market
Success Metrics
Publisher partnerships signed
Investment secured
Beta store adoption
Live platform deployment
Platform credible enough to demo at an industry conference and in front of enterprise publisher leadership
04
Research & insights
Rather than designing from internal assumptions, I structured research around three distinct methods.
01
Competitive analysis revealed a low bar across the market. On the player side, event information was fragmented across multiple tabs. On the store management side, platforms couldn't handle mid-round scoring changes, couldn't support draft formats, and had no seating management. Despite these gaps, users already rated Carde's early product above competitors — confirming that thoughtful execution would differentiate, not just feature additions.
02
Ongoing support commentary and site metrics provided continuous signal on friction points across the Play Hub and Unified Admin Panel, feeding directly into prioritization throughout the engagement.
03
The most formative research happened at GAMA 2024, an industry event attended by game-store owners and publishers. We brought a working demo and ran live interviews with store owners in their professional context — capturing gut reactions and unfiltered experience with the product. This wasn’t recruited research behind a one-way mirror; it was field research at the source, with the actual users who would run events on this platform.
I also had direct conversations with representatives from three publisher brands who were evaluating or already engaged with the platform. Gathering feedback from both store operators and publisher partners at the same event, in the same context, shaped product decisions on both sides of the UAP’s permission model.
05
Strategic Decisions
Decision 01
In direct collaboration with the VP of Engineering, I established a Tailwind-mapped design system built on ShadCN that separated brand tokens from component architecture. Color, typography, and brand-specific visual decisions mapped onto a shared component library — meaning a new IP skin required token remapping, not a rebuild from scratch.
Why this choice
Each publisher partner would need their own branded experience — Ravensburger's Play Hub, Universus Gaming Network, and future partners each carry distinct visual identities. Building a bespoke design system per IP would multiply complexity with every new partnership.
Rationale
This was as much a code infrastructure decision as a design decision. We evaluated the complexity cost of bespoke systems together and agreed that optimizing for developer implementation efficiency was the right constraint. A designer advocating for scalability in the abstract is easy to dismiss. A designer who can explain what a bespoke system costs in engineering hours per new partner is a different conversation.
System impact
One component library now serves multiple branded publisher hubs with entirely distinct visual identities — Universus Gaming Network (play.uvsgames.com), the Ravensburger Play Hub (tcg.ravensburgerplay.com), the Riftbound Gaming Network (locator.riftbound.uvsgames.com), and CookieRun: Braverse (play.cookieruntcg.com) are all running on the same underlying system in 2026, more than a year after Carde.io closed. Each carries its own brand; none required a rebuild.
Decision 02
Access control was a foundational requirement across the platform, but the organizations using each product had fundamentally different structures. Ludwig served enterprise production teams managing card set pipelines across departments. The UAP served game stores managing a mix of internal employees and external event staff. I designed distinct permission architectures for each, shaped by how each organization actually assigns responsibility.
Why this choice
A single permission model applied across both products would have required each to carry complexity it didn't need. Enterprise publishers needed a group-based matrix where role inheritance scaled across departments like Art Direction, Game Design, and Narrative. Game stores needed a two-track system that separated internal employees from external game masters at the data model level. The right architecture in each case was the one that matched how the organization thinks about access, not the one that was easiest to build once.
Rationale
Ludwig's Viewer, Member, and Owner tiers map to how production studios delegate responsibility across a project. Permissions flow from group to user, so onboarding a new team member to Art Direction automatically scopes what they can see and edit without per-user configuration. The UAP model solves a different problem. Store employees and game masters aren't the same entity with different settings. They have different data structures, different operational relationships to the store, and different access scopes. Modeling them as separate tracks meant neither carried the complexity of the other.
System impact
Both architectures were designed to scale without administrative overhead. A publisher adding a new contractor to a production team inherits the right permissions from their group assignment. A store onboarding a tournament organizer for a single event gets event-scoped access with no operational store permissions attached. The underlying models are different, but the outcome is the same: the right access, to the right people, without manual configuration at scale.
Decision 03
I designed a two-sided permissioned workflow within the Unified Admin Panel - stores apply for official publisher relationships, publishers review and approve on their end, and approval gates what each store can do on the platform.
Why this choice
The relationship between game stores and publishers was managed informally. Stores had no structured way to apply for official status. Publishers had no scalable way to vet them. The gap wasn't a UI problem — it was a missing business process.
Rationale
Solving this required understanding the relationship model before touching the interface — what triggers an application, what a publisher needs to evaluate one, and what approval should unlock. The design translated an informal business relationship into a repeatable, scalable workflow. Ravensburger's immediate response to this feature in the initial demo led directly to a second development contract.
System impact
A previously informal partnership process became a structured, permissioned workflow extensible to any publisher on the platform — without rebuilding the underlying architecture.
Decision 04
Tournament infrastructure designed for formats competitors couldn't support
Draft events are among the most logistically complex formats in organized play. Tournament organizers were running them on paper or spreadsheets because no TCG software handled the edge cases. I designed a tournament management system that could accommodate the complexity of each common tournament format, surfacing the right controls to the right role at the right moment. As an additional feature, event architecture was editable even during a live event, something that had never been solved to that point.
Why this choice
Competitors failed organizers not on features, but on flexibility. A round timer is easy. What's hard is letting a tournament organizer go back to a previous round, adjust scores, restart it, or edit players without voiding the entire event. No major TCG platform offered this. Organizers were abandoning software mid-event and finishing on paper.
Rationale
GAMA research confirmed organizers were leaving competitors over rigidity, not missing features. The software did too much at the wrong time and locked organizers into decisions they couldn't reverse. The design solution was containment: surface only what each role needs at each event stage, while keeping full complexity accessible when required.
System impact
Carde's event management rated higher than competitors among users who had tested both, despite being an earlier-stage product. The sealed draft support specifically represented a capability gap no competitor had closed.
Decision 05
COPPA-informed parental permissions as a regulatory layer on the role model
I designed a parental permission layer into the existing role-based model rather than as a separate compliance bolt-on. Age-gated access was treated as a user type consideration from the start — consistent with the underlying permission architecture rather than appended to it after the fact.
Why this choice
The Play Hub served a general audience that included minors. TCG communities skew young. Operating without a parental permission model created regulatory exposure and trust risk with publishers who had their own age-gating requirements.
Rationale
Retrofitting compliance into a live product is materially more expensive than designing for it upfront. Treating it as a systems problem meant the solution was coherent with the rest of the permission model. It also signaled maturity to enterprise publisher partners who needed confidence that the platform could handle their audience responsibly.
System impact
Reduced future regulatory risk and established a precedent for thinking about user type governance that extended beyond workflow access into legal and brand protection territory.
Decision 06
Publisher workflow management system designed from the ground up
Why this choice
Publisher partners needed more than a play network. Running a trading card game at scale requires managing card design workflows, artist relationships, print-ready asset pipelines, user permissions for different internal roles, and group-level access controls. None of this existed in any form when I joined. The question wasn't how to improve a system — it was what the system should be.
Rationale
Publisher partners were evaluating Carde.io not just on the player-facing platform but on whether the back-end tools could support a professional publishing operation. Ludwig was the proof that the platform could handle the full lifecycle — from card conception to organized play. The strength of the Ludwig demo directly contributed to Ravensburger's decision to sign a second contract. The sophistication of the permissions architecture — group roles, user states, approval workflows — reflects the same systems thinking applied across the rest of the platform, applied to an entirely different problem domain.
System impact
Ludwig represented the most ambitious scope of the engagement. The user and group management system shipped in June 2025, one month before my departure. The designs demonstrated that a small design team could produce enterprise-grade workflow software from scratch — but also that the feature expansion ambition eventually outpaced what the engineering team could deliver, which contributed to the company's closure.
06
Cross-Functional Collaboration
Executive team
I worked directly with the CEO, CTO, VP Product, and VP Engineering throughout the engagement — not in a presentation capacity, but as a collaborator shaping how the product got built. Design decisions at this scope had downstream implications for engineering architecture, partnership positioning, and investor narrative. Operating in that room required understanding those implications, not just advocating for experience quality in isolation.
VP Engineering — design system co-ownership
The Tailwind DS decision was made jointly with the VP of Engineering after evaluating scalability, team capacity, and implementation tradeoffs. We aligned on a shared system architecture that avoided per-IP complexity and prioritized long-term maintainability and engineering efficiency. This reflects design and engineering operating as a single problem-solving unit, resulting in a system still running in production today.
Ravensburger
The success of the initial platform demos expanded the partnership from one contract to two. I helped navigate enterprise stakeholder alignment, evolving requirements, and cross-functional execution while maintaining momentum across a distributed team.
Universus
As Carde.io's first publisher partnership, Universus became a long-term proof point for the platform. The product remains live today, continuing to support an active player community more than a year after Carde.io closed.
CookieRun: Braverse
Partnered directly with publisher stakeholders to design organized play experiences and custom commerce features within the platform ecosystem. The implementation remains live today as part of the broader Carde.io infrastructure.
Riftbound / Riot Games
Led early planning and implementation strategy for a large-scale organized play network, coordinating across legal, operations, and product stakeholders to establish a foundation for launch after my departure.
07
Outcomes
Quantitative
Unified Admin Panel reduced errors by 55% and saved store operators 43% in task time
Qualitative
Ravensburger returned with a second contract after UAP and Ludwig demos — unsolicited validation of design quality and strategic fit
Store owners at GAMA responded immediately to the publisher application portal, identifying it as a feature they hadn't expected and couldn't find elsewhere
Four branded publisher platforms running on the same architecture more than a year after the company closed — evidence the design system and permission model were built to last, not just to demo
Organizational
Unified four products under a single design language for the first time in the company's history
Introduced a hiring process for design roles, extending design leadership beyond individual contribution
08
Key Learnings
The most consequential decisions on this project weren't interface decisions — they were architecture decisions. What user types exist? What can each see? What workflow does each need? How does the data model support all of them simultaneously? Getting those questions right made every downstream design decision faster, cleaner, and more coherent. Getting them wrong would have compounded into a product that was impossible to maintain.
The Tailwind DS decision wasn't made in isolation — it was made in partnership with engineering leadership, with implementation cost and developer efficiency as explicit criteria alongside scalability and brand flexibility. Designing for scale means designing for the people who have to build it, not just the people who have to use it. That requires understanding the cost of your decisions in engineering terms, not just design terms.
Carde.io closed in late 2025 because the ambition to expand Ludwig's feature set outpaced the team's engineering capacity and budget. I left in July 2025, a few months before the closure, in part because the organizational pace had become unsustainable. I didn't own the decisions that led to either outcome — but I learned from watching the conditions develop. At Principal scope, design leadership includes flagging when product ambition is disconnecting from delivery reality and when team health is eroding under that pressure, even when those are uncomfortable cross-functional conversations. The design architecture held — the Universus platform is still live. What I'd do differently is advocate earlier and more directly for sustainable pace and scope discipline as product health issues, not resourcing problems to solve in the next sprint.
GAMA gave us access to LGS owners and publisher representatives in the same professional context — people with real operational stakes who could evaluate a demo against their actual needs. That quality of signal is hard to replicate in recruited research. The conversations at GAMA directly shaped product decisions and extended into active implementation work with CookieRun and pre-launch coordination with Riftbound. Wherever your users and partners gather professionally, be there with something to show them.
09
Attribution
Executive team
I worked directly with the CEO, CTO, VP Product, and VP Engineering as a collaborator shaping the product—not just presenting designs. This required understanding how design decisions impacted engineering, partnerships, and investor strategy, not just user experience.
Engineering
The Tailwind DS decision was made jointly with the VP of Engineering after evaluating scalability tradeoffs. We aligned on an approach that balanced team size, budget, and implementation efficiency, resulting in a system that remains in production today.