One of the tasks that people in our wacky profession seem to wind up doing is writing or rewriting error messages and text in an application’s user interface. Not that I’m complaining — it’s a job that needs to be done, and why not get the right people to do it right?
Doing that sounds simple. Often, it isn’t. There are times when it’s not immediately obvious what that text should be. And, at least in my experience, technical communicators get put on the spot to come up with something during a meeting or while chatting with developers and QA.
In a situation like that, you can’t always come up with clear and concise text on demand. But often, you need to come up with something. And quickly.
The easiest way that I’ve found to do this is to brainstorm ideas on my own. It’s a very effective technique, and I can usually come up with something that’s better than just usable very quickly.
A while back, I attended a very interesting seminar given by a 
Aaron and I advocate minimalism in documentation. Our definition of minimalism differs slightly from how some people may define the term, and we take some heat for it. But no matter how you define it, the aim of minimalist doucmentation is always the same. To give user the information they need in the most concise, readable, and accessible way.
Lately, I’ve been chatting a bit with a some people who use 
Lately, I’ve been thinking about what makes an caution or warning in a piece of documentation effective. While thinking about it the other day, I recalled what was probably the most effective warning I’d ever seen.
Radio and documentation. It sounds like a strange, if not incompatible, mix. But if you think about it for a moment, the parallels are staring you right in the face.