I generally agree. This is why I think the home construction analogy for software might do more harm than it does good. If you go with the building construction analogy then the UX is just as much the architecture as it is the paint, floorings, materials etc. Even in the housing market, the same building plan does not work for your entire market.

It depends on if you're developing software that is more of a tool addressing a well understood and pervasive problem, as opposed to a service or solution where you're trying to adapt to the varying needs of a broader market.

If you build like a house you might have plans that meet the needs of a few customers but you're going to have to re-design the house for the next set of customers. Software is generally more of a continuously developed service that needs to adapt as problems, jobs and markets change -- houses don't have to do this.

But I agree, "UX" first can work if it's iterated in small cycles continuously and the technical knowledge is involved in understanding the jobs and problems rather than the requirements and specifications.

Plus the purpose of a house generally does not change much. If you buy one, you're not going to turn it into a bar one year, then turn it into a candle shop the next. The requirements usually stay the same.

Some business apps do need to change every year. There's not any common sense for this situation (like house building) because you'd need to predict the future.

>UX first can work if it's iterated in small cycles continuously

Absolutely agreed, what I've generally seen is that the first iterations are there to get the UX grammar down with non-technical users. Then they can see what they like and don't like and their requirements become more coherent.

I agree with just about everything you said here, (never read the book, so no opinion upon that). I would add that UX-first _can be_ the start of the conversation in a larger context.

Yes there are things that can't be done without a thorough review by an architect. But some things can be worked around without drastically affecting the UX, and that context can help an architect find places to hide the slow parts and inconsistencies.

I agree with the underlying drive of this article. The user experience is the most important part of what's being built. Where this article goes wrong is in assuming the UX is solely defined by the designers. The architecture is just as much ux as the visual / motion / interactive design.

The design isn't finished the day a system architect shows up to review it. It's just gotten started.

> I would add that UX-first _can be_ the start of the conversation in a larger context.

As a backend engineer who took a job where I also have to do frontend work, it took me a good six months to learn what you just summed up.

A good UX design really helps to highlight the context that the user is presented with, and it's much easier to iterate over and find gaps before having a hefty backend in place.

You can show a frontend design to your team, have them go over it and find edge cases you haven't considered, show it a manager to get early feedback, and then have confidence going into the backend work that you know the scope of what needs to be done.

Isn't this what he's advocating for when he expresses the need to approach work "UX first" even when it comes to story and epic-level work?

I believe you should start by gathering considering initial requirements, of which "UX requirements" is a subset. Trying to create a hierarchy or priority of requirements, to be defined in phases, is repeating the error of "waterfall" or "assembly line" thinking for software projects.

You do the UX first then its a fight with reality during development to try to get as close as possible to the UX ideal.