Edge cases and warnings
Include edge cases when they affect a meaningful number of users, or when the consequences are serious.
Risk matters more than frequency. A warning should be prominent even if it affects only a small minority, when ignoring it could cause data loss, security problems, irreversible changes, financial consequences or service disruption. Never bury high-risk information inside general explanatory text.
Troubleshooting
Troubleshooting should usually stay close to the task it supports. A short section at the end of a relevant guide saves the user unnecessary navigation. Create dedicated troubleshooting documentation when the section becomes disproportionately large, the same problem affects several workflows, users are likely to search for the issue independently, or keeping it in place makes the guide harder to scan.
Document specific error messages when they are common, important or likely to block users. Do not attempt to catalogue every possible failure.
Screenshots
A screenshot should earn its place. Keep it when it helps locate a control, clarifies a complex interface, confirms the expected result, prevents ambiguity or improves orientation. Remove it when it merely repeats obvious text.
Show enough of the interface to provide context. Sometimes that means a tight crop, sometimes the surrounding interface is necessary. If a screenshot no longer matches the current interface, update or remove it: even small discrepancies make users question whether they are following the right documentation.
