I usually champion the "let's start with the UI" state of mind in every company I go.
This has several benefits:
- it forces to confront reality of the problem and field
- you have to talk to people, and understand their needs
- you almost get your backend public API out of it for free
After that, you don't really need to do full top down, you can split in subsystems, and works on small parts of those subsystems.
It doesn't have to be a good looking or sophisticated UI. It can be a ugly, as long as it's practical and validated by the end user.
But this works only well the if the problem can be well defined and you know how to solve it.
If you need to figure it out, top down doesn't work as well.
This has several benefits:
- it forces to confront reality of the problem and field
- you have to talk to people, and understand their needs
- you almost get your backend public API out of it for free
After that, you don't really need to do full top down, you can split in subsystems, and works on small parts of those subsystems.
It doesn't have to be a good looking or sophisticated UI. It can be a ugly, as long as it's practical and validated by the end user.
But this works only well the if the problem can be well defined and you know how to solve it.
If you need to figure it out, top down doesn't work as well.