You've actually hit the nail right on the head - and I'm pleasantly surprised to see that some of the recommendations you've made, we're actually starting to put into place at the minute as a team.

For example, one of senior members of the front-end team mentioned how helpful it would be to them for me to gain some understanding of REACT (their framework of choice).

I could 'wireframe' up my layouts in REACT, apply some basic styling and then leave them to figure out how to perform the complex workings of it e.g. panels sliding in etc...

I'm very open with sharing designs (and getting feedback) as they're being done - but I don't talk about every single decision that I make. Perhaps I should? My worry is that I would never get anything done.

For example, one of the issues we're discussing at the minute is what a selected state should look like. How it should work functionally has never been an issue - but the team are reluctant with my choice because it would require changing it across our platform. Functionally there wouldn't be any issue - but it's purely the work required. Even so, we're not talking days worth of work - it might be an extra hour or two.

The Product Owner is happy with my decision, but all it takes is a few of the team to do a couple sharp intakes of breath - and they get their way. It's just frustrating.

Don't get me wrong - I don't want it to seem as though I'm only interested in getting my own way. I completely understand it if they have a valid point i.e. something is likely to take weeks extra for very little benefit.

It seems that because a lot of my decisions are subjective, then I have to fight tooth and nail for them - but the Development Team just have to play the time card and they get their own way.

My go to response now is always to suggest putting the two versions up for testing internally to see what our internal users prefer. The majority of times I come out the winner because inevitably mine is more usable. Then it's up to the developer to fight the battle of time vs. benefit to the product owner.

Sounds like a cop out - and to be honest it is.

EDIT:

Oh and another thing I've just thought of in the battle of Design Vs. Developers is the whole "we don't do that elsewhere, so why should we do that here...". Take for example in the last couple of weeks one of my designs used a slider for a form. Amazingly it's the first time we've ever had the need to use a slider on one of our forms and the response from the developer was that because we didn't use it anywhere else on the site - we shouldn't use it here. I was astounded.

My response was just because we haven't used it anywhere else doesn't mean that it isn't the right solution for this particular problem! I get it. Developers want to re-use as much code as possible - but this was just a massive cop out!

Like Andy mentions really....

Although I've been in my team for a year or so now, I'm the first UX / UI Designer to join our in house Development Team. Because of this, people don't know how to treat me i.e. what rules and processes do we need to follow. The Developers do however.

We've got the basics right e.g. I'm called upon when big features need to be scoped out properly from a set of requirements and I tend to work 2 - 3 sprints ahead of the rest of the actual development team to allow me team to complete the work and hand it off to the front-end team to pick up without delay.

Common problems are:

• Poorly put together requirements from a part-time product manager, which in turns leads to unforeseen changes when the front-end team picks up the work. Changes which change my designs massively. To the point where my original designs are redundant.
• 'Signed Off' designs changing when it comes to final development because the developer prefers it a different way. I obviously make my point about user research etc... but because the developer is more 'senior' and baffles me with developer speak about how much harder it would be, and how it would cause further delays - I feel like I'm forced to give in.