A peer-review workflow using shared decks

Peer review of drafts fails for a reason that has nothing to do with the students. A draft is prose, and a reader of prose responds to prose: this sentence is awkward; I liked the introduction; maybe more examples. None of that is wrong, and none of it helps, because the problems that make a paper weak are almost never in the sentences. They are in the structure — a claim with nothing under it, an objection nobody answered, an order that wanders — and a reader of a finished draft cannot see the structure, because the prose is covering it.

Review the cards instead of the draft, and the structure is the only thing there is to see. This guide is a workflow for doing that: in class, on a table, with cards; or between classes, with software that can show a reviewer the cards and nothing else.

What changes when you review cards

A reviewer looking at a row of claim cards, each with its evidence beneath it and its counterpoint beside it, cannot say I liked it. There is nothing to like yet. What they can say is:

• This claim has one card under it, and it's from the same source as the claim before.
• This counterpoint has no answer beside it.
• I don't see how claim three follows from claim two.
• Your thesis says X, but claims four and five are about Y.
• What is this evidence card doing here? Nothing points at it.

Every one of those is a sentence a writer can act on, and none of them requires the reviewer to be a better writer than the author. It requires them to be able to see a table. That is the whole advantage: structural review is something a peer can do well, and prose review mostly is not.

The workflow, in class

Before class. Each student has their cards — claims, evidence, counterpoints, thesis — in their current best order (student guides 1, 2 and 6). Not a draft. If a draft exists, it stays in the bag.

Minute 0–5. Pairs. Each student lays out their row on the table exactly as they would arrange it for the draft: thesis at the top, claims in a row, evidence under, counterpoints beside. No explanation. The author says nothing.

Minute 5–15. The reviewer reads the table and writes on three blank cards, one sentence each:

1. The thinnest claim — which claim has the least under it, and what would it take.
2. The unanswered objection — which counterpoint has no answer beside it, or which objection the reviewer would raise that is not on the table at all.
3. The join that does not hold — where, reading the claim titles in order, the reviewer stopped believing that one followed from the last.

The author still says nothing. This is the hard rule and the one that makes it work: an author who explains is an author who is not learning what the cards say without them.

Minute 15–20. The reviewer reads the three cards aloud. The author may ask one question of each — what would convince you? is the useful one — and writes the answers down. Then they swap roles.

Minute 40–50. Each author, alone, decides what to do with each of the three cards: find evidence, write the answer, reorder, narrow the claim, or disagree with the reviewer and say why on the back of the card. The three review cards go into the author's stack, dated. They are part of the record (instructor guide 2).

What you have at the end is thirty students each holding three specific, structural, actionable notes about their own argument, produced by people who are not yet good writers — and a class period in which nobody said I liked it.

The workflow between classes

The same review can run outside class if the reviewer can see the author's cards without being able to change them, and can leave notes attached to particular cards. On paper this means photographs and a shared document, and it works badly. With software that works from cards it works well, because the software can give a reviewer exactly that: a read-only copy of the deck — the cards, the links, the order — and a place to comment on a particular card, and nothing else.

The assignment is the same three sentences, written as comments on the three cards they are about: the thinnest claim, the unanswered objection, the join that does not hold. The author reads them, replies if they want, marks each one dealt with when it is, and the exchange stays attached to the cards it concerned.

Two rules for the software version:

The reviewer sees the structure and not the draft. Give the reviewer the cards and the order; do not give them the compiled draft, or they will review the prose. Most software that works from cards lets the author choose what a link hands over; the structure and the links are the right choice for this exercise and the draft is the wrong one.

The reviewer does not see the process. The author's record — when they worked, what they cut and why, how many sessions — is the author's and is not part of peer review. A student reviewing a classmate's argument has no business with their working pattern, and software built on these principles will not include it in what a reviewer can see. Say so to the class; students are rightly wary of anything that shows their work to each other.

Reviewing a published deck: the whole class, one argument

A variation for a single session that teaches structural reading to everyone at once. Take a completed paper — a former student's with permission, or one of the worked examples that come with the method — decomposed into cards, and put the deck in front of the whole class: on a wall, on a screen, or as a deck everyone can open and read but not edit.

Then do the three questions as a room. Which claim is thinnest? Which objection is unanswered? Where does the chain break? Students will find, in a published paper by a competent writer, all three — because every argument has them — and will learn in twenty minutes that structural review is a thing you can do to any argument, including your own. Send them home to do it to their own cards.

A deck that can be copied is better than one that can only be read, because a student who copies the deck into their own space can rearrange it — try the objection first, cut the thin claim, see what the paper becomes — and that is the exercise from student guide 6, done on someone else's argument, where the stakes are zero.

What the reviewer's three cards teach the reviewer

The author gets three notes. The reviewer gets something better: practice at seeing an argument's structure through its cards, which is exactly the skill they need on their own. Students who have reviewed three classmates' rows come back to their own row and see the thin claim they had been walking past for a week. This is the reason to run the workflow more than once. The first time, the reviews are cautious and the authors defensive. The third time, the reviews are sharp and the authors ask for them.

Grading it, or not

Do not grade the review cards. Grade the paper, and if you want to acknowledge the review, acknowledge that it happened — three cards written, three cards received. A graded review becomes a performance for the instructor; an ungraded one stays a note to a peer. The improvement shows up in the papers, which is where you were going to look anyway.

If the class uses software

Software that works from cards, built on the principles in these guides, gives an author two kinds of link to hand to a classmate: one that shows the cards and the draft for reading, and one — for a reviewer, an advisor, a supervisor — that shows the argument's structure, where the evidence is thin, and a place to comment on a card, with the author choosing which of those to include. The reviewer needs no account. The author sees the comments, replies, and resolves them; the reviewer never changes the manuscript, and nothing about the author's process is part of what the reviewer sees. A deck can also be published read-only under a rights statement, for the whole-class exercise, and copied by anyone who wants to try rearranging it. Nothing about the workflow changes; it is the table, with the reviewer somewhere else.