This page describes the process we intend to use for hands-on product reviews. Our launch articles are practical editorial guides. They are not scored product tests, and they do not imply that we have used a particular product.
Start with a defined agency scenario
Before a test, we define the workflow, user roles, required actions, and completion criteria. For example: invite a client, request three assets, review a submission, request a revision, and record an approval.
Separate evidence from claims
- Hands-on observation: behavior we verified in an account, with the plan and test date recorded.
- Documented information: information from official documentation or pricing pages, linked and dated where relevant.
- Editorial assessment: our interpretation of the evidence and the trade-offs for a particular workflow.
- Unverified point: a limitation, feature, or condition we could not independently confirm.
What a hands-on review should cover
We evaluate setup, the client’s first visit, permissions, ordinary work, common exceptions, notification behavior, mobile usability, export options, and the cost of the required plan. We use sample data rather than confidential client information.
Where a feature is restricted to an inaccessible plan, we identify that restriction rather than implying it was tested. A trial, a vendor-provided account, or a paid subscription will be disclosed when relevant to the review.
Recommendations need a context
There is rarely one best tool for every agency. A recommendation should explain the team size, workflow, constraints, and trade-offs it fits. We avoid unsupported scores, invented benchmarks, and claimed performance improvements without measurement.
Corrections and updates
Software changes. Reviews should identify when the relevant checks were made and explain material updates. To flag an error, email [email protected] with the article and supporting information.