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:
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.
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.
I 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 different areas and how to make them.
In that sense I completely agree - starting with anything else is just going to impose restrictions and limitations that are likely to go against what you want to acheive.
This. A lot of people seem to be missing the forest for the trees. General point I took away was if you're starting on a new project and you're thinking about which tools (language, framework, db, etc) to use before you've taken time to understand the problem and articulate a solution (UX), you're not really setting yourself up for success. That seems pretty reasonable to me.
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.
I agree with this, but also I draw a different conclusion:
tools, tools, tools
I will implement the UX my smart colleagues from the Design Thinking group come up with. I bring the tools and the tech and the architecture to do that. Quickly. And if the UX changes after the first user test, my architecture, tools and modular code will easily accommodate the new UX.
I'd argue that UX and Architecture ought to be done in parallel with a decent amount of cross-feedback. I've seen this done with a big 1-2 day kick-off meeting with everything present at the start of the project. But I think the key thing is that design, development, and product don't work in isolation.
I've had good experience doing UX first when your team is writing the whole stack. It's much easier to establish the scope of a project when you map out the user's context first; the whole team then has a good idea of what needs to be accomplished. If it's done in isolation though, there in lies the path to madness =)
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.
> 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.
I 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.
Or a more generalized take from Carol Sandford's regenerative business paradigm -- "external considering". It's not just UX. We can build UXs that are useful for the end user, or we can build UXs that sucks up attention for the benefit of monetization, producing significantly detrimental second-order effects to society. It's more than figuring out what the customer needs.
Each end user is a part of their own community, and they use these devices and apps as a service within their own community. There's a way to figure out how to help that end-user do that. It won't always even be a high tech solution all the time. It could be changes in operations, logistics, perhaps financing.
Instead of market lockin or monopoly power, what you get is non-displacability. That is, that end user and those communities those users are a part of don't want to get rid of your business, and your business forms a vital part of the health, well-being, and prosperity of that community.
I’m a fan of user centric design, whether it’s domain driven design or a UX practice. I’m a Technology person too.
One thing that is dangerous about the above is from a top down perspective, UX folks don’t always know the possibilities and capabilities of tech (or feel they don’t need to) which can hinder the design.
As well, UX doesn’t always know how users prefer to work with the data for anything beyond mild and simple use cases. Results in a lack of depth, or too much depth.
It’s far more reasonable for creators (tech), designers and UX to be at the table from the start instead of any one group trying to abstract away the other in some sort of hierarchical or structural land grab.
If this doesn’t seem realistic, imagine if tech folks can learn to work with any type of detail easier than design folks can learn to code. The power will converge in developers who can design, and designers who can develop,
I'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.
I disagree with this. You have to explore the architecture first to see if the UX is technically possible. Once you know it’s possible, then you know the canvas you can paint on.
I can say with more than a little bit of experience that the 'tools' never get written properly, as budget is is now blown, and the project timeframe is over-run.
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.
I disagree. Every product has a user, whether that product is in your web browser or a command line script. The way your user interacts with your product is its interface. I believe the author is suggesting that you must understand that interface first before you go off designing architecture.
If you are a security researcher designing a virus scanning algorithm, you need to understand how your users will interact with your scanner. Can they pause and resume? Can they tune the parameters of your scanner? Which parameters? etc. The way you answer these questions will invariably affect the architecture in some way.
No, it's a narrow mentality of what a product is. If you are writing code, that code interacts with humans in some way. It might not be a consumer or even B2B product, it might be strictly an embedded library that interacts with nothing except other code, but even that should be designed to meet the needs of the other programmers who have to interact with it.
A lot of programmers want to be handed concrete requirements so they can focus solely on implementation, but in practice this leads to gaps. A programmer who thinks beyond their immediate scope to the end-to-end context and human players involved where their code is executed will deliver far more value and avoid so many common disasters that happen when non-technical people are solely responsible for requirements.
I am handed several terrabytes of data and is asked to find the needle in the haystack.
You tell me, that I should be concerned about the UX of the scripts I develop to go through all the data and hand me the result I will answer back with?
I would say that I should just solve the problem, answer with the needle, and get on with my life.
My 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.
There really is no correct answer here. If you start with a database design, will you have a bad product? No answer can be given because there is so much other variables.
UX first sounds great when you don't have to integrate your new application into a monolith where jQuery spaghetti and table-based HTML are spread like a disease.
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.
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_Synt...