I have one philosophy going - try not to be the expert of the program - instead, let the domain experts tell you what they know. This way, you can remove yourself from all the noisy data and the intricacies of certain ways of doing things. What I try to find most of all, is to ask the right question to compel a better response to find the answer.
Of course, easier said than done. To NOT become the expert requires almost complete removal of yourself and the ego some designers or usability practitioners might have. I heard of one definition of what certain politicians are suppose to do - represent their constituents - namely, our users.
So in that case, remain objective in no matter what you do. Most of all, embrace uncertainty because even though I might have to learn or become familiar about a certain program, all I really need to do is learn enough to understand the why's and the how's and the sequence that they come in so that even the sequence or its fundamentals can be shifted to improve productivity.
I'm finding that the experts that give me the data can sometimes be too much - so I read between some lines and find the fundamentals, something the novice user can understand. Because let's face it, the experts and the expert users aren't necessarily your everyday user - what about those coming aboard to learn the program? To dumb-down the level on conceptual understanding translated through a less complex and task-flow streamlined interface is the way to go, and I believe this eases the tension more for these expert users. They become experts for a reason - the interface is sometimes too difficult to understand, so they go about learning everything within the program so that they can explain it to someone who's a novice. Ever thought of that perspective?
If you keep it simple, in no matter what you do, you'll get the message across a lot better and people will use your programs more often with less hassles. And so, not as many "experts" develop.