5 ms·

I've seen "UX first" gone terribly bad, because when designing the UX in a vacuum it's easy to glance over a lot of requirements imposed by the domain. E.g.: i

I've seen "UX first" gone terribly bad, because when designing the UX in a vacuum it's easy to glance over a lot of requirements imposed by the domain. E.g.: it's common for UX designers to expect any action in the app to be synchronous, which is often an impossibility (not just technical but from a business domain perspective), leading to UIs that pretend things already happened and puzzling users when it turns out the action failed or took longer than expected; refusing to be transparent and writing sentences like "We've received your order and will notify when ready" in the UI and working w/ push notifications. For "UX first" to work, you actually need everybody w/ domain and technical knowledge involved, but that rarely happens. > This Does Not Mean “Waterfall” If you're not going back to adapt the UX to all requirements, it is. Any project that is phased like that instead of considering all requirements together is waterfall. I recommend this book as a framework to run projects holistically, gathering requirements and executing against them in a way that finds the best fit: https://www.goodreads.com/book/show/320553.Notes_on_the_Synthesis_of_Form https://www.goodreads.com/book/show/320553.Notes_on_the_Synt...

enobrev 6y ago
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.
- craftinator 6y ago
  > 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.
Mertax 6y ago
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.
- vsareto 6y ago
  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.
spandrew 6y ago
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?
- hcarvalhoalves 6y ago
  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.
bni 6y ago
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.

enobrev 6y ago

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.

craftinator 6y ago
> 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.

Mertax 6y ago

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.

vsareto 6y ago
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.

spandrew 6y ago

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?

hcarvalhoalves 6y ago
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.

bni 6y ago

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.