Soliciting beta readers for technical zines

Editing a technical zine is a lonely process. You stare at your own pages too long, convinced everything is clear — until someone reads it and points out that a core term was never defined, or a diagram only makes sense to you. I’ve tried a lot of feedback channels over the years: posting individual pages on Twitter, hiring a friend to do a deep pass for confusion, hiring a technical reviewer, asking a casual friend to skim parts, having my partner read it, and hiring a copy editor near the end. All of these helped, but I still felt I wasn’t getting enough signal on which specific parts were confusing.

For the recent CSS and bash zines, I tried something new: recruiting 10–20 beta readers and asking them for structured feedback. It worked well enough that I want to write up the process.

Recruiting the right readers

I emailed a small slice of my mailing list — roughly 300–600 people — and asked for volunteers. About 5% replied, which gave me 10–30 beta readers per zine. That range felt right: enough diversity of perspective, but not so many that managing the feedback would become a full-time job.

Two things made the recruitment email effective. First, I specified exactly who I wanted feedback from. For the CSS zine, I asked for “people who know some basic CSS, but still get really confused & frustrated every time they try to get something done.” That focus ensured the feedback came from people in the zine’s actual audience. Second, although I didn’t ask for it, most volunteers naturally included a sentence or two about their background with CSS when they replied. That context was invaluable when I later had to weigh conflicting feedback, and I would explicitly request it next time.

Telling them what I wanted

The most important step was being precise about the kind of feedback I needed. Left to their own devices, people often default to either vague praise or speculative critique about what others might find confusing. Neither is very actionable.

So I sent each volunteer a detailed email with the draft link and explicit guidelines. The feedback I wanted:

  • Things they found confusing, with specific examples like “On page 3 it uses the term ‘inline’ and I had to look up what that meant”
  • Questions they had — big ones like “what even is the point of this feature at all?” and small ones like “what is that code supposed to output?”
  • Specific things they learned, such as “I never understood what X syntax meant, and now I get it!”

And the feedback I explicitly did not want:

  • Things they thought someone else might find confusing, but that they themselves understood — most people aren’t good at simulating another reader’s confusion
  • Technical review, since I had a separate reviewer for that and didn’t want to crowdsource it

I also made clear that any amount of feedback helped, even if they only read a few pages. The deadline was short — about six days — which kept the process moving.

Consolidating the comments

The volunteers largely stuck to the guidelines, and almost everyone organized their comments by page. To consolidate, I built a text file with a section per page, then wrote a small Python script to push each page’s comments into the corresponding Trello card where I already tracked all other feedback.

One unplanned complication: I had shared a Dropbox link for downloading the draft, and forgot that Dropbox has its own commenting feature. Some readers left comments there instead of emailing. The page rendered painfully slowly in my browser, making manual copying impractical — so I opened the network tab, found the list_comments endpoint request, copied it as cURL, and pulled the raw JSON. A short Python script formatted those comments into the same per-page text format.

Reading the signal

With 10–30 readers, most pages got feedback from about five people. When multiple readers independently flagged the same confusion, that was a clear sign the page needed work. But readers sometimes disagreed — one would say a page was clear and they learned something, while another reported being totally lost. In those cases I leaned on each reader’s stated background to gauge whose perspective was closer to the intended audience, and I tried to fix the confusing element whenever I could find a way.

Making the changes

Some fixes were straightforward — a footnote that didn’t clearly refer to anything, an explanation of “css reset” stylesheets that made no sense. Others were harder. The page on stacking contexts, for instance, was confirmed to be genuinely confusing, and I suspect the topic may not be fully explainable in a six-panel format. For cases like that, I looked for a simpler concept I could explain in the space, such as “if z-index isn’t working the way you expect, the reason is probably that you have 2 elements in different stacking contexts.”

The biggest change to the CSS zine was adding a set of live examples at https://css-examples.wizardzines.com, targeted at concepts the beta readers had flagged as confusing, and marking those panels with a small “try me!” icon.

The process also had an unexpected side benefit: seeing what readers said they learned — not just what confused them — gave me real confidence that much of the zine was landing as intended. That goes a long way toward quieting the “OH NO MAYBE THIS IS AWFUL” anxiety that precedes every release.

I’m not currently looking for more beta readers, but if you’re on the Saturday Comics mailing list, you may get an invitation when the next zine is in draft form.