Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You are exactly confusing UX and UI.

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.



> You are exactly confusing UX and UI.

> 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".


> Considering these to be separate disciplines is just more of the same madness. They're inextricable.

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?


No, it doesn't make any 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".


There is an experience to using a UI (bad colors make for a bad experience), but it is not UX. Totally different. Here's how it Don Norman makes the distinction: there is no medium to UX. That's a fairly large conceptual difference.

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.


> 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.)


I will never understand why people like you start fights in disingenuous attempts at discussion, with practically know knowledge of the topic. I guess I fell for your trolling. Well done.


> Considering these to be separate disciplines is just more of the same madness. They're inextricable.

But the terms have different meanings.


They have different nuance, at the very least. But claiming that UI design has nothing to do with usability is absurd.


You're correct. For example, if you're in someone else kitchen, trying to eat a meal and you didn't ask the house owner where the forks at so you go searching by yourself:

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?"


It sounds like you're describing more of a macro vs micro distinction, rather than a functional vs aesthetic/visual distinction. But either way, you can't cleanly separate the two responsibilities.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: