This is the right vision, but misses by a wide margin:

First, define the problem you are trying to solve. Then define the solution to that problem. Then lay out the broad strokes of the architecture and build a skeleton of a POC that proves the system will work.... and then figure out the UX and continue down the path from the article.

I've seen UX-first turn into churn of minutiae, without actually solving the business problems. Whole teams moving icons around for months and bikeshedding over whether they wanted 8 or 10 spaces between labels and fields, and still no functioning app.

UX-second - that works. Solve the problem first.