There are a lot of products build as a business function that are successful without putting focus on UX initially. Product Design is about balance, you cannot design without quantitive analysis of available technology and put your eggs in one basket. For me this is somewhat naive. Article lacks specific use cases and house analogy is bad example in my view.
Disclaimer: I am designer.
UX, Then Architecture, Then Tools
31–40 of 41 posts
Re: UX, Then Architecture, Then Tools
#32UX and UI, while related in some cases are two distinct things. UX = User experience UI = User interface In my opinion, UX should be used to drive the UI, backend & architecture.
Good UI can only positively effect backend and architecture, largely because it forces a good cognitive model and thus relationships between entities. A "Good" UX can have a disastrous effect on backend and architecture. It may put undue focus on glitz and cost the performance or reliability of the application greatly. Those LEAD to a bad UX, but that's typically not in the UX focus up front. Most probably think it's an obvious default, but unless focus is put there, it doesn't come for free. Zero-sum game, paying the glitz tax will cause a debt somewhere else.
Re: UX, Then Architecture, Then Tools
#33I think some of the comments so far here and in the artice might be missing the point - not helped by the use of word UX or the common interpreation as meaning UI. I think the author is advocating that you start with understanding the expectations of the product, what should the user be able to do, what do they need to do, what does the market expect. From that you then work out what tradeoffs need to be made in diff…
Thank you. I agree. People are equating “UX first” with “do the user interface first”. Every interaction your user has with your system is an experience. It should be considered and DESIGNED. That doesn’t mean creating a bunch of screens in isolation. It does mean understanding what users are trying to do and what’s motivating them to do that thing.
Re: UX, Then Architecture, Then Tools
#34My experience is that the best approach to solving a problem is that you need to do a little of everything, with the emphasis on little. But first you have to understand the problem.
Re: UX, Then Architecture, Then Tools
#35I'm wondering if the comments in this would be the same if it said '/users/ first, then architecture, then tools'. Or even 'purpose, approach, technique'.
When I read it I wasn't taking it as instruction about the chronically ordering but more a principle above the primacy of factors - what drives the process. I can see good projects iterate through them together but I feel I've had better results when a clear articulation of the user needs provide the momentum.
Re: UX, Then Architecture, Then Tools
#36I believe the author is attempting to say 'start with the problem not the solution'.
Another name for UX is Service Design, which if that term was used might have made it clearer what the intent of the article is.
The issues of starting with solutions are well documented and understood in IT (law of the instrument), but despite that are often not avoided. I'd go so far as to say almost never.
Focusing on the problem, exploring and defining it well, being clear on user needs and then considering possibilities and constraints, moving to testing and validating/experimenting quickly before sinking too much money and time into whatever random solution 'technology' wants to throw at it has so many benefits.
Getting that right and spending some time on it generally pays off for everyone, users, sponsors and those working on the technical side of delivery as they are working on more valuable and better appreciated pieces of work. It is quite often the case that the resulting technical work is more interesting and enjoyable to work on too as the eventual solution you work on is more novel than building out the bulk standard solution that would have been the default proposal.
Re: UX, Then Architecture, Then Tools
#37I'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…
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.
Re: UX, Then Architecture, Then Tools
#38Retort: A UX-first project would easily fly over budget.
Re: UX, Then Architecture, Then Tools
#39This 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 busin…
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.
Re: UX, Then Architecture, Then Tools
#40I'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…
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.