I've been writing technical documents since the early 1970s.
You can't expect one piece of documentation to serve everyone ... it's like buying a "vehicle" and trying to use it to race, haul hogs, and climb Pikes Peak.
A - Ordinary users don't give a shit how the stuff works, they want it to do something for them ... tell them how to make whatever it is work as a tool for them. Run through the common use cases, screen by screen, showing them how to make the widget-smasher do it's thing.
Start with things the way they should work, then give them some basic troubleshooting, maintenance, etc.
B - Administrative users: They need all of "A", and how to handle the other users. Add, remove and monitor users.
Start with things the way they should work, then give them some basic troubleshooting, maintenance, etc. for the added functions.
C- Service techs, sysadmins, and those who will touch the sacred code: All of A and B (be reference to the appropriat4e manual or section thereof) and then feel free to pile on the technocrapobabble.
Each detailed explanation should start with a very brief "statement of purpose" ... when will this command be needed, or what does the bit of machine do. Why would you use it?
Then explain how to use it, and the expected results if you used it right, the expected results if you screwed up, and how to recover from an error.
You need to explain for each level of user what happens to a transaction, or data, or a part being manufactured, as it passes through the process or the proigram ... chronologically, what touches it and what is supposed to happen?
What will you see if there is a failure?
How do you recover from the failure?
It's not difficult, you just have to make sure that each level of user can get their task done efficiently.