If you can get your service boundaries and APIs fully defined and correct, then the relational database models (underpinning each of those services) just fall from the tree for you.
And then as you say the screens and elements are obvious.
I find if you start at the database model layer you much less likely to screw up the API design. The database model forces a bit of rigor that you can't get going the other direction.
But if you're building a system which is not a monolith, and instead is made of up of, say, 20 services, then putting good boxes around those services and defining the lines that connect them (the APIs) is an essential prereq to designing the databases that sit inside the boxes.
(Though really what's happening, as always, is you're doing it all in parallel, just with more emphasis on the higher level stuff).
To quote Mr Torvalds himself:
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
Something that i struggled with before i learned how to use a SQL/relational database was to actualy use the database relations in my code. I first specified the relations in the database then i basicly redid them in the code.
The way i tend to program these days is to have basically all my relations restrictions and relational rules in the database. Whenever i want to change something you just alter stuff in the database GUI. Most of the application code will just follow along.