How Strangely Useful guides are made.

A Strangely Useful guide should answer a real task, name the limits of that answer, and show enough sourcing for a reader to understand why the page exists.

We start with the reader problem

Guide topics are framed around the question a person is likely to search or ask: how to fix a payment mistake, spot a fake support contact, understand a setting, or decide whether a tool is safe enough to use.

We check primary sources first

Official help centers, product documentation, legal terms, support pages, government resources, and standards documents are preferred over summaries. Secondary sources can add context, but they should not replace the source closest to the claim.

We separate instructions from limits

Practical pages should say what to do, what not to do, what may not be reversible, which account or region the guidance applies to, and where a user should go next if the first path fails.

Images must support the story

Editorial images, screenshots, and diagrams should match the task being explained. Generated images are labeled through page captions and metadata, and they must not be presented as documentary proof or product screenshots.

Updates and corrections stay visible

Published guides can be updated when interfaces, fees, policies, or source documents change. Material factual corrections are recorded through the public corrections process instead of silently rewriting the record.