This is kind of an impossible question to answer without more context, enough of which is probably also impossible to give without writing a treatise.

However, one of the two is likely: Either your arguments aren't compelling, or are at least not compelling to your audience. Or, you're working with a team that is uncooperative and doesn't appreciate your work. OR! Some mixture of the two.

Regardless, when talking about implementing an entirely new design because there is an 'outdated user interface', that's a big fucking task, and I can honestly understand people being hesitant, regardless of how big an improvement it might prove to be. You really have to marshal a lot of resources and motivation for that (and pause feature development), unless you can significantly help with implementation, especially since your team is relatively small.

Not to pile on to the whole 'should designers code' crap, but the main reason I learned how to write pretty good (read: semi-working) html/css/javascript is because I became impatient with the people trying to implement my designs. Not only did it seem to take forever, but they would do a shitty job of it. No one cares more about your work than you.

If you learn enough front-end dev that you could take the work 90% of the way there, and then just have them code-review and fix the dumb shit, or connect data correctly, you wouldn't have to have these discussions. You could just do it, and be like "Here, fix the shit that I can't". You can even do that in pieces. Lets say you want a panel to show, and you don't understand how to have the click event handler show the panel correctly. It wouldn't take more than 5-10 minutes of a front-end developers time to handle that, then you can copy that code for other stuff. You can often get away with being pretty hacky.

I've written too much here, but I totally understand your position. However, it's common that designers who can't write html/css/js feel powerless in these situations. The whole reason people recommend learning it, even if it's basic, is that it gives you so much power. A semi-working prototype is WAY easier for a front-end dev to be like "Ok, I can edit this and make it production ready", rather than starting from a blank page. They also then don't have to deal with you constantly being like "No, it should be 2 pixels left", which is obnoxious for both the developer and the designers. Working with them this way will also develop your empathy for the developers, which they'll generally recognize and appreciate.

TL;DR - I had these same problems, which motivated me to learn to code just enough that I could hand them a mostly working prototype or semi-broken version of the existing product, which they could help me fix and make production ready.

Have you tried involving them earlier on in the design process? Personally, I find it easier to get buy-in when you create a sense of shared ownership from the beginning. And If lack of time is a key constraint, they might even guide you towards a more feasible solution.

It's a little give & take I'd say.

Only two ideas:

1. Give: understand how they think and work that into your designs and the way you talk about them (yes, you'll have to be empathetic with them as well as users, with no expectation of reciprocation—that's called maturity and is also just smart). They like things being easy? Show them how a more modular design is also more modular in code, and can be reused and is less work later. Do they like simpler things? Simplify a few things (you probably always can, anyway, to great benefit) in trade for one more complex thing elsewhere. Do they have beef with how design meets reality? Do your research up front and make sure you're understanding what's possible with the technology before you design, and bring them into the process earlier so they have a say. You're not designing in a vacuum; you're helping co-create a system. Work with them.

2. Take: positively and constructively work to get them thinking more about the end-users and less about themselves and their work. First, find out why they're so focused on development time and scope: is it all just opinion, or are they being measured, rewarded, or punished based on how quickly they work, even subconsciously? Do your best to work on that if so. Are they not understanding users? Get them to spend time on calls, interviews, or research sessions—take some of their time, even 15m per week, and get quotes, videos, highlight reels, or let them sit in on real tests. Get them as close to users as they're willing—and as frontend engineers, they might have some interest in that if offered.

In general—being frustrated with them isn't going to work. Change your strategy, or change the influences on their behavior. Yes, you have to do the work—you can say "engineers should care more!" (mostly speaking to other comments in this thread) or something, and it might feel good, but that won't change anything. Show them why it makes their lives better with real evidence and take small steps that have visible outcomes.

All great points here. I'll try to address some as a front-end dev. As that is my role and job here at my agency.

At the very least, make sure they have access to all that you're doing from day 1. I say this not because you aren't doing it but because when they come back and say "oh i didn't see the design" it'd be entirely on them since you've given them access to everything.

Setup consistent check-ins for design reviews. If y'all work in a sprint cycle pick a day. If y'all work in chunks, pick a percentage of complete to discuss. No dev should ever see the design for the first time during a hand-off.

Lastly, I get the idea that you are not the issue but are on the reseving end of their frustrations. It may be worth it to have a heart-to-heart style conversation to see where you can help reduce the pains.

As a FED myself I'm constantly bombarded with request to change this or that. Or someone tells me it "doesn't work as expected" an the definition of "expected" simply is "i just thought it'd be different".

The more you can integrate the FED team into your workflow the better it may become.

Other things to note.

Prototyping tools are cool but holy shit do they make it really easy to create a picture of something that may actually be hard. So if you go the route of prototyping make sure the dev has as much as necessary to reference when building. This could be the prototype plus some inspirational sites (where they can look at code). I dunno how many times I've pulled my hair out by getting a fucking video file and asked to replicate. It'd be like giving a single person a movie from netflix and asking them to recreate the whole movie, with one person.

If you run into a funky spot with a design. Maybe you don't know how to resolve something, or its starting to feel complicated, ask the developer. They may have some additional insights based on the product infrastructure, shortcoming and roadblocks to help you reach your goal. A friend of mine who worked at FB sat next to her dev counterpart and he explained that some things weren't possible because some aspects of their platform were still on legacy code. You'd never know that as a designer but the dev may have that knowledge.

And lastly, ask them what areas they want to improve. Best way to make a friend is to work on something positive together. If the devs believe the selection interface is problematic maybe y'all can go through an exercise to get it fixed. Helps y'all work together and build some rapport.

Best of luck - A frustrated developer.

Given the context that you are sharing, it's not about any tricks or tips that will help you push innovation forward, but how your product team is operating.

I think that a major part of the problem is on the Product Manager's shoulders. You should not struggle to convince your team which is the right design. From the early stages of the design process, you should work closely with the Product Manager and align on the main design guidelines of the feature. Your time should be spent in designing the best possible solution and not in arguing about your designs.

You are right to design with the user as a first priority and based on a fine balance between being consistent and having upcoming features in mind. To be honest the first one who should think that way is the Product Manager.

However, the time to implementation is not always the "golden rule" and definitely this is not something that the front-end devs of your team should worry about. Roadmaps and meeting shipping deadlines is a product manager's problem and responsibility.

As far as front-end is concerned, if your team needs weeks of development for implementing a new feature even on the existing UI, it means that you are missing something. E.g. having a design system would significantly increase your team's development speed and help you ship new features much faster.

If your UI is not functional and outdated, this should appear on your user metrics and feedback and your Product Manager should prioritise a UI revamp. Given the facts that you are describing, you are trying to make the things that your Product Manager should do (but apparently is not doing).

Long story short, your problem is not the developers' change aversion. It's not a matter of you finding any tricks to convince your team. It's a matter of how your team is working. If I were you, I would discuss my concerns with my Product Manager, so that we could find a long-term solution to this problem, or else I cannot see it working in the long term.

Everyone has mentioned good points already, but here's a few others that might help.

Do some user research. Nothing works better than data proven the design is better. If you can show your designs with and without the changes to an audience quickly, you can prove that a slight animation actually increases usability. But be prepared to be wrong.

Create a design system if you don't already have one. Developers understand the need for systems that solve many problems. If they understand the design system they'll be able to implement it knowing that it will be used again and again. Get them to help design the system too so they understand the decisions for the type and spacing scale.

If they just don't care about getting the finer details right – spacing, type, color – then you're going to have a hard time getting past that. Creating a design system can help, but you'll need to have a front-end developer on the team who cares about those details.

Try to relate your concerns with problems they understand. I've often related design quality to code quality. Engineers have linters, formatters, and best practices. They're often pretty OCD about it. The same way they do code reviews, they should be doing design reviews. The same way they have tech debt from corners cut, there's design debt from corners cut. There's common ground there.

Finally it can come down to your influence of the team. Small things like speaking confidently, standing tall, and being assertive shows people that they can't just take the easy way out and that this is important. Make sure your arguments for change are strong and you're not just doing it because "it looks cool". Don't sacrifice the details that you can't necessarily measure for impact.

Also, don't think of it as "dealing" with developers. They have concerns and some of them will probably be important. The team needs to work as a unit. Without that you'll always run into issues.

Interesting conversation.

There are two problems in this (not one). The first is getting the design of the app to be good. The second is making sure your team respects one another. Learning how to code React or Javascript may solve the front-end problem, but it ultimately circumvents the deeper problem about respect and cross-discipline understanding.

Anyway—learning how to code is fine. But tread carefully that the motivation to learn how to code in the first place is coming from a good place.

this may sounds obvious but... To get your point across: you'll need to present it in a form that the other party fully understands

For example: it helps when addressing a team of engineer to present your case in the most rational way possible with a well structured list of advantages AND disadvantages affecting everyone (not only end-users) of the solution you are proposing

No matter who is "right" or "wrong" in any specific case, there is one thing I have noticed: Designer often come from a background where soft skills like how to give constructive feedback and how to nurture a creative environment is essential. Many developers lack in this area.

It's not uncommon for developers to be very blunt/rude when voicing their opinions or to just change stuff in the design without telling anyone (likely to avoid social interaction). When invited to join the projects early they perform badly and their behaviour lowers team morale.

During my 10 years at a number of different companies I have never met designers who act like this, but a good share of developers do (of course designers can be douches in many ways too).

Solution? Social skill should be valued higher when recruiting developer. Make sure that they are good team players. Also, tech schools should teach more about working in a creative environment.

I have exactly the same problem, especially with new employees and the younger ones. They either do not recreate what had been designed or argue about things I can easily overthrow or support on my side with the use of e.g. Gestalt (like proximity). I feel they also lack soft skills and aren't able to communicate. I do everything correctly on my side (I know this because I have no problems with like 75% of developers and programmers who are communicative and want to cooperate) but there are those 3-4-5 guys who "know better" and "they know UX". Getting help from above is useless as I am in a development-driven organization. Very often I hear there's some new functionality in the system, it's already coded and they ask me for a comment if it's good. 80% of the times it's not at all good because it's dev/programmer choices - so developing fast and easy, not so that it looks and works good.

Try and involve the rest of your team in aspects of design that will help them see things from your point of view. A classic strategy is to show them direct feedback from users, research, customer support, etc. Even better is actually involving them in those things. I've noticed when developers have a chance to build empathy with the user, they are often much more receptive to change and doing things the right way versus the easy way.

Often this can't just come directly from you however, or at least you can't go ask them to do this as you're not their boss. That means your PM might need to step up and actually do their job (the fact that you have a weak PM running a team that large is kind of shocking to me, I can't imagine that flying for very long anywhere I've worked).

This is why the environments I've worked in that I've enjoyed the most have had leadership with design backgrounds. This attitude towards design would NEVER be allowed without very good reason. These types of empathy-building strategies often need to come from the leadership.

Alternatively I've had decent success winning over developers with data. Do you have the ability to run any tests around a specific feature? Or conduct research and compile the results, even if qualitative? Maybe if you start small you can slowly but surely win them over. Proposing a massive redesign of the entire app/site/whatever is a lot harder to do than a small feature or silo'd experience, but if you're able to do that and the results are positive you might have an easier time convincing them in the future.

I definitely don't envy the position you're in!

As a developer (primarily backend) myself, data would change my mind and it would override any dissenting opinions. The problem you face is how can you get that data when you're unable to make a prototype yourself? As others have already mentioned, it helps a lot to make a working implementation on your own. This is something you probably don't want to hear, but it's the 'easiest' way to sell your idea. The good news is there are so many resources to learn how to code now that it's not an insurmountable problem anymore.

I have to agree with others about coding. I learned HTML & CSS because I got sick and tired of half assed implementations and developers simply saying "no, I can't do that." Most developers I've worked with avoid CSS work either because it's boring or they're bad at it. If you can build the pixel perfect front-end then you're meeting them at least halfway. This breaks down a bit for native iOS / Android development, but most software today requires a good web component anyway. They also take you a bit more seriously when you know the basics the web dev stack and the time commitments to build various functionalities.

I think with a lot of the QA, interactions and subtle design nuances, I'll hand folks handling the front-end the css/js for those interface components. No extra effort on their part, unless they have to worry about polyfills for browser support. The good thing is if you're providing the front end code, you've already fine tuned the details and don't have to worry about the nitty gritty details being off.