This is why I personally like to do documentation, then coding, then unit testing. But my unit tests are written to the docs, not the code.

That is, or should be, a different set of docs. Design documents make lousy user documentation.

Conversely, I like to start with the (or at least a) application that will use the library I'm going to write.

I define the library interface in terms of the functions/methods that the application needs to fit its structure and use of the library. Those calls can then be mocked up to allow the application to be written and (functionally) tested. In a simplified form if necessary.

Once the api is defined and shown to satisfy the requirements of the application; it becomes much simpler to write a library to fit that api. (And *just* that api.)

The (simplified) application then also serves as both a test harness for the api; and as example code for user documentation.