TLDR: A useful custom mtg set playtest should answer one narrow question and record which exact card and set versions produced the result. Give every card a permanent ID, number each card revision, assign a version to the complete set file, and identify every session. Record observed events separately from suggested fixes. Afterward, classify each issue as keep, revise, retest, move rarity, hold, or cut.
The objective is not to prove that the entire set is balanced in one evening. It is to create a traceable loop: choose a hypothesis, test it in the right environment, record what happened, make a controlled revision, and test again. Wizards has described playtesting and iteration in similar broad terms: play, take notes, revise the card file, and repeat.
A session becomes difficult to interpret when it tries to assess mechanics, individual rates, Draft collation, archetype balance, flavor, templating, and final artwork simultaneously. Pick the most important uncertainty and build the test around it.
Good test questions are specific enough to influence the setup. For example: “Do players understand when resonate triggers?” is a mechanic question. “Does blue-red have enough inexpensive enablers?” is an archetype question. “Does this removal spell make expensive creatures unplayable?” is an environment question. “Is this set fun?” may be worth asking during a debrief, but it is too broad to design the session by itself.
| Test stage | Question it should answer | Useful environment |
|---|---|---|
| Mechanic microtest | Is the mechanic understandable, functional, and worth its complexity? | Small constructed test decks containing the mechanic and relevant interactions |
| Individual-card test | Does one design create the intended decisions at an appropriate rate? | Controlled decks in which the card can be drawn and used repeatedly |
| Early common test | Do the set’s basic themes, interactions, and game actions function? | Common-heavy decks or an all-common Sealed approximation |
| Archetype test | Do intended color pairs have enough enablers, payoffs, and baseline playables? | Curated Limited pools or targeted matchup decks |
| Environment test | Are pacing, removal, combat, fixing, and color balance working together? | Sealed or Draft using a sufficiently developed file |
| Polish test | Are remaining problems mostly wording, rarity, numbers, and presentation? | The intended final format with near-current files |
Wizards’ design guidance discusses early all-common testing as a way to expose confusion, fun, visible themes, and cards that may deserve a higher rarity. Its mechanic-design guidance also supports moving from focused mechanic tests toward evaluation of the complete environment. You therefore do not need a finished set before testing. In most projects, waiting for a complete file only makes foundational problems more expensive to repair.
For an isolated mechanic test, Wizards’ published guidance describes an early approach using 40-card decks with roughly eight to twelve new cards. Treat that as a starting model rather than a universal formula: the appropriate density depends on whether the intended destination is Draft, Sealed, Cube, Commander, or another casual format.
Card names are poor database keys. Names change, two concepts may temporarily share a name, and a redesign can retain its name while becoming a substantially different card. Assign each design a permanent card ID that survives renaming and ordinary revision.
A lean identification system needs five parts:
A complete reference might read “ASH-W-014 r03, set 0.7.0, session ASH-PT-2026-04-12-A.” That looks fussy until two testers provide contradictory comments about versions with different mana costs. The identifier immediately shows whether they actually tested the same design.
For the set file, use a simple three-part number: major.minor.patch. Increase the major number after a structural reset, such as replacing a primary mechanic. Increase the minor number after a meaningful design batch, such as revising an archetype or changing several commons. Increase the patch number for wording, typographical, and presentation corrections that are not intended to alter gameplay.
Individual card revisions can remain sequential. Move from r03 to r04 whenever a gameplay-relevant field changes, including mana cost, stats, card type, targets, timing, effect, or ability cost. Correcting a misspelled flavor word does not need a new gameplay revision, although it can still appear in the file change log.
Maintain one short change record per revision: “r04 — cost changed from 2R to 3R after repeated turn-three tempo swings.” This preserves both the change and its reason. If the next test disproves the diagnosis, you can reconstruct the earlier design instead of relying on memory.
A playtest packet should tell participants what they are testing without coaching them toward a desired verdict. Include the current card list or file version, intended format, session goal, known questions, required tokens or markers, and a feedback form. If cards create unusual game objects, prepare the correct helper materials instead of asking players to remember them; the custom token design guide covers the readability side of that task.
Do not spend hours polishing temporary art before a mechanic has survived basic testing. Legible names, costs, types, rules text, stats, card IDs, and revision numbers matter more. A visually refined render cannot rescue an ambiguous or unhealthy design. The broader custom-card workflow can help separate concept, wording, layout, and final review.
When physical copies would make repeated shuffling and table testing easier, prepare a clearly unofficial packet and consider printing custom MTG playtest cards only after verifying that every face displays the current revision. Retire or mark obsolete copies immediately; mixed revisions can invalidate the session.
A score such as “power: 4/5” is difficult to use without context. It could mean the card was strong in one matchup, looked frightening but was never cast, or won after the opponent kept a weak hand. Require the tester to describe what occurred.
For example, “This card is broken; make it cost five” combines a conclusion and a fix. A more useful report is: “ASH-B-021 r02 was cast on turn four in three games. Twice it removed the opponent’s best creature and returned a two-mana creature, creating a large immediate swing. The opposing player stopped committing a second creature in game three.” The designer can now examine rate, repeatability, matchup, and play pattern before choosing a solution.
| Dimension | Question to record |
|---|---|
| Clarity | Did players understand the card before it resolved, and did they interpret it consistently? |
| Fun | Did it create an engaging choice, satisfying moment, or repetitive chore? |
| Power and rate | What resources did it trade for, and under what board or matchup conditions? |
| Color fit | Does the effect support the intended color’s strengths, limits, and set role? |
| Rarity fit | Does its complexity, swinginess, or build-around demand fit its current frequency? |
| Synergy | Did it enable the intended strategy without being useless elsewhere? |
| Play-pattern health | Did it encourage interaction and decisions, or produce locks, snowballing, or non-games? |
| Template confidence | Is the intended function clear enough to compare against official terminology? |
These dimensions are prompts, not an official scoring standard. A card can be powerful but healthy, weak but enjoyable, or clear yet inappropriate at common. Record the dimensions independently before deciding whether the design succeeds.
Individual card notes cannot reveal every environmental problem. A reasonable removal spell may still contribute to a miserable format if the set contains too much efficient removal. A fair build-around may fail because its archetype lacks ordinary playable enablers. Use a separate environment debrief after Sealed and Draft tests.
If the environment is intended for Draft, use focused deck tests first and then move into repeatable draft sessions once the file can support meaningful choices. The custom MTG Draft testing guide covers pack setup, draft observations, and later-stage Limited testing. For earlier structural work on mechanics, color pairs, and the set skeleton, see the custom set design guide.
Begin the debrief by collecting observations before discussing fixes. Otherwise, the loudest proposed solution can become the group’s explanation of what happened. Consolidate duplicate reports, connect each issue to its card revision and session, and then assign a disposition.
| Disposition | Meaning |
|---|---|
| Keep | The design is meeting the current test goal; continue watching it. |
| Revise | Evidence supports a specific change before the next session. |
| Retest | The concern is plausible, but the test did not isolate it well enough. |
| Move rarity | The design may work with a different frequency, complexity expectation, or Limited role. |
| Hold | Do not change it while a related mechanic or environment issue is unresolved. |
| Cut | The design is redundant, structurally harmful, or not worth its complexity. |
Prioritize issues in four levels. First, fix anything that blocks play: incomprehensible text, missing components, loops, or unresolved functional questions. Second, address problems that harm the format, including repeatable non-games, dominant archetypes, unusable colors, or severe pacing failures. Third, investigate concerns that need more evidence. Fourth, polish names, flavor, minor wording, and visual presentation.
Change as few variables as the next question permits. If a creature appears too efficient, changing its cost, stats, creature types, and triggered ability simultaneously prevents you from learning which adjustment mattered. A controlled change creates a stronger next test.
Conflicting reactions are data, especially when they come from different decks or player preferences. Do not settle the matter by averaging “fun” scores. Identify the context behind each response. A graveyard payoff may feel excellent in the supported deck and useless elsewhere; that could be an intentional build-around profile rather than a defect.
Give the most weight to repeatable observed patterns, but do not treat repetition in one matchup as proof about the complete environment. Form a narrower follow-up question: Does the card dominate only slow decks? Is it frustrating because of rate, repetition, unclear counterplay, or session length? Can players identify the correct response after seeing it once? The next test should distinguish among those explanations.
Official terminology is useful when checking whether players will interpret custom wording consistently. The Magic Comprehensive Rules page is the appropriate official starting point for specific rules questions and current terminology. Similar wording does not make a custom card official, sanctioned, or guaranteed to function under every interaction; it gives the designer a clearer reference language.
Label custom cards and playtest materials as unofficial, and obtain the playgroup’s agreement before using them. MTG.cards describes its tools as independent and unofficial, intended for creative projects such as casual playtest cards, custom sets, tokens, and Cube cards. It also states that unofficial cards should not be represented as authentic or used where sanctioned-event authenticity is required.
Before closing the file, write the next session’s question in one sentence. Then confirm that every changed card has a new revision, the complete file has the correct version, obsolete copies are removed, and the test environment can actually answer that question.
A strong revision system does not eliminate judgment. It preserves enough context for judgment to improve. If every comment points to an exact card revision, session, observed event, and intended environment, your set stops being a pile of reactions and becomes a sequence of defensible design decisions.
