Hacker News Reader

Without going into who is inherently better at design choices, the problem often seems to be with the process: UX/UI designer sits down and builds some mocks, then hands them to the developer to implement. The developer sees that the mocks as designed go against the grain of their chosen framework/platform, and they have the choice of either implementing them in a hacky way, or pushing back and finding out if they were intentional choices or merely weak preferences.

They’re almost always better off spending the time doing the latter, or even better, working with the designer during the design process to both understand which decisions the designer actually cares about as well as communicate the platform constraints/preferences to the designer.

What you're describing there isn't a problem with designers doing the design, it's a problem with bad designers doing the design. And it goes double for programmers who are bad designers overriding the actual designers and domain experts on UI matters.

> it's a problem with bad designers doing the design

No, it's not.

A designer making that mistake isn't a signal s/he is a bad designer. I've worked with UI designers who range from good to excellent when it comes to design.

Thus, my overarching point which was that UX ≠ UI

and that UX shouldn't be co-opted by UI teams.

IME, the UI/UX distinction is almost entirely artificial buzzwording anyway. People either define UX so broadly that it loses any useful meaning, or sufficiently narrowly that it's just stuff good UI people were doing long before anyone started buzzwording it.

Similarly, you seem to be using a particularly narrow definition of "designer" here, as if the only people designing web UIs come from print backgrounds and the only thing covered by "design" is aesthetics.

If you have a team where you have someone from that mostly unrelated background doing your UI design, sure, they're obviously not going to make great decisions. But even then, there's still no reason to assume your programmers will do any better, unless those programmers happen to also have genuine UI design skills (which they certainly could, but it's mostly orthogonal to their role as programmers).

UI: User Interface - the layout & visual look & feel of the page/components. UX: User Experience - the interactions of these pages/components by the user (incl. expected behaviour etc.)

> you seem to be using a particularly narrow definition of "designer" here

My definition of UI designer is somebody who designs UI (which encompasses those of print background which a lot will probably have been at some stage in the/their past)

> but it's mostly orthogonal to their role as programmers

No, it's not, unless your programmers have been relegated to code monkeys. In years gone past (pre web dominance, when native desktop applications ruled), developers were designers/user experience etc.. which lead to the checkboxes everywhere UI.

Good UI needs someone with good design aesthetic. This is where UI designers shine.

In contrast to other design fields(most notably Industrial Design, where designers have pretty much always owned (& thought about) design & interaction as a whole), that is not something which UI designers have done. It's only in recent years that I've seen UI teams claim UX in the form of renaming themselves as "UI/UX team". My point is that UX has not historically been something they've put much thought into ,and as a result, they are not qualified to just own UX.

UI: User Interface - the layout & visual look & feel of the page/components. UX: User Experience - the interactions of these pages/components by the user (incl. expected behaviour etc.)

But UI has always been about more than mere aesthetics. A UI is literally how the user interacts with the system, the interface between them. That subject has always encompassed usability and accessibility issues, information architecture, planning sequences of interactions, and so on. What you've described is exactly the illusory distinction I was talking about.

I'm not sure there's much to be gained from pursuing this line of discussion any further. Obviously you can redefine terms to suit your argument and thus make your argument true in that context, but then it doesn't really address the original point of debate, which was whether developers should be overriding designers and domain experts in matters of design. If you relegate your designers and domain experts to the equivalents of those code monkeys you mentioned while elevating your developers to developers who are also designers and domain experts, obviously the latter are going to make better calls on most UI issues as well, but then you have to ask why you had separate designers and domain experts involved at all. I don't think that's a normal distribution of skills and responsibilities within a product team, though.

> which was whether developers should be overriding designers and domain experts in matters of design

in matters of UX...

Are you perhaps thinking of the term GUI? UI is not generally narrowed to refer to only visual appearance and layout. The mouse is a UI tool, as is the keyboard.

I've pursued this definitional distinction at a previous company, and got nothing by eye rolls. In modern software design, UI == GUI and design == visual design. That's just how people use those words.

Yes but visual design always includes interaction and behavior. A position that only lays out visual elements with no regard to behavior would be called an artist.

Kind of a pedantic comment given the articles content...

Do designers who design webpages/apps generally call themselves GUI designers?

Pedantic? You described the distinction between UI and UX, you just described it incorrectly.

To answer you question, no. Such people usually design interactions. Behavior. What happens when the user clicks or scrolls or drags. So they're designing UI and they're called UI designers. UX is a step removed, defining the overarching design language for the app and how it makes users feel.

In my experience there are no people who work only on the visual layout of a page and not on behavior (what you incorrectly called UI). Mockup artists maybe, but even they are usually thinking about behavior.

Regarding the sidenote,

I can visualize an engineer making that mistake way more than a UX person.

"I need something to enter dates, oh here's a calendar widget library. done."

The reason for product to own UX more is they should be more connected to the 'why'.

My point was more so targeted as UI designers who co-opt the UX role. If there's a dedicated UX person, then they're less likely as they'll be actively thinking about the UX.

Whoever owns the UX should be putting the thinking effort into how that behaves. Things like this happen due to a) inexperience with whatever UI construct is being presented and/or b) not enough thought being put in to the usability of that component.

A developer is generally going to be more hands on with the resulting UI (checking/testing etc..) Whereas, a designer has more than likely mocked it up in InVision/whatever and then done surface level checks

And product managers will be hands on with the product but, well, they shouldn't be trusted with UI/UX/anything but the description of the problem they want solved :-)

Honest question. What's wrong with using a calendar widget for DoB.(engineer here)

You weren't born on a range of days.

You're unlikely to change your mind about when you were born.

You really only ever need to provide three well defined numbers.

So, why display a calendar?

Well, one issue is that there are different date formats used worldwide and there's a risk that the website will accidentally swap the month and date if I simply enter three numbers without thinking about them. mm-dd-yy and dd-mm-yy are both used occasionally.

There are also different calendar formats.

https://msdn.microsoft.com/en-us/library/cc194816.aspx

A calendar is good for a 'free choice'. It can provide context(i.e. day of week) and can be overlayed with useful information(price for a date/availability etc.

A calendar is not good for pre-determined dates where the date is fixed before hand - i.e. you don't get to choose what value you want the date to be.

For example, if you're entering in your driving license details for insurance quote, you don't get to choose when it expires - that's already decided for you. Ditto for DOB and other such things.

So, there are far more efficient options for date entry ranging from single text input (with appropriate parsing/validation) or the '3 dropdowns option(D,M,Y)' which is more effort but easier to avoid mistakes with.

For starters, the default date is generally off by anywhere from 20 to 70 years.

Isn't the most common date entry field one where you can type directly into, but have the option to use the calendar widget?

> business domain experts (seemingly now called 'product managers)

I wish they were called product managers. It's been my experience that what starts as product management slides in to project management, as the product managers are not interfacing with customers or crossing department lines for requirements gathering.