Technical writing · manuals and documentation
Independent technical writer
Yekaterina Pashkovskaya writes operating and maintenance manuals, installation and commissioning instructions, work procedures and software documentation. Every job starts with a written scope note — who reads the document, what it has to let them do, and where it stops — and ends with editable source files you can revise yourself without coming back.
From drawings, notes and half an hour with the people who run the thing, through a structure agreed before any prose, to a numbered document with its illustrations and the source files that let you reissue it next year.
Four kinds of document make up most of the work. They share a method: find out what the reader has to be able to do, then write only what gets them there.
Start-up, normal running, shutdown, the service intervals and what to check at each one, fault tables with the symptom first, and a parts list that matches the diagram beside it. Written from the equipment, the drawings and half an hour with whoever actually runs it.
What must be in place before the first bolt, the order the steps happen in, the checks that confirm each one, and the warnings placed where the risk is — not collected on a page at the front that nobody reads twice.
The written version of what an experienced person does without thinking, so that a new one gets the same result. One action per line, the decision points marked, and a form at the end that records what was actually done.
Getting-started pages that work on a clean machine, configuration written as a reference rather than a story, endpoint and parameter tables kept next to the code they describe, and release notes that say what changed and what a reader has to do about it.
Five steps, the same for a two-page procedure and for a full manual. The structure is signed off before a paragraph of prose is written, because that is the part that is expensive to change later.
Who reads this, what they must be able to do when they put it down, which languages and formats it has to survive in, and what is deliberately out of scope. One page, and there is no charge for it.
Drawings, parts lists, screenshots, earlier versions, the standards the document must follow, and time with the people who build, run or support the thing. Gaps are listed rather than filled in with guesses.
The table of contents, the numbering scheme and one sample section go back to you before anything else is written. Reordering a manual at this stage costs an hour; after the draft it costs a week.
The full draft goes to the people who know the equipment. Every comment is answered in writing — accepted, or explained — so nothing quietly disappears between one version and the next.
You get the finished document, the editable source, the illustrations as separate files and a short style sheet. Everything needed to reissue it next year without asking anyone.
A manual that cannot be updated is a manual that goes out of date on the day it is delivered. These come as standard, not as extras.
The working files come with the finished document, in a format you already have. Nothing is locked, and there is no tool you have to licence to open your own text.
Sections, figures and tables are numbered so that inserting one in the middle does not renumber every cross-reference behind it. Revisions are dated and listed on one page.
Line drawings and diagrams are drawn and handed over on their own, so a part can be redrawn without rebuilding the page it sits on.
One name per thing, agreed with you and written down, so the panel is not a console on page 12 and a display on page 40.
Text is written to be translated: short sentences, no idiom, no text baked into the pictures. The translation itself is somebody else's job, and that is said plainly.
The rules the document was written to — headings, warnings, units, how steps are phrased — so the next person who edits it does not pull it out of shape.
If what you need to know is not here, write it on the request page and it will be answered in writing.
Often, yes, and it is usually cheaper. The existing document is read against the equipment first; the scope note then says which parts are sound, which need rewriting and which should simply be deleted.
It makes the document better and it is not always possible. Where there is no access, the gaps are listed and the draft is marked at every point where an assumption was made, so a reviewer knows exactly what to check.
Yes, with the structure fixed early and the volatile sections written last. What is not possible is a fixed scope note against a moving specification, and the note says which parts are provisional.
You do, together with the source files and the drawings made for it. Nothing written for one client is reused in another document, and nothing is published here as a sample without permission.
Describe what it covers, who will read it and when it is needed. A written scope note comes back, and nothing is started until you have agreed to it.