3 ms·

Hi there. The reality is this was totally predictable. In the beginning things were simple. UI/UX is focused on creating the prototype and actual implementation

Hi there. The reality is this was totally predictable. In the beginning things were simple. UI/UX is focused on creating the prototype and actual implementation was done by front-end programmers. But nobody likes to pay extra, so why not make designers code? Yes, i am one of those designers, old enough to remember frustration with tables and inline css. So if you asking your self why there are no more websites that are beautiful and usable? This is your answer: Is very rare someone with artistic abilities to have "programmers mind". Is enough frustration to deal with browser layout to expect someone to do full stack front-end dev. In the end you have mediocre designers (without basic understanding of color theory or typography) that are mediocre programmers (using all the cool JS tech, without CS basic understanding), so websites have interactive technology with design interaction from 2005:)

lowercased 8y ago
> so why not make designers code? Well... I don't want to force someone to do that, but I'd really really really prefer if design people actually did code sometimes, so they understood the reality of what they're 'designing' from an implementation standpoint. It may take you 6-8 hours to mockup something that is ... logically impossible, which someone 'signs off' on, then 40 hours for someone else to try to cobble together - pushing back is 'combative' and 'negative', etc. You know how designers don't like people who ask for stuff that "pops" and then want more "pop"? Designers 'designing' stuff that creates practical impossibilities or gaps in state, etc. - programming folks hate that just as much as you hate 'make it pop' requests. Hey - cool - you "designed" a form with 3 elements! The actual implementation options are 17 for that area. What should happen with 0 selected? Do we want notifications or help text? Nice - that design looks really slick with 3 checkboxes in a pulldown, but you've sort of just invented a widget that doesn't really exist, will create accessibility nightmares, and you didn't show how this should behave on mobile/tablets. The number of design people I've met who can actually reconcile clean design with real implementation, usability and accessibility issues addressed is very small.
- pjungwir 8y ago
  I can sure relate to this. Or my favorite question: "What happens when I click that magnifying glass in the top nav?" and they say, "Oh, I didn't think about that!" I doubt the real answer is for the designer to code (though it's nice when you get to work with someone like that), but you sure have to ask a lot of questions, and you never manage to check everything up front. Especially anything that doesn't immediately open a new web page, at every step there are just so many input possibilities: the user clicks this button or that, clicks elsewhere, types a bit here then a bit there, presses Enter, presses Tab, presses Escape, has a screenreader, is on a phone, is on an iPad, gets an error, gets 1000 results, changes the dropdown that enabled this other control. . . . I guess you do the best you can imagining flows up front, but plan on having some iteration as you discover gaps in the design.
  - lowercased 8y ago
    > I doubt the real answer is for the designer to code I'm not saying they have to code 100% of everything, but I'm really fed up with having to deal with that sort of "well gosh that's not our issue!" hands off sort of 'design' folks. Internal design teams that work in the same building as the implementors/devs... maybe a different experience. I'm sometimes brought in and given "mockups" from an external team, done in whatever tool of the day they use, that have little bearing on real world web implementation. it's apparently beneath some of these folks to learn css/html and use ... you know... a web browser to mock up a web site. i don't care how much 'freedom' some tool gives you, you're just punting the hard implementation to someone else. Came off a project recently like this - the original team had done 'weeks' of 'design' and 'planning' with an external design firm. "but plan on having some iteration as you discover gaps in the design" sounds nice, but in their mind, they'd already "thought a lot about it" 8 weeks earlier, so any implementation issues I found were somehow... my fault? my problem? "these guys are a really strong design firm..." who don't seem to have ever actually implemented anything they design, from what I could tell.
hinkley 8y ago
> But nobody likes to pay extra, so why not make designers code? From the other side of the aisle, this isn't what happened. I want to preface this by saying that in general I like designers, but there are things about your good friends that you find annoying and tease them about. So now for some teasing. What happened was that a bunch of up-in-the-clouds designers kept denigrating (directly or by omission) developers in front of their bosses and we got tired of it. The response to "why can't you guys figure this out? It's really simple" was "Well if you're so smart why don't you implement it?" Constructively, that translates to engineering the situation so the designers felt our pain. But on a particularly bad day the sentiment tended to be more like "choke on it."
- readitone 8y ago
  Nice:)) Very Nice. Actually i understand it, so much that i fired a lot of brogrammers, because in the end a lot of the "heavy and impossible work" of programmers is to implement someone else's real hard work and claiming the check. So now we are all suffering together.

lowercased 8y ago

> so why not make designers code? Well... I don't want to force someone to do that, but I'd really really really prefer if design people actually did code sometimes, so they understood the reality of what they're 'designing' from an implementation standpoint. It may take you 6-8 hours to mockup something that is ... logically impossible, which someone 'signs off' on, then 40 hours for someone else to try to cobble together - pushing back is 'combative' and 'negative', etc. You know how designers don't like people who ask for stuff that "pops" and then want more "pop"? Designers 'designing' stuff that creates practical impossibilities or gaps in state, etc. - programming folks hate that just as much as you hate 'make it pop' requests. Hey - cool - you "designed" a form with 3 elements! The actual implementation options are 17 for that area. What should happen with 0 selected? Do we want notifications or help text? Nice - that design looks really slick with 3 checkboxes in a pulldown, but you've sort of just invented a widget that doesn't really exist, will create accessibility nightmares, and you didn't show how this should behave on mobile/tablets. The number of design people I've met who can actually reconcile clean design with real implementation, usability and accessibility issues addressed is very small.

pjungwir 8y ago
I can sure relate to this. Or my favorite question: "What happens when I click that magnifying glass in the top nav?" and they say, "Oh, I didn't think about that!" I doubt the real answer is for the designer to code (though it's nice when you get to work with someone like that), but you sure have to ask a lot of questions, and you never manage to check everything up front. Especially anything that doesn't immediately open a new web page, at every step there are just so many input possibilities: the user clicks this button or that, clicks elsewhere, types a bit here then a bit there, presses Enter, presses Tab, presses Escape, has a screenreader, is on a phone, is on an iPad, gets an error, gets 1000 results, changes the dropdown that enabled this other control. . . . I guess you do the best you can imagining flows up front, but plan on having some iteration as you discover gaps in the design.
- lowercased 8y ago
  > I doubt the real answer is for the designer to code I'm not saying they have to code 100% of everything, but I'm really fed up with having to deal with that sort of "well gosh that's not our issue!" hands off sort of 'design' folks. Internal design teams that work in the same building as the implementors/devs... maybe a different experience. I'm sometimes brought in and given "mockups" from an external team, done in whatever tool of the day they use, that have little bearing on real world web implementation. it's apparently beneath some of these folks to learn css/html and use ... you know... a web browser to mock up a web site. i don't care how much 'freedom' some tool gives you, you're just punting the hard implementation to someone else. Came off a project recently like this - the original team had done 'weeks' of 'design' and 'planning' with an external design firm. "but plan on having some iteration as you discover gaps in the design" sounds nice, but in their mind, they'd already "thought a lot about it" 8 weeks earlier, so any implementation issues I found were somehow... my fault? my problem? "these guys are a really strong design firm..." who don't seem to have ever actually implemented anything they design, from what I could tell.

hinkley 8y ago

> But nobody likes to pay extra, so why not make designers code? From the other side of the aisle, this isn't what happened. I want to preface this by saying that in general I like designers, but there are things about your good friends that you find annoying and tease them about. So now for some teasing. What happened was that a bunch of up-in-the-clouds designers kept denigrating (directly or by omission) developers in front of their bosses and we got tired of it. The response to "why can't you guys figure this out? It's really simple" was "Well if you're so smart why don't you implement it?" Constructively, that translates to engineering the situation so the designers felt our pain. But on a particularly bad day the sentiment tended to be more like "choke on it."

readitone 8y ago
Nice:)) Very Nice. Actually i understand it, so much that i fired a lot of brogrammers, because in the end a lot of the "heavy and impossible work" of programmers is to implement someone else's real hard work and claiming the check. So now we are all suffering together.