22

How to deal with Developers who are reluctant to change?

over 2 years ago from , UX / UI Designer

I'm a single UX / UI Designer working as part of a Product Team of 17 people; 4 of those being Front End Developers.

Consistently I'm faced with the challenge of trying to convince them of the benefits of my designs and why I have done things a certain way. In general I have no problem with this - because I often have to do this for our Product Manager. My point is often that not only does it look good and consistent, but it also allows us to be more flexible further down the line on other upcoming features.

However - I often find that they look at it purely from their point of view i.e. how long it will take to implement, and not from the actual end user's. Then due to sheer difference in numbers and a weak Product Manager - I'm outvoted and the easy way is often chosen.

What's annoying is that often one of the areas singled out for improvement in our product - is the 'outdated user interface'. Yes it might be functional - but it's not a pleasure to use and I put this purely down to us always choosing the 'easy way'.

What tricks and tips do you use to try and help push innovation forward?

45 comments

  • Jimmy HookerJimmy Hooker, over 2 years ago

    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.

    24 points
    • , over 2 years ago

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

      0 points
      • Jimmy HookerJimmy Hooker, over 2 years ago

        That means they empathize, which is a pretty good sign. Could they give you read only access to their git repo? Looking at how they do things could also be pretty informative (although maybe overwhelming for a beginner). Being able to fuck with something real is really compelling. Even if you just tweak some shit and see how that affects the way things are displayed. You can then look up conventions online, and how the developers did other things, and copy-paste/tweak.

        I would definitely find some good tutorials to mess around, but also would be nice if you could dig into your actual products codebase. Here's one that looks like it has potential (I haven't tried it): https://learnreact.design

        5 points
        • Linton Ye, over 2 years ago

          Hey Jimmy! Author of the learnreact.design course here.

          Thanks a lot for mentioning my course. I completely agree with your points above which is why I created the course in the first place.

          It'd be much easier to work with devs if a designer can speak devs' language and show them that your design is not just pixels in Sketch but actually backed by code. They'd respect your design a lot more. Also completely agree that it's really compelling to be able to dig into actual product codebase and tweak things there. As long as you learn the basics, learn how to set up things, get the project running, and have a sense of where to look at and which file to change, it'd be life-changing since you can start contributing your design into the final product without someone else's help.

          4 points
          • Account deleted over 2 years ago

            Let's end this crap. At least a solid designer knows the basics of coding but is not to code. This is the first thing. The second - when will we start telling the devs to be more communicative, cooperative and learn the soft skills? I am fed up with this attitude that they are the ones we need to listen to and care for. If you understand coding, you create something good and you get poor communication, anger, hustle (you know, the "rush" to "let's just produce it, it doesn't need to be designed"), then whose problem is this? The designer's problem? No way!

            3 points
        • Account deleted over 2 years ago

          Git repo? Are you talking about the UX or the UI part? I hope the UI, at least... and not a UI Designer but UI Engineer. But wait... aren't we talking about more of a UX Designer with UI?

          And one more - can I come to a dev and point a line in the code and say I object using it and he has to convince me that it should be there?

          1 point
          • James LaneJames Lane, over 2 years ago

            If there is a shit piece of code that you think could be done better, of course you can! But if you do, you've got to have an example of how you think it can be better.

            0 points
            • Account deleted over 2 years ago

              If it's about a UI Engineer, then OK. But it seems the author (and me, personally), are more UX + designing solutions. And in such case NO, we do not even try to get into dev's work. We understand it, yeah, but we don't do it, don't try to edit it, etc. The same is the other way round - the dev gets what's to be done, analyzed, designed. Produce it, the best possible way you can produce it. Of course, you can be asked questions or asked for comments in the process but once given to produce - produce, maybe with petty questions if something is not clear, but I can't imagine useless discussions about the designer's choices. This is ridiculous.

              0 points
      • Linton Ye, over 2 years ago

        Hey Stephen, I'm the creator of learnreact.design.

        Just in case if you need any help in learning React. Are you familiar with HTML/CSS/JavaScript? I'm preparing a free email course that helps people get up to speed with the basics if they are not familiar with HTML/CSS/JavaScript. Let me know if you are interested!

        Feel free to ping me and I'll try to help wherever you need it.

        1 point
    • Josh Rio, over 2 years ago

      This x100.

      We're in an era, where it's acceptable to be a 'non-technical' designer, but I believe that era is coming to an end. As a designer, you should want to carry your designs through to completion to ensure your design maintains its integrity as it's translated from pixels to code.

      I can guarantee you one thing. Learning to code makes you a better designer. You'll stop doing frilly bullshit because you'll know how hard it is to implement. By simplifying your designs and thus the associated code, is likely to make half the argument for you.

      The other half of course, is learning to code. The fact you guys are using React, shows they know the right approach to frontends. As a designer, you should be learning it because it enables you to build cross platform applications with a single tool. Reacts mantra after all is 'Learn one, write anywhere'.

      If you can learn React, then you'll be able to design, implement, then code applications for Desktop, Web, Android and iOS. From a developers perspective they're going to respect you a great deal more. From an employees perspective you're a unicorn.

      And in the odd case that the company or development team are actually fuckwits. You can pack up your bags and take your skills to a company that respects them and make more money.

      My advice is to learn React through Stephen Griders courses on Udemy. React is a great way to start actually learning more functional Javascript too. You'll realize that CSS/HTML isn't that hard, and now you want to figure out how to stop duplicating code and use data instead of static code.

      Once here, you're in good shape for the next 10 years.

      2 points
      • Johan Gunnarsson, over 2 years ago

        I think we're moving in the opposite direction. All fields (design, ux, front end) are way more advanced today then say 5 years ago. To be a top tier designer you have to have a strong understanding of classic design principles, stay up to date with all the tools, all new frameworks, design processes, be great at communication your decisions and to sell your design (to clients or internally), etc.

        If you besides that want to be a skilled front end developer and write production ready code, well good luck with that. You can be average at both, or really great at one.

        0 points
        • Josh Rio, over 2 years ago

          1,000,000% disagree.

          I have a feeling this is coming from a perspective where you haven't actually tried to code and so you think it's an unattainable skill. I could be wrong but I doubt it because I used to think the same way before I taught myself to code.

          I consistently hear this defeatist attitude on both sides of the aisle. Designers saying you can't be good at developing. Developers saying they can't be good at design. The truth is, good design and development share many of the same fundamentals such as simplicity, modularity, reusability, scalability, systems thinking etc.

          If you learn Javascript and a framework (like React) for even 6 months, you'll see that it's not that difficult. Is it hard? Sure. Is it a 'savant-only' skill? No way.

          You might also be in a position where you work in a large company or studio where specialists are all that people hire. Personally, I don't do that, I start companies or work on early stage companies where being a generalist is your only option.

          At early stage companies you don't have the budget to hire:

          • 1 x UX designer
          • 1 x UI Designer
          • 1x User Research
          • 1x HTML/CSS Developer
          • 1x Frontend Developer
          • 1x Backend Developer.

          You learn to 80% yourself or you're unemployable, or in my case unfound-able. If you're not a "specialists specialist" (i.e Erik Spiekermann, Massimo Vignelli) you're always at the risk of a person with 1 more skill than you stealing your opportunities.

          Personally, that's not a risk i'm willing to take.

          0 points
          • Johan Gunnarsson, over 2 years ago

            Yeah we seem to disagree. I come from a code background and early in my career I did both design and development. But I have come to realise that this skill has little impact on how "good" a design is. Code illiterates can create amazing design, all you need is an understanding on how it works.

            I still code for fun but rarely uses it professionally. Mainly because my code is not as good as that written by a real developer. I think it's too hard for most people to be good enough in both design and code to make the stuff you produce production ready. If it's not good enough to use for real, then you might as well use a visual prototyping tool.

            My 2 cents

            1 point
    • Account deleted over 2 years ago

      I disagree. Well, not completely, but still. Of course, having some knowledge of coding is a must-have but it's not a designer's role to actually implement it. I can see another problem - mixing UX with UI. It's like combining to save money - this is the first problem here. The second - you are either a UX Designer and you don't stick to coding, you just beware of some problems + ask for dev advice. If you are a UI Designer then there's no problem because I say you would actually await advice from a senior dev. If it's a junior blocking everything, then well... the junior has a lot to learn, also the soft skills. It's not a solution to do everything yourself. You first analyze, talk to users, then wireframe, and prototype (which is not a product yet!), maybe create aesthetics but code the final product? IMO that's way too much and if your boss even lets you do it, then there's a problem in the organization.

      2 points
    • Cristian MoiseiCristian Moisei, over 2 years ago

      Another possibility is that they actually have good points, if the design OP is pushing for does improve the UX but means huge technical complications, it might not be worth pursuing to begin with. What I try to do, instead of coding myself, is to get a rudimentary understanding of programming and enough basic coding skills to understand what it would take to develop a particular design and use that knowledge to try and keep my stuff reasonable. I also involve developers early on, discussing my ideas and giving them a chance to speak up if they think something would cause difficulties. This also helps them feel less like they are handed some dude’s design, and more like they had a hand in shaping the product and the thungs they care about were addressed too.

      I found there are usually very small compromises that only minorly impact the experience but save us a ton of development time, so this means I can have 80-90% of the design I had in mind, and choose which parts we change, vs letting developers decide on their own.

      Have a look at this course that explains the core concepts of programming without teaching any specific language or framework. I found it useful. https://www.linkedin.com/learning/programming-foundations-fundamentals

      1 point
  • Max HenningssonMax Henningsson, over 2 years ago

    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.

    10 points
    • , over 2 years ago

      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.

      0 points
    • Account deleted over 2 years ago

      What if they don't want it? They just want to produce it "now". Believe me, UX Designers don't need the cooperative skills - this is the basis for us, remember, we work with users. The devs very often seem to forget that they also should have them.

      1 point
    • Account deleted over 2 years ago

      Can I come to a dev and point a line in the code and say I object using it and he has to convince me that it should be there?

      1 point
  • Tristan HarwardTristan Harward, over 2 years ago

    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.

    4 points
  • Art VandelayArt Vandelay, over 2 years ago

    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.

    4 points
    • Account deleted over 2 years ago

      What if they have their own ideas, they stick to what's easier to implement and they don't care about "this designing process"? Why do the designers have to do this, that and also that. Where is the developer's role here?

      0 points
      • Art VandelayArt Vandelay, over 2 years ago

        Sounds like what you are describing in your comment is an asshole employee. And if that's the case take the proper steps to remedy with the company.

        Generally speaking though, as a dev, I can say I've been treated as a "burger flipper" more times than not. Meaning, I've met a lot of designers, PMs, Account Managers, etc. who seems to think developers are not meant to have their own opinions on how something likes, how it acts, how the overall experience feels, etc. That is problematic. Asking for ones designs to be made is one thing, asking for them to be made while creating an inclusive environment (by all parties) is the ultimate goal.

        1 point
  • Manos Kyriakakis, over 2 years ago

    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.

    2 points
  • Anthony Short, over 2 years ago

    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.

    2 points
    • Account deleted over 2 years ago

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

      EXACTLY. Why no one seems to see that it's the devs that need to work on their cooperative skills, too??? So are they just machines to write code or do they want to be integrated into the proces? If they want to be integrated, they need to follow some rules. If I want to talk about coding, I have to respect THEIR rules. If they want to talk about creation, they need to respect the designer's rules.

      0 points
  • Andrew C, over 2 years ago

    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.

    1 point
  • Thibaud Van VreckemThibaud Van Vreckem, over 2 years ago

    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

    0 points
  • Johan Gunnarsson, over 2 years ago

    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.

    0 points
  • Account deleted over 2 years ago

    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.

    0 points
  • C W, over 2 years ago

    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!

    0 points
    • Account deleted over 2 years ago

      So you would spend time and resources to not only present the outcomes of the UX process to the PM, but also explain yourself to your fellow devs? Every petty thing they object? And of course, you think that I can come to a dev and tell him I object using this and that code and now he has to tell me why he chose this? Will he spend his precious time to explain it to me?

      0 points
      • C W, over 2 years ago

        I understand your frustration because I've been there, but you sound very bitter about this experience. Are you sure you're in the right work environment? It sounds very developer driven and that design is taking the back-seat. As a designer that's not ever going to be fun for you.

        I'd seriously consider looking for work elsewhere. I only say this because as designers we're very lucky to be able to find work easily. Life is too short to spend your days frustrated over arguments with people who don't value what you do for a living.

        That said, yes, I would spend my time doing those things if it actually got me results. If I tried a few times and it was extremely clear it's not going to work, I'd find a new job (or accept that I'm just there to push pixels). Leaders in design and technology in general become leaders because they spend time with people from other disciplines, work with them, and influence their decisions to get the outcome they want for the right reasons. You can't simply demand to be respected, especially in an environment where you're outnumbered. You either accept that it's going to be a challenge and try and solve it, or you leave and find an easier challenge.

        Again, I know it's frustrating and DN is a good place to vent without judgement, but this experience itself is a design challenge.

        0 points
  • Brian LeeBrian Lee, over 2 years ago

    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.

    0 points
    • Account deleted over 2 years ago

      If he's a UI Engineer then yeah - work on your own. Of course, if the PM lets it, as the role assignment IS important in a project or a company. If he's more a UX Designer then working on the actual production code is a pathetic joke.

      0 points
      • Brian LeeBrian Lee, over 2 years ago

        I think you misunderstood. Unlike backend logic, you can make a frontend UI prototype that is completely separate from production code. You don't need permission for that. Moreover, if you're a UX designer who already has UX worked out, it's not like working on a working prototype is going to cut into your time on the project. Of course I may be completely wrong.

        0 points
  • Roman PohoreckiRoman Pohorecki, over 2 years ago

    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.

    0 points
    • Account deleted over 2 years ago

      IMO it's bad. You can't be great at everything. If you are talking about UI Engineering, then OK. But if it's about a UX Designer - IMO this is way too much. UXD has its own process and it certainly doesn't include actually creating the product, producing it.

      0 points
      • Andrew C, over 2 years ago

        Yea this is accurate. But this is often dependent on the size of your company. If you’re at a 10 person start-up then helping with the front end makes sense.

        For larger products not so much.

        1 point
  • Shawn MartinShawn Martin, over 2 years ago

    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.

    0 points
    • Account deleted over 2 years ago

      It's confusing we are talking about a UX/UI role here so it's a bit of a problem here. If it was pure UX I wouldn't expect him/her to hand actual components of code. Whose job is it to choose the best tools?

      0 points