"You did what?"
I know you won't find that tip in any book called How To Make Tons of Money Writing Boring Documents (hey, maybe that's my next book! Nah, you write it).
But in this case, that is best for the client, and for the readers of his documentation.
I did the same thing on software teams. I would explain to the god-like developer (actually some were VERY nice), "Either you can explain the software to me, and I will document it, or you can write down how it works, and I will confirm it and edit the content."
Ideally, I would get access to every user-level of the software and be trained on it, or be given time to learn and use it, plus have access to actual software users who are willing to take time to tell me/show me how they use the tool, where they get stumped, and what they'd like to see in user documentation.
Ideally, the software developer has done this before in the requirements-gathering stage, before development started.
My point is, when you help your clients help themselves, your job is easier in the end. I will receive a draft updated by the man who knows the tool inside and out (I HOPE), and I will learn the tool as I prove his instructions are accurate. Then I will polish the document in ways too complex and mysterious to explain here.
Tada! I am SO wise. Uh oh. I think I stood too close to a software developer.