At the end of the day, it comes down to identifying what kind of audience is reading.
The ideal (and hard) way to go about docs is to be redundant/verbose/overcommunicative to target different audiences with different forms of writing.
The paretto approach is to laser focus on the one type of docs that help the most. My super dumb heuristic for this is just looking at question frequency in chat and offering the FAQ that would've answered the question.
What I sometimes try to do is link from an FAQ to a more elaborate section if there's rationales to be explained. Then the skimmer can quickly copy-paste, and the digger can go optionally read more in-depth content.
Our docs are also loosely structured by order-of-learning (e.g. "what is X", "here's pages about the most important components of X" and how they typically tie together, each page with their own FAQs, and then finally an API reference)
For mithril.js[1], I have intro ("tell me what this is and why should I care"), tutorial ("going from zero to hero"), guides ("how to setup specific things"), API reference ("what methods exist"). There's also a glossary ("what does the lingo mean") and a cheatsheet ("just let me copy and paste").
Do you have a set of questions you ask yourself when writing, to check it will be useful and usable by users?