> o need to pay some UI designers big bucks to come up with rounded corners).
It’s really unfortunate how dismissive of the entire ui design profession so much of HN is. Not a great look IMO
It’s really unfortunate how dismissive of the entire ui design profession so much of HN is. Not a great look IMO
Because you cannot legitimately look at the W11 task manager and tell me it was designed with any sort of professional UI/UX in mind. It's busy work to keep a job. And if it is then there's something deeply wrong where no UX theory is being applied, or they're being overruled to make it "app-y".
I don't understand
Bravo, Microsoft.
But these people are not rewarded in today's industry. The criteria for good UI design these days is all about "lOoKs mOdErN". Plus the field seems increasingly tied to HTML/CSS/JS. Development teams as a whole are not incentivized to do UI design with an emphasis on making the user's work easier... they're incentivized by engagement KPIs and the like. So there's a trendline towards more sizzle and less steak.
Why would you not dismiss a profession that actively makes your life worse?
I'm fond of saying UIs designed by engineers look exactly like UIs designed by engineers. I'm not saying that all designers are always better than all programmers, but when you've studied visual composition, it shows.
I mean just look at the scorching replies you are getting. You definitely offended some people who fall into this "I know better than any stoopid artist" category.
The job of a UI designer is to make the UI usable. Looking pretty in screenshots must always be a lower priority than being functional and accessible.
Usability--what you are describing--is the UX or user experience, buttons colors composition affordance is the UI, connecting the buttons to the REST endpoints is frontend, servicing the REST endpoints is backend, making sure the backend is running and so is the gateway is devops. At least that's what it has been for 20+ years.
> Usability--what you are describing--is the UX or user experience, buttons colors composition affordance is the UI,
Considering these to be separate disciplines is just more of the same madness. They're inextricable.
> At least that's what it has been for 20+ years.
I think it's more that over the past 15-20 years there's been a growing trend of people forgetting that "look and feel" doesn't just mean "look".
Not if you've actually done both. ;-)
Here's an example:
UX would be: on beginning a customer purchase, do we use a funnel pattern (isolating the purchase experience from the layout template), or is there backout that allows the user back to the store instead of back through the path.
UI would be: how do we design the checkout template, what colors and fonts from the corporate palette do we use where
Totally unrelated.
Make sense?
You cannot decide whether a small piece of what you call "UI" is good without considering its place within the larger context that you call "UX". A dialog box that is very pretty, fits well with the overall aesthetics of the application and the platform/OS, and properly does what it says it does—would still be an example of bad UI if it's one of those dialog boxes that shouldn't exist in the first place and is a product of the developers/designers fundamentally misunderstanding the workflow or goals of their users.
This distinction you're trying to make is really not productive. Its too vague and subjective about where to draw the line, and I'm pretty sure most people who are adamant that a line must be drawn are people who will subsequently neglect things on one side of the line as "somebody else's problem".
Here's another example: user focus. When an important event occurs, should the user not be able to continue a task and be stopped until a decision is made, or should they continue to work and have the error as a notification? At what point in the experience is the user flow of execution halted for input? This is UX because it doesn't care about the UI. UI is after the UX decision and whether you implement it with a popup, or an alternate screen that overlays, or even a CLI prompt in the case when it is not a graphical UI. Maybe a good way for you to conceptually separate them is to think about the behavior and forget whether you are using a GUI or a CLI to implement it.
I can see this is pointless because clearly you have no experience with either in a professional context. I feel like you're just trying to "win" here and not really listening.
Don't be an ass.
You seem to have finally elucidated a meaningful, unambiguous distinction between UI and UX as you see it: UX is purely abstract, can be described with nothing more than flowcharts and probably is concerned with what kind of mental model the user forms for how the application works behind the scenes, while UI is any concrete realization of an interface; any discussion of a real on-screen layout of information and controls would fall under UI rather than UX.
I can see how that distinction could be useful in a more or less academic way. Unfortunately, even using your definitions there are a lot of usability concerns to UI, as I originally claimed but you took exception to. Bad UI layouts can lead to objectively, measurably worse usability (eg. number of clicks required, hard-to-hit targets, etc). Those problems are real: you cannot assess usability in your purely abstract "UX" context and then completely set aside usability concerns in favor of aesthetics when you start drawing a real UI. You have to constantly keep usability in mind throughout the entire design process, even when fine-tuning your final UI layout.
(Your definitions of UX vs UI would also seem to lead to "UX Designer" being a job title in the same vein as the kind of "software architects" who don't contribute at all to writing, reviewing or testing the actual code.)
But the terms have different meanings.
UX would be "what drawer will the utensils be within the kitchen? Usually close to the microwave/stove/fridge."
UI would be "Does this drawer need handles or can you open it from the bottom?"
If the new design was adequate, it would probably be adopted in a release or two. If it were better, there would be demand to get it to all the well used components. There might still be some components left behind, there's a lot of components.
A truly inspiring design might pull everything forward automatically... But that's asking a lot.
My favorite example is VS Code vs Rider.
VS code looks like a toy. A big stack of unlabeled vage icons that require a decade of context to intuit. Compiling your program takes three clicks and a context switch away from your code! Unless you're a normal person who hasn't memorized those icons, and then it's six or seven clicks while you fumble through the menus.
Rider is a classic ugly UI. everything has labels or tooltips. There's a goddamn toolbar with all your common controls. Building your code requires one single click.
Not a single person is going to stare at your landing page like it's a genuine Picasso. Your ui is not going to be placed in the museum of modern art.
A UI is a tool. If someone has to ask you how to use it, it's not very good. If your users are fumbling through menus after the first hour, it's a bad design. If a user has to have the documentation open at all times to decode your hieroglyphic icons, it's a bad design.
As for my own UI design, the core philosophy is first-order accessibility. If you have to do a task every time you open the program, then that task is accessible with one or zero clicks. If a user asks me what a button does, it gets a better label or a helpful tooltip as well as a mention in the docs. My UIs look like something out of windows 95: simple controls laid out in a grid in clearly delineated functional groups. Everything is labeled and laid out in a way that places the most common controls in VERY OBVIOUS and CONVENIENT locations. It's ugly because it's designed to be used and not looked at.
If a user spends time in my program that isn't related to the task they're doing, I've done something wrong. If someone has to ask me how to do something, it means I have to rethink my design. If users are relying on documentation to navigate my program, I need to redesign.
I respect ui designers who build helpful and useful UIs. I don't respect designers who drop all text and sprinkle a dozen abstract images on a vast barren wasteland of screen space.
ETA: I'm an engineer and I build engineer style UIs: brutal in their simplicity, and utilitarian above all else. Literally not one person who will ever use my programs will care that it's ugly so long as it works.
At some point we've lost the idea that programs should be useful more than they are "pretty". It's a trend that I find frankly abhorrent, and I believe it's one of the major factors that's making software as an entire field worse and not better.