Many "UX persons" are engineers or computer scientists, and having a good working relationship with them and seeing them as equals goes a long way to allowing you to provide your own insight and give suggestions and feedback.
The problem is that they often don't know the constraints of the system you're working with, something that only comes with actually working on the implementation.
E.g. I was working on a display. The graphics were designed by a UX Team. However the display only had 256 colors, had to be readable outside, had a 320x240 resolution. They had designed everything as vector graphics with highest color settings on really good Eizo monitors. The customer thought the designs look cool, and I wasn't given any freedom in improving them.
I tried discussing the constraints with them, but because they were "on top" they wouldn't listen.
In the end the customer saw the prototype and said it looked terrible. But I had all the communication with the UX Team and them that I wasn't allowed to make it work for this display.
In the end it cost everyone an extra month and a lot of frustration to arrive at basically what I suggested when I first checked the hardware.
The problem isn't to learn about UX, it's that you have a "UX person" that may not know about UX and dictates the terms.
UX person suggests a design that is sprinkled with choices that clearly are from someone that has not been on the web that long, like wrong icons.
We do a meeting and explain what is going on, what the user wants to see on the page, and the UX comes back (usually that same day - how quick of them) with another version, but this version shows that the UX person did not understand the problem again. And again. And again.
I've seen the UX person showing a wireframe to the user and asking 'Will this cover all scenarios?'. Client said yes, we delivered the feature monday, and tuesday client was 'hummm, without the hability to do scenario X, this won't be used'.
The reason the UX person is so beloved between a bunch of devs is only because of the UI aspect of it - it looks good, something we devs could not come up with. But damn, I would love to work with an UX that I feel that knows what she's doing.
A UI is essentially the highest layer of abstraction we build and thus should follow the same principles as any other. Namely respecting both the lower and the upper abstraction barriers.
UX designers are responsible for the language on top of all these layers. They need to understand the human side of things (often through data or through direct interaction such as workshops), but also the technical and artistic side of UI implementation. Direct interaction, written documentation and learning are paramount.
The good thing is that we programmers also want to understand the layer above us, so there is a natural pull for programmers and designers to communicate and to refine that communication.
It’s like that guy that said: “it’s easy to be a good investor in god times, it’s when recession hits that the pros really shine”
No true Scotsman would ignore the technical specs!
The fact is that many UX designers are designers first and foremost and maybe even entirely non-technical when it comes to specs. The existence of "true professional" UX designers does not mitigate the vast quantities of average skill UX people most teams will encounter.
I don't think that's much of an excuse. A graphic designer needs to know about page bleed and colour spaces. A product designer needs to understand the strengths (literally sometimes) and weaknesses of the materials they are working with. And a UX designer for a tech product needs to understand the technical constraints of the medium they designing for, or be able to talk proficiently to someone who does.
How can you design a user's experience (lest we forget what UX stands for) if you don't understand to at least some level the medium through which it will be conveyed. Designing something that a user will never see because the colour depth of the display they be using can't convey it is not designing the user's experience at all.
Right. Most designers are not UX designers, they are graphic designers hired to do UX because they can make pretty pictures in Illustrator.
People not listening come in all forms. UX, dev, MBA.
Unless you have valid reason to think the user would prefer your way, this sounds like the correct chain of command for a strong product.
Repeat the above for as long as you want.
Of course, the kind of place the GGP is complaining bout won't let peasants like developers to take part on that phase, so win-win, I guess.
If one's priority is design freedom or whatever, a good working relationship with your higher ups is the best chance to enable that.
Working well with managers is also a good strat for becoming one yourself, and having more influence over things you care about.
True, the problem is more when companies become more and more top-heavy over time. These intermediate layers are created. With every layer it becomes less likely that the people that can actually decide won't ever hear valuable feedback until it's too late.
>Working well with managers is also a good strat for becoming one yourself, and having more influence over things you care about.
In the end I showed them what had to be done to make it look decent on this kind of display. Because all layers of management were in the room, they managed to decide to do these changes. It's just a very inefficient way to get to this point.
Everything else was out of my hands.
Who said you did?
Many of who use the argument "Apple/Google does it this way" I'm not saying your now right it's just been my experience that they aren't engineers or Computer Scientists.
In fact I've seen several engineers trying to migrate to UX but the gatekeeping and prejudice made them give up.
1) I've never met a UX person who is a programmer. Most of them are from graphic design background, sometimes for vouchers or magazines and they don't necessarily understand that the computer screen is not the same kind of medium as a piece of paper.
2) Having a professional relationship entails pushing back and questioning. Being a "yes man" to the UX people is not a good working relationship. The implication of your comment is in order to push back and provide feedback I must first acknowledge my subservience to their whims and only once they approve of my work I may humbly submit some suggestions for their kind consideration.
UX people, UI designers and PO/PMs who see developers purely as interface xerox machines don't really deserve much respect.
I find "graphic designers" to be enormously helpful in solving problems related to user interaction and judgment with regard to use of color, typeface, and effective use of limited screen real-estate.
There are good ones and bad ones. The key is to assess where they are, and learn how to communicate with them with regards to any technical impacts.
The last thing I'd want to do in collaborating with a team-mate is summarily judge them as "my inferior". But that's (unfortunately) just me.
most organizations that tend to have office politics and are very politically-correct in their behaviour tends to end up with people in roles calling shots, despite those shots not being great.
graphics designers is just one example of this that i've seen, where a poor UI or bad UX is mocked up, but because you're an engineer, you do not get to have much input or your input is regarded as irrelevant (because your role is to code, not do UX design).
That's what i mean by the "inferior" comment - that the UX/UI designer isn't as good at their craft as you are in implementing code.