Re:UX, Then Architecture, Then Tools
by phailhaus on Thursday December 03, 2020 @12:49PM
(#25291930)
> 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.
That sounds more like UI; I don't think this is what the author means by UX. Whether you have 8 or 10 spaces makes no impact on the architecture, but deciding that users should be able to change video quality does. If you try to decide on an architecture first, you will often constrain the UX of your product. If you don't realize that your product needs X feature, but your architecture doesn't support X, you're screwed.
I think you’re conflating UX with UI, which is usually the cause of confusion in these discussions.
What you’re advocating for - solving the problem - is the essence of UX design. Visual design is only part of the design process that comes after user research, information architecture and interaction design.
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.