With this approach, I
- sketch out the most important use cases,
- combine them into the index of a tutorial (links plus teasers summarizing the use-case),
- flesh out the tutorial topics (and thus use-cases) one by one,
- develop the use-case tests in parallel to each topic,
- cite the important parts of the tests as actual code samples into the topic, and
- only then start doing the implementation (this last step is accompanied by more tests, which are now more like unit-tests).
TDD already helps to make you focus on the user during API design. DDD takes the effect further by making you tell consistent and convincing stories for each important use-case to your users. This uncovers things like
- inconsistent or poor naming: its easy to live with a poor name in a test - but hard to explain it,
- overly complex design: you, the designer, have the design fully present in your mind, it often does not really seem complex when you write the tests - but try writing down all the details of why it is how it is: it will quickly make you wish it was simpler - and remember: your story should be convincing,
- the need for simplified APIs atop more complex and powerful lower-level APIs: if you have to explain the same setup code over and over again, you'll see the need for a simplified API for typical setups, and
- feature creep: features and options you don't really need, but thought you might just add quickly, become more expensive because every feature now incurs the full cost of documentation, test, design and implementation.
(See RSpec and BDD - something crucial missing? for more of my thoughts on this.)