The first is that one way to document is to strive to make as little as possible worth documenting. What do I mean by that? Well suppose you write a script, and it has a bunch of dependencies. What is good is if you can make it have as few installation dependencies as possible, and make those as clear as possible. Then you don't have very much to document about how to install it!

The second is to consider ways of combining user documentation and specs. An extreme is the approach that Microsoft has been known to take, of actually writing the user documentation as a spec. Somewhat less extreme is the approach of writing down "use cases" for a spec (this is advocated by extreme programming, among other schools). When you have done that, the use cases are extremely suggestive about what to put into the user documentation.