You describe your development approach as a "top-down-only" process - you start from a higher abstraction level and go more and more into the details. TDD, at least in the form as it is popular, is a "bottom-up" technique. And for someone who is working mostly "top-down" it can be indeed very unusal to work "bottom-up".

So, how can you bring more "TDD" into your development process? First, I assume your actual development process is not always so "top-down" as you described it above. After step 2, you will probably have identified some components which are independent from other components. Sometimes you decide to implement those components first. The details of the public API of those components probably does not follow your requirements alone, the details also follow your design decisions. This is the point where you can start with TDD: imagine how you are going to use the component, and how you actually will use the API. And when you start coding such an API usage in form of a test, you just started with TDD.

Second, you can do TDD even when you are going to code more "top-down", starting with components which are dependent on other, non-existing components first. What you have to learn is how to "mock out" these other dependencies first. That will allow you to create and test high-level components before going to the lower-level components. A very detailed example on doing TDD in a top-down-manner can be found in this blog post of Ralf Westphal.

You describe your development approach as a "top-down-only" process - you start from a higher abstraction level and go more and more into the details. TDD, at least in the form as it is popular, is a "bottom-up" technique. And for someone who is working mostly "top-down" it can be indeed very unusal to work "bottom-up".

So, how can you bring more "TDD" into your development process? First, I assume your actual development process is not always so "top-down" as you described it above. After step 2, you will probably have identified some components which are independent from other components. Sometimes you decide to implement those components first. The details of the public API of those components probably does not follow your requirements alone, the details also follow your design decisions. This is the point where you can start with TDD: imagine how you are going to use the component, and how you actually will use the API. And when you start coding such an API usage in form of a test, you just started with TDD.

Second, you can do TDD even when you are going to code more "top-down", starting with components which are dependent on other, non-existing components first. What you have to learn is how to "mock out" these other dependencies first. That will allow you to create and test high-level components before going to the lower-level components. A very detailed example on doing TDD in a top-down-manner can be found in this blog post of Ralf Westphal.