Anyone can publish instructions. The question that matters is what happened between someone having an idea and you reading a numbered list. This page describes that, step by step, including the parts where we stop and cut things.
1. The question comes first
We do not start from a keyword. We start from a question somebody is actually asking, sourced from search demand, reader messages, and problems we have hit ourselves.
Before anything is written, we have to be able to state three things: who is asking, what they are trying to accomplish, and what they should be able to do when they finish reading. If we cannot answer those in one sentence each, the topic is not ready and does not get commissioned.
This is where most ideas die, and it is the cheapest place for them to die.
2. Scoping and honest exclusions
Next we decide what the guide will not cover.
A guide that tries to address every device, version, and region becomes a guide that helps nobody. So we pick the situation the majority of readers are actually in, name it explicitly at the top, and note the significant cases we are not covering.
We also check the question against the areas we deliberately do not write about — medical, legal, and individual financial advice, and anything that involves defeating security or licensing that belongs to someone else. Those are documented in About Tutorils.
3. Primary sources before anything else
Research works outward from the most authoritative source available:
- Official documentation from whoever makes the thing — support pages, changelogs, developer docs, release notes.
- The product itself, where we can access it.
- Standards and regulatory sources, where a claim touches security, privacy, or compliance.
- Other publications, last — and when a claim comes from another outlet, we say so and link to it rather than absorbing it as our own finding.
A claim that exists only in secondary coverage, with no traceable primary source, does not get stated as fact. Either we find the source or we flag the uncertainty.
4. Walking the steps
Where a procedure can reasonably be tested, we run it.
That means opening the software on a current version and describing what is actually on screen — the real menu label, the real button text, the real order of dialogs. Not what the documentation says should be there, and not what was there two versions ago.
While walking through, we record the things that break instructions in practice:
- Where the interface differs from the documentation
- Where a step requires a permission, subscription tier, or setting the reader may not have
- Where something is irreversible, and needs a warning before it rather than after
- Where the process silently fails, and what that failure looks like
- How long it actually takes, when that matters
Where we cannot test, we say so. Hardware we do not own, region-locked services, enterprise tiers, and paid plans we do not hold all produce the same response: the article states that the steps come from documentation rather than from a run-through. Pretending otherwise is the specific dishonesty this page exists to prevent.
5. Writing for the reader in a hurry
Structure is not decoration. Somebody reading a troubleshooting guide is mildly stressed and wants out.
So: the answer comes early, not after a history of the feature. Steps are numbered when order matters and bulleted when it does not. Prerequisites appear before step one, not discovered at step six. Warnings come before the destructive action. Headings describe what is in the section, so the page can be scanned rather than read.
Screenshots and illustrations are labelled for what they are. An AI-generated illustration is presented as an illustration, never as a photograph of a real screen — see How Tutorils Uses AI.
6. Checks before publication
Every guide is checked against a fixed list:
- Claims — each factual statement traces to a primary source or a test we ran
- Steps — each one matches the current interface, with conditions named
- Links — every outbound link resolves to what we said it does
- Safety — irreversible or risky actions carry a warning positioned before them
- Scope — the version, region, and device assumptions are stated
- Disclosure — any commercial relationship is disclosed at the top of the article
- Alternative text — images carry descriptions that work without sight of them
- Metadata — the title and description describe the article accurately, without inflated promises
7. Second review where the stakes are real
Guides touching account security, privacy, payments, or official government services get read by a second person before publication.
A reviewer is not proofreading. They are asked whether following the guide literally could harm the reader, whether any claim is stated more confidently than the evidence supports, and whether the article quietly assumes knowledge the stated audience will not have. Where a second person has reviewed a piece, the article says so. See Authors and Reviewers for who does this.
8. Maintenance after publication
Publication is not the end of the process.
Guides are revisited when the underlying software changes in a way that breaks the steps, when a reader reports that something no longer matches, or when a link rots. Every article carries its publication date, and an update date where it has been revised, so you can judge for yourself how likely it is to still hold.
Refreshing a guide to match new software is maintenance. Fixing something we got wrong is a correction, and it is treated differently — visibly, with a note explaining what changed. That distinction is set out in the Corrections Policy.
What this process cannot do
We would rather be straight about the limits.
We do not have every device, every regional variant, or every paid tier. Interfaces change without notice and some of our screenshots will be stale before we notice. We are a small team, which means depth on the subjects we cover and silence on the ones we do not.
What we can promise is that the difference between "we tested this" and "this is what the documentation says" will always be stated, not blurred. If you find a case where it was not, that is a defect — report it through the Contact page.