Just found this interesting article on documentation in Agile projects by Scott Ambler. As with everything in the Agile world, we must strive to do just enough to meet the business objectives - this includes documentation. One point which Scott makes very well is that "Your team's primary goal is to develop software, its secondary goal is to enable your next effort."
Even when I am not working in an environment which requires a formal design phase, I often write stuff down during the design stages so I can get my head around a problem. These take the form of Design Notes, a logical UML diagram or a scribble on a whiteboard - whatever works best as a way of communicating the design to myself and the rest of the development team. In my view, the key to a good design is that each component should have a very discrete job to do (low coupling, high cohesion). I just wish I could figure out a painless way of sticking the artifacts produced during the initial design stages into a document that someone could pick up and get an understanding workings of the system.
I find presenting the design the best way of communicating, but that is probably because I enjoy talking. A document is quite often not the best form of documentation, but you sometimes cannot avoid them.
