Acceptance and integration tests tell you whether your code is working and complete; unit tests tell you where it’s failing.
If you’ve done a good job with acceptance and integration tests, and they’re passing, your code is implementing all the functionality it’s supposed to, and it’s working. That’s great to know (it’s also great to know that it isn’t). But if it isn’t working, an acceptance test won’t give you much insight into what has gone wrong; since it tests many units of functionality, it can be kind of a bird’s-eye view of failure. This is where unit tests shine. Good unit tests tell you exactly what went wrong, with exactly what part of your code. It’s harder to know whether you’ve written enough unit tests than acceptance tests, but when you have a failing acceptance test without a corresponding failing unit test – it’s time to write that unit test.
That is all from the testing perspective. And, of course, TDD isn’t (and ATDD isn’t) about testing. With respect to driving your design, acceptance tests give you a broad roadmap (“here’s where you want to go”) while unit tests take you to the next intersection (“turn left”). They’re both valuable in this regard and, again, their value complement one another.
Don’t confuse them; don’t miscegenate them. Unit tests, in particular, shouldn’t depend on anything else, and it would be a mistake to constrain your unit tests by making acceptance test dependent on them. Of course they can share some framework code, but they should be independent.