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.
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.