Be as direct and specific as possible, without assuming too many concepts. If possible, go beyond instructions and actually provide a link or a button that does the action. If it's a severe problem for example, the Web site is undergoing maintenance or is overloaded provide some mechanism for the user to report the problem to you, so you at least have a record of how many people suffered the problem and can use that in planning for the next release. If you write solid code, and build robust support for error handling, the most common or severe errors are never even encountered by the user. This can be achieved by automating parts of the user interaction, intelligently offering alternatives to common mistakes users make, or by refining the UI to reduce the frequency with which users get into certain error-prone situations.
Great engineers forgo the error messages, and just solve the problems directly.
It's often impossible to do this for all cases, but if you have information from your support team for the top ten most common errors, you can invest your time there. I'm starting a collection of bad error experiences on the Web. If I receive good suggestions, I'll post them on the site and make some noise to the responsible parties. And, yes, it's okay to submit bad error messages from Microsoft Web sites. Remember, I don't work directly for any Microsoft product or Web site, so don't blame me for them.