Screenshots along with text, then use Microsoft Paint to mark up the screen shots. For example, circling the appropriate menu option in a thick red line. Sadly, I do not know how to graphically convey the double-click operation.
Its a time consuming and error prone process, best used if the buggy GUI application is abandonware. Otherwise, the new version will have the same bug or non-intuitive process but the GUI will be unrecognizable. Probably because some manager, somewhere, read too many HN articles and decided a user-facing refactor was the most important thing they could possibly do.
The usual interpretation is that scripts glue together system commands that don't otherwise incorporate one another. This is tremendously useful and is by itself a huge advantage over GUIs.
But the second sense is that vast libraries of scripts keep developers bound to their previous UI promises. You don't capriciously change command-line options without raising all kinds of ire. I've seen GNU tools (tar comes to mind) in which options have been "deprecated" for decades, yet are still available. I seem to recall a very small number of cases where options had their senses entirely inverted, to much protest, and ultimately abandonment of those tools. In other cases you've got generations of programs which support backwards-compatible options with precursors: exim and postfix with sendmail, ssh with rsh, alpine with pine, off the top of my head. Developer headspace and script compatibility are valuable.
On that note, whilst I find the *BSD's extreme conservatism annoying myself, I can appreciate that it does lead to increased consistency over time as compared with GNU userland.
Doesn't work so well for GUIs, which was sort of the original point.