← Henry Davis

Wizards EventLink: Concept to Beta

2020

TL;DR

Magic: the Gathering runs on in-person competition. The software powering it, Wizards Event Reporter (WER), was 15 years old, Windows-only, and so difficult to use that volunteer organisations ran training classes just to operate it. I was brought in as a Product Designer to help replace it from scratch, and became the person driving the project through every stage from discovery to launch.

Working within a hard 12-month delivery deadline, a small cross-functional team, and significant technical constraints, I planned and led a full discovery programme, defined the product scope, and drove design from initial research through closed beta to global launch. The result, Wizards EventLink, successfully replaced WER and is still in active use today, maintained by dedicated teams at Wizards of the Coast.

During the project I also identified and pitched an adjacent opportunity: a companion mobile experience for players to register, receive pairings, and report results digitally. Leadership approved the expansion in the same meeting. (See the Magic Companion case study.)

Team and Role

Team

My Role

I was the designer responsible for this project. The team had a senior designer at the outset who contributed early journey mapping work before moving off the project; from that point forward, the design direction, research agenda, prototyping, stakeholder communication, and day-to-day design decisions were mine. I worked directly alongside the product owner and lead engineer throughout, advocating for users in scope and timeline conversations with leadership and driving every sprint from discovery through closed beta. The other designers on the team collaborated closely on research execution. I was not a people manager, but the product design was my responsibility to own and deliver.

Background

Magic: the Gathering, one of the world’s largest trading card games, grew on the back of a strong in-person tournament system. Every week, players come to Local Game Stores (LGS) to compete, and those events are the financial backbone of thousands of small businesses in the Magic ecosystem.

Wizards of the Coast commissioned Wizards Event Reporter (WER) in 2004 to support this system. Tournament Organizers used it to manage events; in return, they were enrolled in a business partnership programme where rewards tracked to player attendance. It became the infrastructure underpinning Magic’s retail health.

Over the next 15 years, WER was allowed to languish. It remained Windows-only. Its interface was so counterintuitive that the Magic Judge Programme, a volunteer organisation of semi-professional referees, ran dedicated training sessions just to teach organisers how to use it. Bugs accumulated. Workarounds multiplied.

I encountered WER first-hand as a Magic Judge, flying to professional tournaments on weekends while working through design school. I knew exactly how broken it was, and when a contact mentioned Wizards was hiring a team to replace it, I sent my portfolio that night. Two weeks later I was a Product Designer on the project, and the person responsible for its design direction.

Discovery and Research

Before a single wireframe was drawn, I needed to understand three things: what the existing system actually did, how real people used it in practice, and what the business needed from any replacement. I designed a research programme to answer all three and secured approval before the project formally kicked off.

Coming in with a research plan already scoped meant we didn’t lose weeks at the start of a tight timeline negotiating what we needed to learn. It also established early that design would be driving the process, not reacting to it.

Understanding the Existing System

I began with a deep audit of WER, reviewing its functionality, its sparse documentation, and its failure modes. I supplemented this with expert interviews, including members of the Magic Judge Programme who had spent years building workarounds for WER’s usability failures. This gave us a clear baseline: what core functionality had to be preserved, and where the biggest opportunities for improvement were.

Ethnographic Research in Local Game Stores

No documentation review tells you what actually happens during a tournament. I planned and led five in-person shadowing sessions across local game stores of deliberately varying sizes and maturities, from small neighbourhood stores to venues handling multi-format events simultaneously.

I brought the full team through this process. Engineers and our product owner each joined at least one session. Getting non-designers into the field early paid dividends later: when constraints got tight, engineers who had watched a retailer struggle with WER made different trade-off decisions than engineers who hadn’t.

Fieldwork was limited to Pacific Northwest stores due to timeline and budget, a known constraint we accounted for by weighting these findings carefully against the global interview data collected separately.

Global Retailer Interviews

To counter the geographic bias of in-person research, I worked with our global marketing team to set up 12 moderated interviews with event organisers spanning every major region. These sessions surfaced how WER’s problems, and people’s workarounds, varied by market.

I also ran a focused session with Wizards’ Retailer Advisory Panel: a standing group of experienced, NDA-bound retailers selected for their ability to give specific, high-signal feedback. This gave us a strong pressure test for the assumptions we were forming.

Synthesis

With fieldwork complete, I led synthesis across the design team, building the journey maps that became our primary artefact for cross-functional alignment. I used these to run two structured workshops with engineering leads and product leadership, walking through each persona’s end-to-end experience.

Getting engineers into these workshops, rather than handing them a requirements doc, changed the conversation about what was worth prioritising technically. Pain points became shared problems.

Business Requirements

In parallel, I ran a scoping workshop with the Product Owner and Engineering Manager to surface the constraints that would shape everything downstream:

Understanding these constraints early meant the solutions I developed were grounded in reality from day one, not handed to engineering and negotiated down.

Defining the Problem

Research pointed to three pain points severe enough to warrant rethinking the fundamental model of how tournament communication happened, not incremental fixes to WER’s interface.

Pain Point 1: Match Reporting Was a Paper Logistics Problem

Organisers printed result slips, cut them, distributed them to players, collected them back, and manually entered results. At average event sizes this was slow and error-prone. At larger events it required dedicated staff just to manage paper flow, every round, the same friction.

Pain Point 2: Pairings Created Predictable Crowd Bottlenecks

When round pairings posted, players converged on printed lists. At scale this became a genuine crowd management problem. The information players needed was simple, who am I playing and where, but the delivery mechanism created a bottleneck every single round.

Pain Point 3: Registration Consumed Staff Time Better Spent Elsewhere

Local game store staff are running a retail business. Every minute entering players into WER was a minute not spent serving paying customers. New players without membership cards made this worse: registration became a visible queue that discouraged first-timers from coming back.

These three problems shared a root cause. WER was designed around paper and manual data entry at a time when that was the only option. Fifteen years later, it didn’t have to be.

Design Hypothesis

I brought a focused proposal to engineering and product leadership: test whether moving tournament communication entirely off paper, onto a web-based organiser tool paired with a mobile-accessible player experience, could eliminate all three pain points at once.

A web-based replacement would also remove the hardware barrier created by WER’s Windows-only model, and allow multiple staff members to access the system simultaneously.

Leadership approved the direction. We moved into prototyping.

Prototyping and Testing

With a validated direction and a backend team spinning up core infrastructure in parallel, I ran a series of tight design sprints, moving from sketches to Figma wireframes to testable prototypes as quickly as the engineering cadence allowed. Working alongside a team building their frontend skills meant design decisions had to be practical from the start. High-concept solutions that would have been expensive to build were out. Clarity and simplicity were engineering survival strategy.

Solving Registration: Two Models, One Clear Winner

The registration problem had two plausible solutions. Both replaced manual entry; they differed in how players would identify themselves to join an event.

The first model used a short alphanumeric code, players called out or typed a unique identifier. The second used a QR code, players scanned on arrival.

We tested both in live store environments. The QR approach failed consistently: scanning was unreliable under variable game store lighting, and the mental model of “scan to join” required explanation every time. The short code won decisively, faster, more robust, and immediately intuitive across every user type from seasoned regulars to first-timers.

The mobile web portal we built to support player-side registration performed better than expected. Players didn’t just tolerate it, they asked for more. Feedback from testing surfaced a clear appetite for managing the entire match experience through “the app.”

Identifying the Companion Opportunity

That feedback pointed to something larger than a registration fix. What players were describing was a lightweight companion product, a mobile-first experience that kept them connected to the event without requiring the organiser to manage it for them.

I developed and pitched the concept to organisational leadership: a standalone mobile expression of EventLink handling the full player-side event experience, registration via short code, real-time pairings, digital result reporting, and integration with the existing player account system. The pitch was built directly on testing data from the beta programme, grounding the conversation in evidence rather than speculation.

Leadership approved the expanded scope in the same meeting. (See the Magic Companion case study for the full pitch prototype and design process.)

From Wireframes to Beta

With the core interaction model validated, I moved through successive rounds of wireframing, from rough sketches exploring information density through to higher-fidelity Figma prototypes used for closed beta testing in stores. Each round was checked against engineering feasibility before moving forward, keeping the gap between design and buildable reality as small as possible.

The closed beta ran across a select group of stores before global launch. Findings from beta informed final adjustments. EventLink launched on schedule.

Outcomes

EventLink launched on schedule and was met with immediate positive response from the retailer community. The beta cohort reported that the transition from WER meaningfully reduced the time and effort required to run events, particularly around registration and match reporting, the two pain points we had set out to solve.

“EventLink is the best thing since sliced bread. Having 30+ commander players and two 8-player drafts all running at the same time and the system didn’t skip a beat. Also the penalty/add drop integration is an actual godsend.” Anthony M., Retailer

The successful beta secured full funding and an expanded team to continue development. What began as a focused MVP became a multi-year product programme. EventLink and its companion products are still maintained by dedicated teams at Wizards of the Coast.

What this project demonstrates:

Product Designer, Wizards EventLink · Wizards of the Coast · 2019–2023