4 ms·

I also think it should be noted that compromise between designers & developers & business domain experts (seemingly now called 'product managers) could vastly s

by sloxy 9y ago

I also think it should be noted that compromise between designers & developers & business domain experts (seemingly now called 'product managers) could vastly simplify all this. The more empowered a developer is to over-ride a designer/biz person's preference[1], the better it is for all. Way too often, I see developers just accept what the product manager/designer specifies with zero pushback when it strays outside what could be considered the 'norm' for whatever tech stack is in play. [1] I use the word preference because that is all it is - their preference. They don't have a magic ball. Sidenote: I'm also seeing a rise in UX suddenly becoming owned by the UI & product management team which is bizarre. You have designers(whether from print backgrounds or whatever) making poor(& I mean piss poor) UX decisions because they don't have the exposure/understanding of web platforms. Case in point: if your UX person has a calendar widget to enter a date of birth, they should no longer be allowed do UX. /rant

tkahnoski 9y ago
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'.
- sloxy 9y ago
  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 :-)
Silhouette 9y ago
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.
- sloxy 9y ago
  > 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.
  - Silhouette 9y ago
    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).
    - sloxy 9y ago
      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.
noxecanexx 9y ago
Honest question. What's wrong with using a calendar widget for DoB.(engineer here)
- verletx64 9y ago
  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?
  - PeterisP 9y ago
    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.
    - Blaiz0r 9y ago
      There are also different calendar formats. https://msdn.microsoft.com/en-us/library/cc194816.aspx https://msdn.microsoft.com/en-us/library/cc194816.aspx
- sloxy 9y ago
  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.
- jstarfish 9y ago
  For starters, the default date is generally off by anywhere from 20 to 70 years.
mnutt 9y ago
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.
scruple 9y ago
> 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.

by sloxy 9y ago

tkahnoski 9y ago

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

sloxy 9y ago
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 :-)

Silhouette 9y ago

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.

sloxy 9y ago
> 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.
- Silhouette 9y ago
  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).
  - sloxy 9y ago
    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.

noxecanexx 9y ago

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

verletx64 9y ago
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?
- PeterisP 9y ago
  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.
  - Blaiz0r 9y ago
    There are also different calendar formats. https://msdn.microsoft.com/en-us/library/cc194816.aspx https://msdn.microsoft.com/en-us/library/cc194816.aspx
sloxy 9y ago
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.
jstarfish 9y ago
For starters, the default date is generally off by anywhere from 20 to 70 years.

mnutt 9y ago

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.

scruple 9y ago

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