WorthBrief

How We Review Products

Last updated:

A review is only useful if the reader knows what it is based on. This page explains the criteria we apply to products and the labels we attach to our conclusions. Together, these two things tell you exactly how much weight a WorthBrief page can carry.

The three editorial levels

Every piece of WorthBrief analysis carries one of three levels. They are not marketing tiers — they are disclosure of method.

RESEARCHED

The piece is built from information that already exists publicly and can be checked: manufacturer documentation and specification sheets, official product pages, published manuals, warranty and returns terms, and other verifiable sources. We assemble, organise, and explain. We do not claim to have touched the product, and the writing never implies otherwise.

ANALYZED

The same sourcing as RESEARCHED, extended with structured editorial work: we define the criteria that matter for the category, weigh products against those criteria, compare alternatives side by side, and reason explicitly about trade-offs and value. ANALYSIS is reasoning on top of documented facts — not an experience of the product.

HANDS-ON TESTED

This level is used only when a member of the editorial team has physically handled or used the product being discussed. It is the strongest claim we can make, and it is deliberately rare.

We do not use "tested", "hands-on", or any equivalent for a product we have not physically used. If a page carries a testing claim, that claim is true, and the page describes the scope of the testing — what was used, in what context, and over what period — so that a reader can judge how far it generalises. We never pad a page with the appearance of testing to make it feel more authoritative. Where all we have is documentation, the page says that.

What we evaluate

Whatever the level, our evaluation is organised around the same questions. Not every question applies to every category, but we work from the same framework:

  • Product purpose — what problem the product is designed to solve, and who it is genuinely for.
  • Features — what it offers, and which of those features change how it is used in practice.
  • Specifications — the documented technical attributes, and what they mean for compatibility and performance expectations.
  • Pricing — what it costs, and how that price sits relative to what the category generally offers.
  • Alternatives — what else exists at a comparable price or purpose, and how the trade-offs differ.
  • Ease of use — what is involved in setting up, operating, and living with the product, based on documentation and available public information.
  • Potential limitations — constraints, restrictions, missing features, and circumstances where the product is a poor fit.
  • Warranty — what coverage is offered, how long it lasts, and what it excludes.
  • Return conditions — the window, the requirements, and any costs the buyer may carry.
  • Consumer considerations — compatibility, ongoing costs, region availability, support, and anything else that affects the decision after purchase.
  • Value for money — an explicit judgement of whether the product's benefits justify its price relative to the realistic alternatives.

How we handle uncertainty

Where documentation is incomplete, contradictory, or region-dependent, we say so rather than smoothing it over. Where a specification is unverified, we describe it as stated by the manufacturer rather than as confirmed fact. Where two sources disagree, we note the disagreement. A page that flags its own gaps is more useful than one that pretends to have none.

Independence in practice

Editorial conclusions are reached by the editorial team and are not for sale. Advertisers, sponsors, and affiliate networks cannot purchase a favourable conclusion, a ranking position, or a positive assessment. Where commercial links exist, they are disclosed near the relevant content. Details are in our Editorial Policy and Affiliate Disclosure.

Questions about our method

If you believe a page does not meet the standard described here, or you want to know how a specific conclusion was reached, write to [email protected]. We answer method questions directly and correct errors in public.