How to Write an Honest Review Using a Content Creation Workflow

Content creation workflow: the four tasks you'll finish in this lesson

A content creation workflow is the order work happens, not a tool pile: choose one idea, build one explanatory graphic, record a captioned short demo, claim-check AI-assisted drafts, and log every asset license. Google warns that using generative AI to generate many pages without adding value may violate its spam policy on scaled content abuse ^[1].

This lesson is for beginners building a small affiliate site who want to publish real, checkable work — including reviews of products they have not bought — without pretending to hands-on experience. It assumes you are working at night, on a free tool stack, with no budget to waste.

If you have been burned by reviews that pushed whatever paid the highest commission, read the claim-check section first. It is about labelling, in public, what you know and what you do not.

What you will have finished

• One graphic that explains one idea, plus the editable source file.
• One short captioned, transcribed demo free of private account data.
• A draft where every product, price and policy claim has been checked against a primary source, and any non-hands-on detail is labelled second-hand.
• A license log listing every outside asset and the permission you relied on.
• A clear answer to whether you need to pay for anything yet — usually, not yet.
• An honest “What I did instead of buying” box for any review written without hands-on use.

Each section ends with a Done when line. If you cannot tick it, do not move on. The four markers are included in the starter kit checklists.

This lesson will not tell you a tool is best; we are not claiming we tested anything here. It will not promise traffic or income. The output is finished, checkable content a reader can act on.

Make a graphic that explains one idea

One clear graphic can carry a comparison that three paragraphs bury, and it works on a phone where long tables collapse. Every image needs a text alternative for screen-reader users; decorative images should have an empty one ^[6].

1. Write the one-sentence promise. If you cannot say what the graphic shows in one sentence, it is two graphics or none.
2. Pick the form. A two-column comparison, a three-step flow, or one labelled screenshot with an arrow. Skip decorative art.
3. Build it in the editor you already have — a document, slides, or a free design editor. No new subscription.
4. Set the canvas to the size it will appear on the page, then shrink the preview to phone width and read it. If labels are unreadable there, the graphic has failed.
5. Limit type and colour. One heading size, one body size, two or three colours. Keep words out of the image where surrounding copy can say them; avoid text inside images unless a logo ^[6].
6. Write the alt text by category. Informative image: short description conveying essential information. Decorative: alt="". Chart or diagram: complete text equivalent of the data ^[6].
7. Export twice. Save the editable source file, then export a web version. WebP usually gives smaller files than PNG or JPEG at similar quality ^[5].
8. Look again at phone size and delete one element. The graphic is usually clearer with less in it.

Illustrative example: a fictional beginner site about desk lamps makes one graphic: three labelled boxes reading clamp, base and arm, with one line under each on where that mount fits. Two colours, no photographs, no stock art. Alt text: three desk lamp mounts compared — clamp fits a shelf edge, base sits on a desk, arm reaches over a monitor. Editable file saved as lamp-mounts-source next to exported lamp-mounts.webp. This is a made-up example, not a result anyone reported.

Done when: one readable graphic supports the lesson and its editable source is saved.

Record the step the reader needs to see

Video earns its place when a reader has to watch a sequence — where the button sits, what changes after the click. Captions make the demo usable for Deaf or hard-of-hearing readers and anyone who cannot play audio; automatic captions need manual correction ^[3].

1. Choose one visible task. Renaming a saved view, adding a disclosure line above a link, switching one setting. Not a tour.
2. Write a five-line script: what the reader will see, the starting point, the action, the result, where to read more.
3. Clean the screen before recording. Log out, use a blank or demo account, hide email addresses, notifications, bookmarks and real names. Turn off pop-ups.
4. Record at the page's aspect ratio and keep it short. One task, one take you would not be embarrassed by.
5. Start captions automatically, then correct them by hand. Automatic captions do not meet user needs or accessibility requirements unless confirmed fully accurate; a single missing word such as not can reverse meaning ^[3].
6. Check the caption file format. WebVTT is the most common caption format on the web ^[3].
7. Publish a transcript too. Captions and transcripts carry the same text; one can develop the other ^[3].
8. Write the same steps in text under the video so the lesson still works for someone who cannot watch it.
9. Export a still at the page's image size and compare WebP and JPEG for file size and sharpness before uploading ^[5].
10. Consider affiliate link disclosure in video. Decide where a disclosure line could go in the video and below it.

Illustrative example: a fictional demo shows one task — placing a disclosure line above an affiliate link in a page template. The recording starts on a blank test page, no account menus visible, forty seconds long. Automatic captions render sponsored as spurned, so the file is corrected by hand and exported as WebVTT. A transcript is pasted under the video, and the three steps are also written out as text. Nobody is identified and nothing real is shown.

Done when: one demonstration is accessible, accurate and free of private account data.

Use drafts with a claim check

An assistant is useful for structure and for asking what a reader might want to know next. It is not a fact source: generative models predict likely word sequences, so output can contain inaccuracies, and Google's guidance says it is critical to manually fact-check and review all AI-generated content before publishing — including metadata such as title elements, meta descriptions and image alt text ^[1].

1. Set the job for the assistant. Outline, tighten a clumsy paragraph, list questions a beginner might ask. Never the prices, policies or product facts.
2. Write what you can stand behind first. What you read, what you compared, what you asked support, what you could not confirm.
3. Highlight every claim in the draft: product names, prices, plan limits, policies, dates, numbers, and any sentence starting with best.
4. Check each one against a primary source — the vendor's own pricing or documentation page, official program terms — and note the URL and date checked.
5. Cut or rewrite anything you cannot verify, including invented hands-on detail. If you have not used the product, say what you did instead.
6. Add something only you can add: one worked example, the limitations you found, and a clear next step. Google's people-first guidance asks who created the content, how it was produced and why, and treats trust as the most important part of E-E-A-T ^[2].
7. Disclose automation where a reader would reasonably wonder how the piece was made; Google describes AI or automation disclosures as useful in those cases ^[2].
8. Name the human editor and the date. The final check is a person's job, and the check date belongs on the page.

Illustrative example: a fictional draft about a made-up tool called LedgerLite says the free plan allows unlimited projects. The claim is logged, the vendor's own pricing page is opened, the phrase does not appear, and the sentence is cut. The draft keeps a dated link to the page checked and replaces the deleted line with what the writer actually did: read documentation, compared two export formats, and asked support one question by email. No experience is invented and no result is claimed.

Done when: every factual claim has been checked and the page contains an original example.

How to write the review when you haven't bought the product

You do not need to pretend you bought it. Write the review as a research summary: what the product claims, what the vendor's documentation says, what you could test without paying, and what you still cannot confirm. That is honest, useful, and safer for readers and Google.

1. Separate the three kinds of information in your draft: - First-party facts: price, plan limits, features listed on the vendor's page. Verify each on the vendor's site and date-stamp the check. - Second-hand research: forum complaints, review videos, support answers. Label these “reported by users” or “vendor support said,” never as your own test. - Your own experience: what you could see or try without buying, such as a public demo, pricing calculator, or support response to your emailed question. 2. Mark every sentence with one of those labels in the margin or a comment. If a sentence cannot be labelled, cut it. 3. Write the “What I did instead of buying” box after the intro. Example: “I did not buy this product. I read the pricing page, watched two official demo videos, and emailed support one question about the refund policy. I have not used the paid features.” Keep it short. 4. Omit any hands-on detail you cannot verify. Do not describe the dashboard, checkout flow, or results unless you saw them in a public demo you can link to. Replace invented detail with a link to the vendor's feature page or a note that you have not tested it. 5. Add a “limitations of this review” paragraph near the end: what you could not test, what the vendor would not say, and what the reader should try before buying. 6. Date the research, not just the publish date. Add a line: “Prices and policies checked on [date] against [source] and may change.” The claim table above supports this.

Illustrative example: the fictional LedgerLite review opens with: “I have not bought LedgerLite. I read the pricing page and help docs, compared two export formats in the free demo, and asked support one question by email. I have not used the paid dashboard.” The review then labels each claim as vendor claim, user report, or my check. The hands-on section is cut and replaced with a link to the official demo video. No experience is invented and no result is claimed.

Done when: the review labels every sentence as first-party fact, second-hand report, or personal check, and the “What I did instead of buying” box is published.

Check licenses before publishing

A license is the permission that lets you use someone else's work; Creative Commons licenses grant that permission in advance in a standard, legally sound way ^[4]. Getting this wrong means pulling an asset after publication, slower and more embarrassing than checking first.

1. Inventory every outside asset in the piece: template, image, icon, font, music, stock video, and any AI-generated image.
2. Find the license text on the source page and save a copy with the date. A search result snippet is not the license.
3. Check commercial use and modification. CC BY allows redistribution, remixing and commercial use with credit to the creator; CC BY-NC limits use to noncommercial purposes; ND licenses permit no derivatives; SA licenses require adaptations shared under the same or compatible license ^[4].
4. Write down the exact attribution wording the license requires and where it will appear on the page.
5. Replace anything you cannot verify today. Not next week — before you publish.
6. Label AI-generated images. For ecommerce product feeds, Google Merchant Center policies require AI-generated images to carry IPTC DigitalSourceType TrainedAlgorithmicMedia metadata and AI-generated product data to be labelled as such ^[1]; check the current policy page before building a feed.
7. Ask a qualified professional about edge cases — for example whether your page counts as commercial for a noncommercial license ^[4]. This is general education, not legal advice; license pages and program terms change, so check the date on the version you relied on.
8. Store the log with the draft, so the next refresh starts from a record rather than a memory.

Illustrative example: a fictional writer downloads a display font whose page says free for personal use, with no commercial option. The row goes into the log, commercial use marked no, and the font is replaced the same evening with one whose license page explicitly permits commercial use. The new license page is saved with the date.

Done when: the asset sources and permissions are recorded and no extra subscription is needed.

Tool decision: free first, pay for a repeated obstacle

You can finish all four tasks with tools you already have: a document or slides app for the graphic, the built-in screen recorder, the caption editor on the video platform, a spreadsheet for the two logs, and a free image converter. If a piece ships with that stack, the workflow has succeeded — a paid tool is an optimisation, not a requirement.

Upgrade trigger

Pay only when the same limitation blocks you a second or third time: production speed, collaboration, brand control, or export quality. Before subscribing, write down the time or work the tool saves and compare with monthly cost. A limitation once is not a trigger.

Candidate categories to research

• Design editors — for reusable layouts and brand colours.
• Screen recorders — if the built-in recorder cannot export the format or length you need.
• Video editors — only if you are cutting more than trimming start and end points.
• Captioning and transcription tools — the free starting point is automatic captions plus your own corrections ^[3].
• Image compression and conversion tools — lossless WebP runs about 26% smaller than PNG and lossy WebP 25–34% smaller than comparable JPEGs; a reference conversion tool is published with the format's library ^[5].

Illustrative shortlist for a $150–$200 budget and 30-day launch

You do not need to decide tonight. Use the dated comparison page and then verify each vendor's own pricing page on the day you buy. Do not pay for a funnel builder before you have published one piece.

We do not list live prices here because they change. The comparison page is updated with dates, but still re-check on the vendor's page before entering payment details.

Names you will see include Canva for design, plus screen recorders and video editors. Treat them as research candidates, not recommendations: we are not claiming we tested them, and no affiliate relationship to them is confirmed here. Read the vendor's own pages, dated, then look for a second source that mentions drawbacks.

On the obvious question — whether this site is just pushing whatever pays — here is the honest position. This lesson contains no product recommendation and earns nothing from you finishing it. Our review pages do disclose how they make money. Where we cannot verify a claim, we say so rather than filling the gap.

When you're ready to buy: check the dated affiliate marketing tools comparison, then verify today's price and plan limits on the vendor's own page. That's the only tool research link you need right now.

Do this first tonight: 30-minute action plan

For this plan, use an illustrative budget of $150–$200 and a 30-day launch goal. Spend tonight in this order; skip everything else.

• Minutes 0–5: Choose one product you can review honestly without buying. Pick something with free materials, a public pricing page, and a support email you can write to with one question.
• Minutes 5–15: Write the one-sentence promise and build the graphic. Use a document or slides app, export as WebP, write alt text, save the source file.
• Minutes 15–20: Record a 40-second demo of one step you can show without an account: setting up a blank page, not using the actual product if you cannot.
• Minutes 20–25: Claim-check the three factual claims in your draft against primary sources. Log each URL and date in the claim table.
• Minutes 25–30: Fill the license log for every outside asset and replace anything unverifiable. Then decide your first tool purchase: open the comparison page, check today's price on the vendor's own page, and write your budget ceiling. Keep remaining budget for hosting only if a vendor page shows a trial or refund window you can cancel within; do not buy a funnel builder until you have published one piece.

Done when: you have one graphic, one captioned demo file, a claim table with dated sources, a license log, and a note on which single tool, if any, you will spend money on this week.

Appendix: tools & formats quick reference

• Image format: WebP lossless is about 26% smaller than PNG; lossy WebP 25–34% smaller than comparable JPEGs at equivalent quality, with native support in major browsers ^[5]. Export at display size and keep the editable source.
• Captions: Automatic captions need manual correction; a single missing word like not can reverse meaning ^[3]. WebVTT is the most common caption format, with SRT and TTML also in use ^[3]. Pre-recorded audio content requires captions and transcripts at WCAG Level A ^[3].
• Accessible images: Informative images get a short description; decorative get an empty alt attribute; charts get a complete text equivalent ^[6].
• Licenses: CC BY allows commercial use with credit; CC BY-NC limits to noncommercial; ND prohibits derivatives; SA requires same license for adaptations ^[4].

Related guides: The Anatomy of a Useful Product Review (With a Fill-In Template); How to Write a Comparison Post That Actually Helps Readers Choose; "Best X" Lists Done Right; Experience, Expertise and Trust on a Small Affiliate Site.