I've heard it called Document Driven Design. Document how to use your API first and get feedback from that.
I always design from the outside in. How do I imagine this API and flow to work, and then how do I structure data and storage. Think of the developer experience before you think of your experience as the implementor of the API.
This is also what I do. I like UML-ish diagrams to help communicate the ideas with my cow-workers although I use it loosely, not following the formal specs or even doing it electronically, just on paper, to diagram the interactions and from there design my structures, state transitions, and message sequences.
The most serious problem I run into is keeping the documentation synchronized with the project. For everything non-trivial it seems I always get to a point where the project is so far from the docs that it's not worth going back to update. Do you discard the documentation when you've built the thing?
When I think document driven design, I think more along the lines of "api spec" or giving the interfaces/method signatures. Sometimes this goes into "boxes and arrows" stuff. For boxes and arrows, I usually don't go back and update those. But for the API spec, example usage, etc, I prefer something that is self documenting or has to be kept valid via tests. This is particularly easy in a language like Go (what I tend to work in) as you get GoDoc for free if you comment right, and you can have your examples directory run with tests.
I second this when it comes to APIs. If you're exposing them to third parties it's especially useful, as you can draft how the endpoint should look and behave using something like Swagger, and then work from the top down. At my job we have close communication with third parties who use our api endpoints, so we are constantly sending drafts of JSON requests / URLs back and forth.