Write your acceptance test
See it fail so you know what the next step is
Write a unit test for that next step
See it fail so you know what the implementation needs to be
Repeat steps 3 and 4 until you have everything you need, and all your tests (including the acceptance one) are passing
Rinse and repeat for every new feature.
When doing TDD, you work inwards from the interface to the implementation. You start by writing a test case against the interface you wish you had, and then you make that test case work. This is a subtle shift in how you approach a design problem, but it frequently results in beautiful APIs. (And you also get a fully automated test suite for your software, liberating you to make much larger changes without fear of breaking things.)