Heavier methodologies produce voluminous design artifacts: diagrams, documents, and so on.  These are "passed on to the developers", placed on shelves, referred to too rarely, updated even more rarely.

In ExtremeProgramming, the design and development roles are merged: the designers are the developers.  ExtremeProgramming believes that the most important embodiment of the design is the code: TheSourceCodeIsTheDesign. Accordingly, the source code is written to express the design clearly and well. No other design artifact is required by the ExtremeProgramming methodology, though some projects may add artifacts based upon special need.

LiterateProgramming may be used to describe core areas of the system and how they work.  (C3 did some of this, and while it was fun, it didn't help us. So we stopped.)

UML or similar diagrams might capture essential relationships between objects. These would be more for publication to the literature, or perhaps to express a few key objects to customers.  

User documents might describe the flow of the system, or the essential concepts behind the GUI.

In general, the XP way is to replace written communication with face-to-face conversation. Where this is possible, it is more effective in every way. Where it is not possible, XP will produce as many documents as necessary, and as few as possible.

--RonJeffries