There are few corporate experiences more spiritually enriching than being asked to produce accurate technical documentation without access to the people who know how things work. It’s one of modern work’s great faith-based initiatives.
Some writers still cling to the quaint idea that documentation should be based on facts. These people are precious. They still believe “collaboration” means talking to engineers instead of receiving a vague ticket, two screenshots from a deprecated build, and a cheerful note from product saying, “This should be pretty straightforward.”
Straightforward. Ha! A marvelous word, usually deployed by someone who won’t be doing the work.
If we want to build a truly world-class documentation set without ever speaking to a subject matter expert, we must release ourselves from outdated burdens such as certainty, verification, and dignity.
Open the product and begin clicking around with confidence. Not knowledge. Confidence. If a panel opens, document the panel. If an error appears, document the happy path anyway. Users enjoy optimism.
Don’t ask what a feature is supposed to do. That only invites facts, and facts are where timelines go to die. Instead, infer the product’s business logic from button labels, breadcrumbs, and whatever happened when you clicked Save. Think of yourself as an archaeologist reconstructing a civilization from a broken spoon and a warning message.
A lesser writer might insist on current screenshots because the interface has “changed completely” and “no longer resembles the documentation.” This sort of perfectionism is why projects slip.
Old screenshots have stability. They come from a simpler time, before someone moved every important function behind an unlabeled icon shaped like a nervous hexagon. If users can’t find the button, they will at least enjoy the thrill of personal discovery.
Documentation shouldn’t rob people of adventure.
Subject mat
