Test the lead magnet before you build the polished version

A fictional cooking educator wants to create a meal-planning download for people who repeatedly buy ingredients they already have. The initial idea is a twenty-page guide covering planning, shopping, storage and recipes. It sounds generous, but it contains several different jobs and would take substantial time to produce.

The educator narrows the first claim: “A person planning an ordinary weekly shop can use this sheet to identify ingredients already on hand before writing a shopping list.” That claim can be explored with a rough resource. It does not require a finished ebook or a prediction about how many followers will request it.

Define who the resource is for and who it is not for. In this example, the intended reader already does some household shopping and wants a simpler preparation step. The test is not about medical nutrition, dietary treatment or food-safety decisions. Avoid adding those topics merely to make the download feel comprehensive.

Write down the assumption most likely to fail. Perhaps the educator assumes that people will inspect their cupboards before choosing meals. Perhaps the sheet's categories do not match how people think about ingredients. A useful test gives the team a chance to discover that the original approach is wrong.

The lead-magnet ideas guide helps with selecting possibilities. Prototype research answers a later question: does this particular version support the task you intend it to support? Those are different decisions, and enthusiasm for the topic does not settle the second one.

Editorial illustration, not a product screenshot.

The educator creates a single page with three areas: “Already have,” “Use this week” and “Need to buy.” A completed example uses ordinary fictional ingredients. A blank area lets the participant try the same process with a supplied scenario. The sheet is deliberately plain so changes remain inexpensive.

Do not make the prototype so unfinished that the test becomes a guessing exercise. It needs the instructions, labels and example required for the task. A box marked “content goes here” cannot reveal whether the missing content would help. At the same time, a custom cover illustration is unnecessary if the uncertain part is the order of the planning steps.

Use realistic but non-sensitive material. A fictional cupboard list is enough to explore whether the instructions make sense. Participants do not need to disclose private household details, spending or personal health information to test the basic structure. If their real context matters, explain what information you need and why before the session.

Record the version being tested. A simple label such as “Planning sheet, prototype two, September 29” prevents notes from different drafts being mixed together. Keep the earlier version so you can connect a revision to the observation that prompted it.

The GOV.UK guidance on planning user research emphasizes research questions and the decisions research should inform. Apply that discipline at a small scale: build the thing that can answer your question, rather than polishing the thing you already hope to publish.

A teammate who helped invent the sheet knows too much about it. They can catch spelling errors, but they may automatically fill gaps that a new reader cannot. Seek participants who recognize the shopping situation and have not been coached through your intended workflow.

Explain the purpose of the session in plain terms. You are exploring whether a rough planning sheet is useful and understandable. Participation should be voluntary, and someone should be able to stop. Ask permission before recording anything, explain how notes will be used and avoid collecting details that the research does not need.

Do not recruit only people likely to praise you. Friends and enthusiastic customers can provide useful observations, but their relationship with the business may affect how comfortable they feel criticizing it. Keep that limitation in the notes. Include different relevant circumstances where they could change how the resource works.

There is no magic participant count in this article. A small round can reveal concrete usability problems without estimating how common those problems are across an audience. Plan enough time to observe carefully, revise and test again. A large pile of shallow preference answers may be less useful for this decision than a few detailed task observations.

Keep the invitation separate from a sales pitch. If the participant thinks the goal is to approve your upcoming product, they may focus on being supportive. Say that discovering a reason not to build the full guide would also be a useful result.

Here is an original script for the illustrative planning sheet: “Imagine you are preparing a shopping list for the next few days. These are the ingredients already available, and these are two meals you want to make. Use the sheet in whatever way seems natural to decide what belongs on the shopping list.”

Then stop talking long enough to see where the participant begins. Do not say “First fill the Already have box” if the order of the boxes is one of the things you need to test. That instruction would supply the missing explanation and hide the problem.

Ask neutral follow-ups when needed: “What are you looking for?” or “What does that label mean to you?” Avoid leading questions such as “Wasn't the example helpful?” A person may agree with your wording even when the example did not influence their behavior.

Moderated usability testing guidance from GOV.UK describes observing participants attempting relevant tasks and using appropriate prompts. The principle transfers to a small downloadable resource: watch the resource do its work before rescuing it with an explanation.

If someone becomes stuck, note the point and the reason they give. You can then help them continue to explore later parts, but mark that help in the record. A task completed after coaching is different from a task completed independently. Neither is a judgment of the participant; each tells you something about the prototype.

Original hypothetical research log. No participant session or outcome is claimed.

Suppose a participant says “This looks useful.” That is a reaction. Suppose they copy an ingredient into both “Already have” and “Need to buy.” That is an observation. “The column labels may not make the transfer rule clear” is an inference. Keep these statements separate so the team can challenge its interpretation.

An illustrative decision log might read: “Observation: participant placed rice in both columns. Context: rice appeared in the supplied cupboard list. Interpretation: the instruction to subtract existing ingredients was missed. Proposed change: add a worked line showing an ingredient removed from the shopping list. Next check: observe the same task with the revised sheet.” This is a hypothetical example, not a report of research we conducted.

Do not turn every pause into a problem. Someone may be reading carefully or considering their own approach. Ask a neutral question and record their explanation before deciding that the layout caused difficulty. Likewise, a fast completion does not prove the resource is useful in everyday life.

After the session, group observations by the task they affect. Confusing labels, missing examples and irrelevant content may call for different revisions. GOV.UK's guidance on analyzing a research session supports working from observations toward findings and actions.

Preserve disagreements. If one person wants more space and another prefers a compact sheet, identify the circumstances behind the difference. Perhaps one plans on paper while the other uses the resource as a reference. The correct response may be a clearer intended mode of use rather than a compromise layout that serves neither well.

Before testing, define the decisions you could make. Continue to a more complete draft if readers can understand the task and the resource contributes something useful. Revise if a specific instruction or layout problem blocks use. Narrow the scope if only one part addresses the situation. Stop if the central premise does not appear helpful and you have no credible revision to explore.

These are editorial decisions, not statistical thresholds. A handful of sessions cannot prove demand across Instagram, forecast revenue or establish a download conversion rate. If you later publish the resource, actual requests and use will provide different evidence. Keep the questions separate rather than claiming the prototype validated the entire business case.

For the cooking educator, the result might be a one-page planning sheet instead of a twenty-page guide. That smaller artifact can be a better outcome if it solves the specific problem more clearly. Length is not the success criterion. A reader's ability to make the intended decision is closer to the point.

After revision, test the new version with someone who has not learned the old one. Check the exported file and delivery route separately using the delivery guide. A useful prototype can still be undermined by an inaccessible destination or a mismatch between the caption and the actual resource.

When you build the campaign, describe what the resource does in the same concrete terms used in the research question. The comment-to-DM guide covers that delivery mechanism. Your preparation has supplied something it cannot create for you: a better-supported reason for the resource to exist.