Once upon a time, I wrote A LOT of email about software. http://markmail.org/search/?q=wendy+smoak (Those aren't all original messages, some of them are replies where I'm quoted, or mail generated from the issue tracker.)
Many of those messages were answers to questions. Sometimes I knew the answer when I started writing. Sometimes I only had an idea. Sometimes it was out of my league... but I knew someone else who would know.
If I know the answer off the top of my head, it's easy. Just write, and perhaps include a link to the relevant documentation. Once I've been working with something long enough, the compiler in my head can predict what the system will do with a given input.
If I'm not sure, my first course of action is generally a search (Google? Internal knowledge base?) with interesting words from the question. The last thing I want to do is spend time figuring out a problem that someone else has already solved.
Immediately, I start keeping notes. On paper, on a wiki page, in a text document. Later, if I'm looking at a code snippet that I didn't write... I want to be able to figure out where I got it from.
While I might have some ideas of what the problem might be at this point, I try to avoid speculating. Especially if I'm on site with a client, I don't want to mention something that sends them off on a tear.
Then I try to reproduce the problem. Sometimes that means clicking through a UI, sometimes that means creating a test case or an example in code. I'm after the simplest possible way to demonstrate the problem, so everything extraneous gets removed, one thing at a time. Sometimes, this process of removal will reveal where the problem is.
Even if it's one of those problems that seems impossible to reproduce, having something to poke at helps me think it through.
I might take screen shots of the UI or capture the text output in my notes.
Now with an understanding of what the problem is, I try to explain it to make sure I understand, listing my exact steps to reproduce it. No point in solving the wrong problem!
Then I set about fixing it, working around it, or otherwise getting the user to a point he can continue.
Rather than consciously brainstorming a bunch of possible options, for me this involves trying and discarding ideas in sequence, noting what I tried and what did or did not work.
And finally, I write it down.
That third option, knowing someone who knows, is an important point. After answering question after question after question, I built up enough social capital that I could call on the more senior members of the group if I got stuck. Despite not knowing the answer myself, I could catch the attention of a developer who might not otherwise be interested in answering. And they often would.
I'm a Connector. I go through life meeting people and figuring out who else I know that they should meet. And then I step back and let the magic happen.
The best part is seeing the user respond "Fixed!" or "Thanks!" and knowing I've helped.