TLDR
To compare MTG playtest notes deck versions effectively, give every list a version ID, change log, hypothesis, and testing goal. Record every game with the same six tags: [MATCHUP], [MULLIGANS], [MANA], [DEAD CARDS], [WIN CONDITION], and [SIDEBOARDING]. Then compare repeated patterns against the question each version was built to answer—not just its win rate.
A 3–2 record tells you what happened. It does not tell you whether the new card improved the deck, whether you kept weak hands, whether one color repeatedly arrived late, or whether an opponent drew unusually well. Useful playtesting turns each result into diagnostic evidence while keeping enough context to avoid blaming the wrong card.
Give every deck version a question to answer
Do not call a list “new version” and hope you remember what changed three weeks later. Use a simple sequence such as Phoenix v1.0, Phoenix v1.1, and Phoenix v1.2. Add the date when lists might be tested out of order or shared with other players.
Each version needs a short hypothesis. A useful hypothesis predicts what the change should improve and identifies what you need to observe. “Trying two different cards” is a change log. “Replacing two expensive threats with cheap interaction should reduce turns spent unable to affect aggressive matchups” is a testable hypothesis.
Wizards’ playtesting guidance recommends deciding what a test is meant to learn, selecting relevant matchups, playing both sides when possible, and deliberately trying alternatives or sideboard plans. Its goal-oriented playtesting guidance is a useful foundation for a structured testing session.
- Deck name and format
- Version ID and date
- Exact cards added and removed
- Reason for each change
- Expected improvement
- Target matchup or game state
- What result would challenge the hypothesis
Try to keep each version focused on one change package. That package might contain several connected edits, such as removing two expensive threats and adding two early interactive spells. Changing the mana base, threat suite, sideboard, and draw engine simultaneously makes the result much harder to interpret.
Use the same six tags in every game
Consistency makes notes comparable. Free-form comments such as “deck felt bad” preserve the emotion but misplace the diagnosis. The following six tags cover the most common causes of a deck performing differently from its intended plan.
| Tag | What to record | Useful example |
|---|---|---|
| [MATCHUP] | Opponent, archetype, play or draw, and pre-board or post-board | Azorius Control, draw, Game 1 |
| [MULLIGANS] | Hand size, keep or mulligan reasoning, and whether the hand functioned as expected | Kept six with two lands, cantrip, and early interaction |
| [MANA] | Missed land drops, unusable colors, flooding, or sequencing constraints | Had four lands but no second red source for two turns |
| [DEAD CARDS] | Card, game state, and reason it lacked a useful target or timing window | Removal spell had no legal target against the opponent’s threat package |
| [WIN CONDITION] | How the deck attempted to close, whether the plan was available, and what stopped it | Established engine but lacked a way to convert resources into pressure |
| [SIDEBOARDING] | Cards in and out, tactical reason, and whether the plan affected the game | Added graveyard interaction; removed slow removal with few targets |
Also record the result, but place it beside the tags rather than above them. A win can expose a structural problem, and a loss can show that a change worked. If the revised mana base consistently casts the important spell on schedule but the opponent answers it, the mana edit may have succeeded even though the game did not.
Write one compact note after each game
Take notes immediately while the important decisions are still identifiable. You do not need a turn-by-turn transcript. Capture the opening-hand decision, the main turning point, and the observation most relevant to the version’s hypothesis.
Example game entry
- Deck: Phoenix v1.2
- Test goal: Determine whether two cheaper interaction spells improve the aggressive matchup
- Game: 4, post-board, on the draw, loss
- [MATCHUP] Red aggro; pressure started on turn one
- [MULLIGANS] Kept seven: three lands, interaction, draw spell, two threats. Keep had both colors and an early play
- [MANA] Cast available spells on schedule; drew two additional lands after stabilizing
- [DEAD CARDS] Five-mana threat stayed in hand because the game required multiple actions per turn
- [WIN CONDITION] Stabilized at low life but could not establish a clock before the opponent rebuilt
- [SIDEBOARDING] In: two cheap removal spells. Out: two slow value cards. Removal was relevant; one expensive threat may also need to leave
- Next question: Does trimming another expensive card improve post-board recovery without weakening slower matchups?
This entry is useful even though it covers one loss. It suggests that colored mana was not the immediate issue, the added interaction did its job, and the remaining expensive threat conflicted with the post-board plan. Those are leads to test again, not final verdicts.
Separate pre-board and post-board results
Game 1 and post-sideboard games test different configurations. Sideboarding can materially change how a matchup plays, so combining all games into one record can hide whether the main deck, the sideboard plan, or both need work.
For every post-board game, list cards in and out with a tactical reason. “+2 removal, -2 threats” records the action but not the plan. “Add cheap removal to survive the first three turns; remove slow threats that cannot be deployed while answering pressure” lets you assess whether the sideboard plan made sense even when the cards were not drawn.
A testing gauntlet also helps keep opponents relevant and repeatable. If you need to define representative matchups before comparing versions, use a structured MTG testing gauntlet workflow rather than testing only against whichever deck happens to be nearby.
Distinguish mana problems from bad sequencing
The tag [MANA] should describe a symptom, not deliver an instant verdict. “Mana screw” is too broad. Record whether you missed land drops, lacked a particular color, drew lands that entered tapped at the wrong time, or could not cast multiple spells in one turn.
Mana requirements depend on the deck’s strategy, card access, and opposition; there is no single construction formula that fits every list. Before adding lands after one awkward game, inspect the curve and colored requirements. A deck builder can manage revisions, the main deck, sideboard, maybeboard, opening-hand tests, and goldfishing, while curve analysis helps inspect cost distribution. The MTG Deck Builder is useful for revising the list, but the game log supplies the matchup and sequencing context that list structure alone cannot provide.
If notes repeatedly mention the wrong colors, perform a colored-source audit. If they instead show plenty of mana but too many expensive cards competing for the same turn, inspect the shape of the mana curve. This distinction prevents “add another land” from becoming the deckbuilding equivalent of restarting the router.
Record why a card was dead
A card is not automatically dead because it remained uncast. It may have been stranded by mana, held for a better target, made unnecessary by a faster line, or drawn after the relevant window. Each explanation implies a different change.
- No legal or relevant target: possible matchup or sideboard problem
- Could not produce the required color: possible source-distribution problem
- Could not afford the tempo loss: possible curve or matchup-speed problem
- Held for a better target that never appeared: possible sequencing or threat-assessment question
- Redundant with another card already drawn: possible density problem
- Drawn after its useful window: possible situational-card or mana-value problem
Look for recurrence across games. One late copy of a strong card says little. The same card repeatedly missing its window against the matchup targeted by the test is a pattern worth investigating.
Compare patterns, not isolated outcomes
When reviewing two versions, start with the original hypothesis. Group notes by matchup and by pre-board or post-board configuration, then scan each tag for repetition. Do not pool unlike tests merely to create a larger-looking record.
- Confirm that the compared games used the intended deck versions.
- Group games by matchup and pre-board or post-board status.
- Compare mulligan frequency and the reasons behind those decisions.
- Review whether mana failures share the same cause.
- Count repeated dead-card contexts rather than every uncast card.
- Check whether the deck reached and executed its intended win condition.
- Review whether sideboard plans changed the relevant tactical problem.
- Write a conclusion as supported, unsupported, or still uncertain.
There is no universal number of games that makes one version definitively better. Opponent skill, matchup selection, play-draw balance, sideboarding, and ordinary game variation all affect the record. If the notes are mixed, retain both the uncertainty and the next question. “v1.2 appears better against early pressure, but needs more post-board games on the draw” is more useful than forcing a winner.
Copyable MTG playtest notes deck versions template
Version header
- Deck name:
- Format:
- Version ID:
- Date:
- Changes from previous version:
- Hypothesis:
- Target matchup or question:
- Expected sign of improvement:
- Result that would challenge the change:
Per-game log
- Game number:
- Opponent or archetype:
- Pre-board or post-board:
- Play or draw:
- Result:
- [MATCHUP]
- [MULLIGANS]
- [MANA]
- [DEAD CARDS]
- [WIN CONDITION]
- [SIDEBOARDING]
- Turning point:
- Most useful observation:
- Next question:
Version summary
- Games reviewed and relevant matchup groups:
- Patterns that repeated:
- Patterns seen only once:
- What the change improved:
- What became worse:
- Questions still unresolved:
- Decision: keep, revert, revise, or retest
- Next version and its hypothesis:
Digital lists make rapid changes easy, but physical testing can help when table play, shuffling, or board-state recognition matters. If you want paper copies of revised cards for casual testing, a service offering an MTG card printing workflow can be a separate practical step. It is optional; the same note system works with existing cards, placeholders, or digital testing.
Adjust the log for Limited and Commander
For Limited, add draft or sealed-pool context, archetype, fixing, curve gaps, and sideboard cards available in the pool. A repeated failure may originate in drafting or deck construction rather than an individual gameplay decision. Draft practice can also help isolate pick flexibility, signal reading, and curve construction before match testing.
For Commander, replace the single matchup field with commander identities, approximate game plan, turn order, and relevant table dynamics. Record whether a card was ineffective because of the deck’s construction or because three opponents created a specific board state. Sideboarding is usually not the central variable, so use that tag for pregame swaps or omit it while keeping the other tags consistent.
Make the next version earn its number
The best playtest log is not the longest one. It is the one that tells you what to change next and why. Name the version, define the hypothesis, use the same six tags, and separate list-level issues from matchup events. After several relevant games, summarize repeated patterns and create the next version around one focused question. That turns scattered anecdotes into a deckbuilding process you can actually repeat.