Ask HN: How to get developers and UI designers to work well together

I have a fair bit of experience here as I work with many teams struggling with this.

The root cause I have found is getting designs done in isolation and then treating the Figma/Sketch/whatever file as a hard business requirement, instead of treating the user experience as a collaborative exercise that is a tradeoff between usability and feasibility.

Sorry for blogspam but I sketched a model of the two approaches. https://bitbytebit.substack.com/p/waterfall-design?sd=pf

As a mobile developer, the main pain point with collaborating with a designers over the years has been their complete lack of knowledge when it comes to norms on Android.

All have been exclusively iOS users, with no feel for how the two platforms differ, and I have had to take it up on my self to translate and adjust the designs given to me so that they follow norms and practices on Android.

It's only one tip, but if both developers and designers are in color-calibrated environments with color-accurate monitors, you can eliminate some it-looks-good-on-my-screen arguments with technology (colorimeters). Many developers that are working pretty close with designers are using really bad, not-calibrated panels and aren't seeing the same thing as the person giving them the design.

I've worked as both, for many years now.

It obviously varies by individual and by team, but in general the solution is more communication, earlier in the process, and frequently throughout it.

The thing designers often don't understand is how their design needs to work within the larger system, which has many complex interactions, tradeoffs, and constraints. Changing one thing entails changing many other, non-obvious things, and did you think about that when you drew a picture of it working perfectly in Figma? No?

The thing developers often don't understand is that designers work without the benefit of certainty. They may get a set of requirements from a PM, but often they don't, or they don't get a very good one. Do all the user interviews you want, you're still just guessing about a hundred times a day. And there is no automated testing or static analysis. There isn't even syntax highlighting. You just make something you hope is right, then show it to people, and have them point out all your mistakes. Of course they get defensive and protective of their jobs.

So developers and designers need to be in communication with each other frequently, to spot problems early and fix them. And it needs to be so common and lightweight an interaction that it doesn't feel like a committee meeting, but like a collaboration between partners with the same goal.

I'm usually the guy called in to make peace between designers and developers. I have consulted with large enterprises, major IT providers, etc., and my job was to bridge the gap. I have also been one of the Creative Directors at Razorfish, but my job usually starts with presales and meddles with the product managers, designers, and developers.

In short, I can talk the business talks while designing and finish off coding the designs. So, here are what I think.

The war between Designers and Developers will never end, and it is OK. The designers will blame the developers that they are supposed to be smart enough to code the design. At the same time, the developers will scorn that the designers have no clue how things work. The situation aggravates in bigger companies and environments where separate teams by function, not by products or features/modules.

There was a documentary about Aston Martin making the One 77[1]. The engineers, designers, and everyone work together. There are no separate teams that come together later to fit in the final car. A few friends and I used to refer to this analogy when explaining how to get designers and developers to work together -- think of the product/feature/module and then bring the team together from the start.

There should be one person in the team who can walk between the designer and developer world, even if s/he can only either design or write code. S/he should have that empathy to understand both sides of the stories. Once you have that person and the team begin to learn to dance around, the intricacies of interaction between the two different minds will be the time when things get smoother. There will still be friction, but it should become way more manageable.

1. https://www.imdb.com/title/tt2289553/

I come from a different industry before moving into this one, but there’s a chaotic and abysmal lack of teamwork between departments in this industry that I’ve seen this far.

Have those two teams work together.

Also, foster a culture of continuous self-improvement. I’ve now seen a bunch of “it’s good enough to ship, go for it” and now whatever work arounds and bandaids are permanent. Don’t be so fast, don’t try to iterate so quickly, and focus on quality over quick ROI.

Imagine if Boeing behaved like a SaaS operator. The first version of 737 would be glued together, and in turbulence the wings would snap off “oh, I guess we should use more glue in the next version - alright guys, iterate!”

Slow down, do a good job, and the product will come.

Don't just let your designers hand over the results. Make them pair on work with the engineers. This way, they will

- get to know each other

- get a better understanding of each other's work: what is important in the design and what is not, why is the design like it is, what is difficult to implement, how much effort certain tasks are, etc.

Another trick is to ask engineers for design input, e.g. in sketching sessions or design reviews.

As an engineer, I think Figma is a great tool. I can see exactly how the UI should look like, including all the details like colors, fonts and margins.

What are the friction points? I’m a UX designer (15 years experience). I love working with engineers on solving problems, QA’ing and releasing high quality products. Maybe your designers are more fresh and junior ??

Have you read this article https://www.smashingmagazine.com/2022/07/resolving-conflicts... ?

I think this is largely a personnel & hiring problem. Stop hiring people who can't work in teams. It takes more than just Developers to ship good software. Stop hiring designers who cannot design software.

> do you also find that there's a lot of tension between developers and designers?

To be honest, no, not really. Only ever at one job have I experienced a problem with developers and designers working together. One designer (out of two or three) was very ego-driven and was focused on producing a piece of art to hang on a wall, while one developer (contract, out of five) just flat out didn't respect anyone else (developers, designers, or PMs) and it was "his way or the highway". There are ways to work around this (mostly around setting clear guidelines for process and expectations), but ultimately the problem is with those people. Let them go.

Good designers are those who recognise that you don't ship PSDs (or Figma designs, as it is now) and are aware of the iterative approach to developing software. Good developers are those that actually respect the design process and set aside time for it.

If you structure your project/team/company where developers and designers are separated, and designs are "chucked over the wall" you will forever be running into problems. The best teams will be cross functional and have design's included in every step of the process.

Design Systems can be a huge help here - when everyone (designers and developers) have a common vocabulary of how a product looks and acts. Get this mature enough and you can just design your product with wireframes.

I’ve found that most misunderstandings between UI/UX and front-end devs can be resolved by having the UI/UX people read a book on CSS. Once you start designing to Flexbox and Grid, instead of reinterpreting/porting designs using Flexbox/Grid, most of the problems disappear.

I can’t overstate how much easier life got once my teams started using CSS as a shared design language.

Designers get really excited when they see what Flex and Grid are capable of. It’s really empowering for them to design something that they know they can be built. Keeps developers honesttoo: No more “this is hard to do on the web, wontfix” if the designers know how to do it themselves.

If you’re a designer working in the web in 2022 and you don’t know the ins-and-outs of modern CSS layout technologies you’re at an impossible disadvantage.

I've been both, currently a developer. My 2 cents. Designers work in the "What we would love to build" space while developers work in the "What can we build" space. Those worlds are incompatible.

Paraphrased comments I've heard in the past month.

"Yes our small margin is always 8px but it didn't look good in this confirmation modal so I changed it, that's no big deal right?" (a designer that doesn't design based on the design system is a joke)

"Here is a link to the figma file ... no not that one, it's the 5th one from the left after you scroll way to the bottom" (I've never told a designer to start up a dev environment and figure out where the code is for whatever feature they are designing, why do I have to open figma and hunt around?)

If 'design' and 'development' are entirely separate it's pretty much impossible because the two sides have different goals. You have to align them. This entire process gets a lot easier when you have one team who understand that their job is to deliver value to the customer (or user) rather than "design pretty things" or "write clever code".

Until everyone gets that message, it can't work.

I've worked in the field for 20 years and I've struggled to find something that works consistently. My frank opinion is that design (particularly UI design) as an industry has a perfectionism problem - designers are encouraged to strive for the platonic ideal in their work and are unwilling to budge after their ideas encounter reality. Software engineers on the other hand are encouraged to ship and not make perfect the enemy of good, because the product of their work is often immediately delivered to customers and turned into value for the business. This puts design and engineering at odds with each other, with engineering often being able to play the trump card because they're self sufficient in developing the end product.

Exacerbating this issue is the fact that design teams often don't report under the same organizational departments as software engineers, and aren't incentivized the same way as software engineers, which produces a lot of organizational strife. Design organizations often consider their final output to be the mockups/wireframes that describe the product, which is thrown over the wall to engineering, at which point they step away from the process and from that point serve only to criticize the end result or ignore it entirely.

The above is my experience and subjective take on the issue, I'm sure others have experienced different. But the above strikes me as somewhat commonplace based on my own conversations with folks in the industry.

At my company we have never had an issue between design and development. Our designers are on the same team as the developers, so we all talk to one another throughout the day.

The tech difference between using Github and Figma isn't a big deal, Figma for the most part put the right buttons in the right places so developers can glean all the right information from a piece of UI to build it (at least in my work building webapps).

I would say the biggest thing we do differently than other places is collaboration with design is happening before any lines of code are written. Design will ask us what UI framework we are planning on using, or if we are planning on just using regular CSS. From there designers will create designs based on the principles of that framework. From there we start building the project and import all the colors, spacing, and other variables from Figma. The actual development is the last step but by then we already know what we are building and have the building blocks in place to make building it straightforward.

I work on a small startup team of 3. What makes my team unique is that I come from a Ux background but pivoted into development about four years ago. As such much of the friction between development and design is eliminated because I speak a common language. My teammates are pure devs. The senior dev has a decent sense of design. Early on we clashed because I felt that I needed to be the final say in design. That was my ego. When I stopped thinking this way, everything fell into place. All of us have a say on all aspects of the project. An inevitable consequence of this was that my Figma designs became a jumping off point for feature discussion rather than a blueprint that was religiously maintained. We iterated in code rather than Figma and we moved faster and smoother as a result. Every day it's a pleasure to work with my team because egos have been removed from the equation.

I'm a UX Engineer and although that means I deal with technical discovery, user testing and the effective implementation of design - It is true that the most challenging part of my day is facilitating communication and helping to resolve misunderstandings and challenge priorities between Design, Engineering, Research etc.

I do this in-person, and also with tools, technology, and documentation.

What I have observed..

Firstly

There is an historical divide and a sense of importance on the part of both disciplines. Each thinks they should have priority.

Secondly

In a Start-up or any company that is working like a start-up to get a product off the ground, we build for MVP and we use Generalists/T-shaped people and we work expediently with a flexible process.. ever heard of a JFDI?

When teams grow and products scale, we tend to hold onto this expedient way of working, because stakeholders do not want to give up the rush of getting what they want ASAP.

Nobody really wants to slow down in order to perform user testing, or implement a healthy process between design and engineering - we have formed bad (although appropriate once upon a time) habits and it's not expected that you will say 'no' upwards.

Thirdly

Having worked expediently, there is likely design and technical debt, this cripples the ability to form processes / better habits because there are almost always things to fix, and changing to a more considered process starts to look expensive when there are alway live bugs to fix.

Finally (Although probably not)

When a way of working needs to change, it is very, very hard to not sound critical of the work that has gone before.

No matter how I have approached it, whether I've met with groups or individuals, if I've been soft or stern.. People are sensitive and resistant to change, and if you are unlucky they will collude and actively work against the effort.

Problems between "designers" and "developers" are usually symptoms of larger problems on the team. People lack trust in each other, and there's an adversarial mindset vs. a collaborative one and a shared goal of solving customer problems.

Well functioning teams don't have a magic guide on how to handle designers. You speak with your colleagues, share context and data, and make the trade-offs together. It's the same with developers who disagree.

Tooling? Pace / Workflow? These are trivial, and in my experience, are not the root cause of why your designers pushes back so hard on everything.

I played both roles in different companies. One thing I found wasting a lot of time on in past companies was the back-and-forth around minor changes like UX copy. Every time I would want a different text in the app I would have to ask the dev to do so and vice versa, I had designers sending me minor changes they need me to fix in the production app. (Shameless plug: this is why I joined working on FlyCode[1] S22)

[1]: https://flycode.com

I have had quite a bit of experience with this.

I'm primarily a native Apple application developer, but have done some backend stuff, as well. I have designed numerous Web sites, but I am not a particularly skilled Web designer.

I was, in the days of yore, an artist. I have also taken numerous design and usability courses, from the likes of NNG (Nielsen-Norman Group).

I'm a passable graphic designer, but don't pretend to be anywhere near "pro" level. I know enough to be dangerous (and use many of the tools).

I have designed a bunch of fancy widgets[0 - 4]. I actually use very few of them, because they are too intrusive.

I am in the "refining UX" stage of an iOS app that I've been developing for the last year and a half, or so. I'm working with designers and testers, to clean up the information architecture, interaction, usability, aesthetic design, and accessibility.

For me, the most valuable technique, has been rapid, high-quality prototyping. I have been abusing Apple's TestFlight[5] beta release system, and have been using it to make regular (usually, a couple a day) releases to the rest of the team, who are mostly non-tech people. I've made over 600 releases. The first release was made less than a month after first code submission.

The way I use it, is that I run what I call "constant beta." The app is always at "ship" Quality, even if incomplete. This means that the code people get, is fully operational, for the currently developed feature set, and they aren't using some kind of "lash-up" kludgy throwaway code. They are working with the actual code that will ship.

This has the advantage of constant vetting by Apple. They don't test TestFlight to the same level as the App Store, but they look for things like unsupported API usage, code signing issues, and obvious quality issues (like crashes). In at least one case, their testing found a crash that I missed.

Once the first release for a version has been vetted (takes a day or so), subsequent build releases, within that version, are approved almost immediately, so I get quick turnaround.

If the testers encounter crashes, I get a fairly useless report. If I use a Ouija board, I can often figure out the general part of the application affected.

With this workflow, we can have a highly iterative process, with aesthetics, usability, and general UX, being tested, almost from the start.

It also means that integration testing (the most important kind), starts almost immediately, and continues, throughout the development lifecycle.

It also means that I throw away a lot of good code. Most of those widgets I referenced were once in the app, and we decided not to use them, so I broke them into open-source packages, for reuse in future projects (I tend to eat my own dog food. I have a lot of packages in the app).

I'm pretty good at interpreting designs. I can accept Figma, Photoshop, Sketch, Illustrator, Napkin Sketch, or Hand-Wavy Verbal Description, and turn it into UX. I usually have something for the designers to try out, within minutes.

Most of the actual app assets are generated (and stored in the app) as vector PDF, via Illustrator, and I will often redesign raster art, into vector.

The designers and non-tech stakeholders seem to like it.

WFM. YMMV.

[0] https://github.com/RiftValleySoftware/RVS_Spinner

[1] https://github.com/RiftValleySoftware/RVS_MaskButton

[2] https://github.com/RiftValleySoftware/RVS_Checkbox

[3] https://github.com/RiftValleySoftware/RVS_RetroLEDDisplay

[4] https://github.com/RiftValleySoftware/RVS_AutofillTextField

[5] https://developer.apple.com/testflight/

The big pain points have been...

People that feel strongly about the solution but don't have much evidence it's right for the user or business. I've seen that from both ux and engineers. Getting both groups more exposure to user feedback and customer feedback helps. Dogfooding also works great when applicable.

Focusing on details over the big picture. For ux I mean the emphasis on pixels over interaction design. For engineers I've seen it too. Exposure to user feedback helps. PMs help. A calm discussion of tradeoffs involving delivery dates help too, or budgeting post launch time to improve the feature helps smooth out the initial debates over scope. Doing rapid iterations with limited groups of users also helps.

Some people feel that they've had unfair compromises so many times that they're no longer willing to compromise at all. I've seen that from both ux and engineers.

"It is critical for a designer to go all the way through the process. Even if they aren’t actually the ones shipping production code—that knowledge about how things work tightens the relationship between them and those they work with. Designers knowing how to code and talk to users cuts down on wasted communication. It creates a tighter connection with other teammates and ensures that design is part of the process from start to finish."

That quote is from an interview I did years ago when Cap Watkins left Etsy to become Buzzfeed's VP of Design. It has stuck with me ever since.

He's speaking about designers, specifically. But I think it's important for all parties to understand as much of the process as possible. The better the understanding, the tighter the feedback loop.

The interview for anyone interested.

https://solomon.io/portfolio/cap-watkins/

I find a few sources of tension

- designers who want things to be "pixel perfect" while devs may cut corners to ship it quickly

- devs who unilaterally alter the design without discussing it with the designer, because they think it's better

- designers who design overly elaborate, customized UI solutions when simple, existing ones do the trick, and then are frustrated when devs push back

- designers with little technical understanding of things like react designing things that seem simple to them, but are complicated to implement, and then are frustrated when devs push back

- designers who feel like they have the final say over UI, while devs view it as more of a suggestion

I don't think I've really solved these super well in larger companies, but where I've observed it not be an issue is when people are closely connected to the product being built, and understand it (even better if they are users), and are working together directly (without product managers as a go between). Not to be like a Marxist, but I think it might actually be caused by alienation from one's labor. Designers design a thing in a vacuum, not fully understanding it, hand it off to devs. Devs code it, not really participating in the creative process. When they are an integrated team solving a problem they understand, collaboratively, it works better.

Align the teams on things they both value: system thinking.

The best way I've found to get designers and developers to produce 1+1=3 outcomes is to show developers the design system (styleguide) and show designers a development process (functionality > fixes > finesse) that works.

Inertia slows team progress when designers hand off fully-finessed, high-fidelity screens that would take considerable time to implement.

Instead, ask your design team to start with functional lo-fi designs so engineers can have a basic UX/UI to dev against. The audience for the lo-fi is mainly internal, think pre-release/private alpha.

Some of the early development work is around feasibility, which doesn't require all the finesse designers value.

After you have functional lo-fi's, the design team can ship mid-fi screens that have fonts, colors, etc. Hold off on gradients, shadows, and micro-interactions. Lottie animations can come later.

At this point, you can start user-testing features and validating each hypothesis. It's much easier to iterate development on mid-fi's vs. hi-fi's. Especially when you need to make changes. Making changes at the mid-fi stage de-risks your startup.

Now you've done design and development in tandem and you don't need long design cycles that take forever to implement and de-motivate developers.

Nothing will motivate developers to implement your polished hi-fi screens more than having a validated product.

Hope this helps! @erikkjell

I've generally only worked with designers in a mobile app context. A few of the things I do as a dev which has improved my relationship with the design side (Although the designers I've worked with have changed over time and that definitely is a part of the better dynamic. The initial designers I worked with came from print media and had no mobile app experience):

- Work in a Storybook-like sandbox for components. This is the single best change and a lot of other stuff comes from this in terms of standardization and common language. By working on components in isolation, its a lot easier to both flesh out edge cases as well as argue that certain edge cases need to be handled ("theres no guarantee about how this component will be used so we need to make sure we have some answer for X"). It also _massively_ speeds up iteration speed

- Put in generators/utilities that do things like generate your buttons/labels/colors. This lets you standardize on a smaller palette and also give you a choke-point to flag "illegal" values (e.g. trying to set a label font size to 8pt, or a button tap target to 36x36).

- Learn some UI/UX! Reading the material design docs gave me a much better understanding of grid layout and color design systems.

- Coach the designers on the platform expectations especially around tap targets, font sizes, and navigation patterns. You should usually stick to your guns on this stuff.

- Understand that your job as a dev is to _try your best_ to implement the design as presented. This means you should at least make an attempt to bring their creation to reality, after you adjust it to fit within the confines as described above.

I have a "systems" business analyst who works with designers. They are the first guard to prevent a design that looks right, but makes no sense in terms of entity or data modeling. If I think things are getting too complex from my weekly check-ins with the design team, then I will send a developer to sit in on the meetings.

What I do probably won't work for you, because team communication is incredibly political. You need political power to have your "guy/gal" sit in on another teams development/design process. Again I want to hammer home, the political nature of this. You need to cultivate good relationships first and foremost. The problem isn't tooling like Figma or Github, its relationships and trust between teams( assuming everyone is competent).

I have rarely butted heads with designers. Most of the time it's mutual respect for what the other does, and both sides have at least casual interest in the other side's profession, so collaboration usually goes well.

Now, if you want to talk about systems/devops teams or IT departments..

Agree with a lot of comments here about more/better communication.

Depending on the size of company you're in there is a specialized role that bridges the gap. At Google it's called a UX engineer, other companies call the roll Design Technologist (DT).

DTs have a technical understanding of what's possible but work in UX and typically produce prototypes to assess technical feasibility of solutions. You can use these prototypes for stakeholder reviews, usability testing and they really derisk the build process.

We had a really bad time of changing things in production multiple times which would take forever before we started prototyping and practicing iterative design and design thinking.

Personally in my dev career I've only ever really had friction with design teams when they did one or more of the following:

1. Changed designs offcycle without updating tickets.

2. Be oblivious/ambivalent to accessibility requirements of UI, or what standard user interactions with existing sites is like.

For 1, I don't even mind as long as the changes are small. There have been times that I've met with designers, we settle on a plan of action, I start working on it, and then they change the whole layout because of some sort of need from higher up. I wasted a few days working on a non-finalized design when I could have been working on something finalized. Solution was to make sure that the higher ups are in the initial design meeting so we don't get any surprises. Yes, their schedules are always packed and it means we have to push back meetings all the time, but it also generally means that we get 1 meeting to get everyone in agreement (even if it's agreement by force at the hands of the hippo)

For 2 there wasn't much I could do other than push back when they present a design that is inaccessible or a dark pattern. If it's an external application I always lean on "I'm trying to save us a ADD lawsuit", but it's always harder with internal tools. I get things like "We don't have any blind sales reps" or "no one at this company uses a screen reader" but I don't let up. Accessibility when done right doesn't just make an application usable to a group of people who would otherwise be excluded, but it also makes applications easier to use period. No I'm not going to rotate that text. No I'm not going to have the text be an svg unless it's a logo. No I'm not going to make the text that light on a light background. Designers generally don't like when they're told a design flat out can't be used but in my experience any application that is written without accessibility in mind, will be rewritten for accessibility.

There's always exceptions but this has been the bulk of my experience. Most designers I've worked with understand where I'm coming from which is a big help, I can only count on one hand the number of times the relationship has been outright adversarial.

I haven't really had this problem (I'm a developer) because I used to try to do some form of UX design way back in the day. And the more I did it, the more I realized I suck at it. So I can empathize with their needs and truly appreciate someone who can do it well.

My recommendation would be to have those with a problem do the other person's job for a week and "sorta" hold them accountable for the outcomes. Give them the mere threat of some minor wrist-slap should they fail to meet a seemingly reasonable objective that the other could do in a week, and then after the exercise explain that you never had any intention of actually delivering on that - in this case - just to make them have some skin in the game so they didn't dismiss the exercise.

After about a week of the shoe being on the other foot, I think the appreciation for the other discipline will become genuine, and then you can start working on having the right conversations about tooling, concerns, workflow, language, and so on. But developers have got to understand that UX design is so, so much more than "pretty pictures" and UX folks have gotta get it through their heads that engineering is FUCKING HARD, and we're way more than mere "code monkeys" over here.

Until that mutual respect and appreciation is established, none of the other stuff matters.

If you're familiar with Clayton Christensen, he has a theory called "jobs-to-be-done".

The basic premise is that you "hire" an object/person for the "job-to-be-done" which is usually the outcome you're after.

I like to use this thinking in problems like this.

Developers are not designers and vice versa. You don't want them doing each other's job in most cases.

You cannot give too much of a solution to these two specialties or it makes it near impossible to work together as there isn't enough slack / autonomy to do their actual job.

What they both can share is a common "vision" for the sought respective outcomes. With the stage set, it is usually worthwhile to have the developers consult the designers and vice versa throughout the process. The more each side educates each other, the more "correct" and "true to the design" the result is.

The one thing I have noticed in a big tech career is that people simply just don't communicate with each other. Majority of these problems can be solved if you put the two disciplines in the same room and give a challenging problem to solve with the common vision set. You'd be surprised at all the amazing ideas each party has when they can express them to each other.

As a frontend developer I've found the best designers have some development experience and likewise a good UI developer should have some basic understanding of UI design.

As a quick example at one place I was working a designer came up with this beautiful new site menu which I was asked to implement. Lots of animations. Items would slowly disappear depending on the space available. Things would resize and move around the menu necessary to look right. From a design perspective it worked great, but as a developer I knew it was going to be a nightmare. I knew even if I could build it as intended it would be overly complex, prone to bugs and difficult to maintain. A good design (and designer) is one that considers the limitations (and possibilities) of the technology and designs with those in mind.

Similarly I've seen great designers who understand the technological constraints well have their designs ruined by developers who implement them without care. For example, making sure things line up correctly or that padding and margins are correct and consistent are things that I see bad frontend developers miss a lot.

In my experience the best way to work is by sitting the developer and designer next to each other. It's less about tooling and more about communication. Ideally a designer should be asking questions about how easy something will be to implement as they're working on the designs, and a developer should be asking questions and showing their progress as they implement. This way you avoid situations where designers are building things that are overly complicated to implement and developers can implement the designs as intended while being able to flag up any challenges that might arise during implementation.

The absolute worse way to work is to ask a designer with little understanding of the system to design something. Then once they're done send that design to a developer who has no direct line of contact with the designer to build it. I've seen this done before and every time it results in bad designs and bad implementations - regardless of the ability of the individuals involved.

In my personal experience there's zero tension between myself and designers. The tension for me is when I'm not able to work as closely with a designer as I'd like to because I know I'm going to produce substandard work which I don't really want to put my name to.

This is what PMs are for. A good PM should have the skills and knowledge necessary to turn engineering limitations and design lofty goals into an achievable plan.

They can't work well together because they speak different languages (like React vs Figma), thus the friction.

One thing they can do is they can come up with a design system. Let them do the case studies together and came up with the solution together.

A design system, in essence:

- is a common language they can communicate with.

- is their consensus that they could agree upon.

- if they do the case study right, it will be a set of sane designs that works great on the target platform (Web, mobile, etc.)

I work at an ad agency designers design up a visual its looked over by a developer before it goes to the client to make sure they don't design something that can't be built.

> do you also find that there's a lot of tension between developers and designers?

Nope the designers can use what ever they want I take photoshop, illustrator, indesign, xd, figma what ever and build it thats my job. Designers make the decision on what tools they use for their job I decide what tools I use for my job. Let's face it once you learn one design tool the rest are fairly similar.

Any pain points I have seen have been from a lack of communication, designers don't know what developers know and they need you to tell them. This is a two way street I see developers turn their nose up at designs or give criticism on the design like the choice of colours when they should feedback on the build ability of the design.

Respect your designers they have a very impressive skill one most people lack and under appreciate. They are not like clients they understand their skill and industry as well as a developer does, treat them with the respect that skill and understanding deserves (don't talk down to them).

Once built designers can come across as critical of developers they designed a masterpiece and they want it pixel perfect. They often feedback that it needs more spacing or on small alignment issues. I could hand wave this as unimportant it won't look any better if I do what they say but I don't I take their skill and feedback seriously I fix the issue and it always looks better and they appreciate my attention to detail, the client is over the moon.

Work with your designers and they will make you look great thats their skill use it.

> For those working in tech/software development teams - do you also find that there's a lot of tension between developers and designers?

Quite the opposite: I typically tend to get along quite well with designers. Perhaps one reason is that I am myself a little bit on the "artistic" side of programming (e.g. with respect to elegance in code).

So, assume that in most cases the designer knows a lot more about what (visually) does look good and what does not and trust his judgement.

This, of course, assumes that you work with a designers whose artistic style is a good fit for an artistic style that you, as a programmer, appreciate for the project (e.g. should the GUI have a minimalistic, or skeuomorphic, or abstract, or realistic design?). I think that sometimes conflicts between designers and programmers are rather about having a very different opinion/vision on this topic.

What value does a designer bring to a project if he is not trusted in his design judgements and design drafts (at least in most cases)? He is intended to be the expert on this topic, and this is part of his role in the project. If such a trust does not exist, the designer simply cannot fill his role in the project.

Just to be clear: a quite similar statement holds in my opinion for choosing suitable programmers for your project(s) (even though I think that the very different programming styles that do exist are much more difficult to distinguish for non-programmers than visual styles are to distinguish for non-designers).

P.S. "Managers", on the other hand, are often a lot more difficult to handle for me than designers ... I can imagine that my "rather hands-off and trust" approach that works well when working with designers might violate some vanities of some managers. ;-)

It really depends on your company processes and culture. I've seen most trouble when SaaS companies expect frequent/incremental delivery of features from engineers, but UX is not part of team but some thing apart that hands over pixel perfect mockups worked on in isolation from the dev team, and that doesn't consider incremental delivery.

In my opinion, design tools like figma or adobe xd are abstractions away from the tech stack in which perpetuates more roles in which there doesn't need to be.

A UI/UX Designer should be competent in CSS in which the browser should be their whiteboard / canvas.

Abstracting the design portion away to other platforms only furthers that gap between design and development.

An optimal and streamlined design regiment is pen and paper straight to css.

Hire designers that are good with css in short.

To bridge the gap between design and development is not to find ways in which those teams communicate better, but rather a fundamental change in how we look at designers and their competency.

To further that point, if we take a look at motion design and animations, it should not be the case that a designer comes up with a wireframe and leave it to the developer to build that for building animations is out of scope for a dev task, but rather these tasks should be soley on the ui/ux designer themselves.

The answers here focus a lot on improving collaboration. Almost all challenges in running a company come to this and there definitely is a lot you can do there. But it's hard and few companies pull this of and no one really wants to admit it. You usually get vague suggestions like "better communication" or "work less in isolation"

I've taken a different approach and I have become extremely conservative in extracting out responsibilities in a dedicated role.

I no longer try to build teams with the design role externalized in someone else, I just focus on finding developers who are also good designers. This is hard but I'd rather fight this battle than the collaboration one

If there truly is a 10x designer that wants to work with me then it's worth it, otherwise it's synergy of having one person be able to fully ship on their own outweighs the overhead of collaboration

From my experience. If you are a junior developer, you are screwed. If you are senior you have leverage.

Designers don't understand the hardship of developers at first, they think they can do whatever they want to you. You gota teach them. Threaten to leave on a conflict. Make them understand those roller coasters are hard on you. Teach them easy rules like: a dev gota finish what he started, some things are virtually impossible to do (spaghetto code is real), you can't get pressured to deliver every day, etc.

If you are thinking about work outside working hours for a long period of time, people are probably hard on you. On average a designer don't think much about work outside of work pretty sure about that. They drink, they fool around town and they get laid. As a developer you deserve that as well.

Once that's understood, from my experience you should have fun together.

I love designers! Especially when they listen to devs, or even better, can write CSS themselves. Devs should be in design review meetings, designers should be in the conversations about functionality. If you want a smoother workflow, make the communication happen.

The teams I had worked with since ‘16 had not had that tension. I think it is because there is a shared common ground of getting to product fit and developing a great product together. I see the developers respecting and valuing what the product team brings to the table, and the product team respecting and valuing what the developers bring to the table. It helps that there’s a strong mission, a worthwhile product, and that attracts people who want to contribute to society in that way.

No, not really. I've worked all hats and never really seen much disconnect, except when there was no communication - which usually starts with ineffective (ignored) comments from the people not communicating. This usually implies the other team is not paying attention and should, before the complete disconnect happens.

yeah I've seen both front end (user interface) and developer (backend/hardware/...) groups do this. And slightly more often - but not exclusively - the latter.

I'm going to shill a little bit, at Kitemaker[0], we use Kitemaker to solve this problem ;).

The typical workflow is that someone creates a work item to track some improvement or new feature. There, the idea is explored before any design or code work is done so that everyone involved understands what the goal is.

Then our designer will go and create some mockups and in figma (and link the figma in the work item). We'll then have discussions about the design, one nice thing is that the figma comments appear in the activity panel of the work item in kitemaker. So even if designer asks a question in figma, the rest of the team can see that in kitemaker (since programmers rarely live inside figma).

Once we've addressed as much as we can at the pure design stage, we'll start implementing the feature in code in a branch (that's linked to the work item). If anything comes up in development that we didn't foresee, we'll discuss it in kitemaker/figma/slack (if it's slack, we make sure to mention the work item so that it's picked up by the integration and shows up in the kitemaker activity feed).

As soon as something is even remotely "working", we create a w.i.p PR which spins up a test environment in Cohesive[1] (no affiliation, just a customer) and link to it in the work item. This lets the designer play around with the feature as it's developed and start giving feedback or adjusting the designs as early as possible.

The key is really just communication as early as possible and throughout the entire process. To make this more tool agnostic:

1) Make sure everyone understands what problem they are trying to solve for the user.

2) Get designers to share the designs as early as possible so that engineers (and others) can provide feedback.

3) Have a way for engineers to share the w.i.p in a test environment as early as possible so that designers can adjust designs or give feedback to developers.

4) Have a way to keep references to all the discussions in one place and visible to the entire team.

[0] https://kitemaker.co/

[1] https://www.cohesive.so/

This has been an issue at every team I’ve worked at.

My current team spontaneously started using FigJam for a variety of things (it’s like a real time multiplayer whiteboard) and I’m starting to think a cross between FigJam/Figma and JIRA/Trello would be a useful product. Basically tickets are directly associated with or “on” mocks, perhaps like annotations.

Maybe a good weekend project for me haha.

The fact that front-end developers and UI designers use different tools leads to them working separately, which is the actual problem.

Unfortunately, this is ultimately a talent/hiring issue, as it's easier to hire developers who have zero design experience and vice versa. When you treat people like interchangeable cogs, you don't get good collaboration.

technical beauty is rarely visually beautiful

acknowledge that. decide that you serve the customer.

sometimes the customer cares to be dazzled others time they just want the thing to work.

often details of design and technical implementations don’t matter so it’s easy to bikeshed.

as trite as it is the solution is honest and open communication

I’ve been working very closely with one over the past few months and the biggest improvement is clearly defining terms and making sure we always stick to them

We realised we were using the word design for like 4 different things and often two or more interpretations were valid

Resolving Conflicts Between Designers And Engineers https://news.ycombinator.com/item?id=32160398

as a dev, i hate working with obsessive ux or ui designers.

they don't seem to care that i have more pressing concerns than whether something they've been staring at for 6 hours is 1 pixel off.

Calmly explain to designers, that their purpose is to serve the developers' needs and they should refrain from bombastic designs and focus on technical feasibility.

Common goals, clear processes, trust, and open, well-developed lines of communication.

Like everything else in life involving more than one human.

I find that when there is tensions its almost always indicative of the overall mismanagement of the project.

Stop hiring designers that can't code up what they design. Seriously.

As someone who has worked in both fields for almost equal amounts of time I can have some thoughts, not all true all the time but certainly some common things I've come across!

I think the one key point is that developers and designers don't always have the same target user in mind!

- developers are often only brought in when something needs to get built, at this point everyone has it in their heads that the thing they've designed is perfect and totally technically feasible, it hurts when a developer tells them it can't be done. If this happens even once where a developer said no when it could in fact be done - every developer is affected!

- designers are perfectionists but so are developers! they just care about different things.

- designers perceive developers as lazy, that is they view the idea of taking a design and making a nice neat set of reusable components and layouts as lazy. To a developer its fun and a challenge and requires a lot of work to do so. Its also seen by some designers as a challenge to their design skills - why would you want to reduce something so carefully thought through to something so simple?

- developers have a bad reputation with designers usually because of outdated ideas about the sorts of people who become developers but also because I'm fairly sure a lot of the communication between developers and designers happens when a developer has been interrupted and no one is in a chatty mood when they're out of the flow state and have to start all over again.

- they don't always share a common goal - a designers primary focus is the user (and sometimes their portfolio), a developers primary focus is the maintainability and how neat the code is of the system (and their portfolio!). A lot of clashes seem to happen when designers implement something new and different or when a developer simplifies things.

- a hard one but both need to be less precious over their work. Pixels aren't perfect, code doesn't need to be beautiful, learning to let go of control of a design or a codebase is a skill!

Some things that help

- teach designers to code

I worked with a designer who was adamant about things being pixel perfect until they learnt to code, you could track their proficiency as a developer through their designs. When they first learnt to code the designs were boxy and simplistic, as they progressed they became more and more advanced and creative but they never went back to that same abstract style they had before they learnt to code

- teach developers to design

Teach design principles, research techniques, introduce them to the users and the clients. Designers often have more of a connection with the users simply because they've studied them to understand the users problems, developers are rarely given the opportunity to do that.

- include developers early in the project

have a system in place so that at least one developer is on the project from the beginning, the cost of them spending a day or two a week just attending meetings and maybe not even saying anything to contribute pails in comparison to the cost of a build up of friction between design/development teams.

- include designers in the tech project

depending on how your company is setup do the same as above with designers, the more often these joint ventures happen the more each learns and the easier things become

- don't hire developers who look down on designers, and vice versa!

One bad apple can ruin an already fragile relationship, don't encourage it. Asking questions about how do you like to work with designers or researchers or developers in interviews will give you an idea of what they think of their colleagues. If someone is the best developer/designer in the world they are not worth having on your team if they make the atmosphere tense and uncomfortable for everyone.

- have an index of terms and processes

some people don't like to ask what does something mean especially if they think they should already know it. Document your deployment process, explain why it takes so long to deploy a small fix to production. Explain why you decided on that shade of blue, what meaning does it convey how does it relate to the other parts of the design. Why is it important that only some buttons have 2px border and others have none - if its just for aesthetics say so!

This is normally where a quality Product Manager can shine.

Well, UX is bullshit (otherwise there would exist software made after 2000 that has at least a decent GUI instead of complete nightmares) so you'll need to fix that first.

Sympathy is what it all boils down to.

Try https://www.specifyapp.com and thank me later!

I think there are a couple dimensions to this problem, and I've observed the balance points vary wildly from company to company.

Probably the largest axis I'd consider is "What do incentives look like and how does someone know if they're doing a good job?" Many software eng companies I see bring designers in later in their cycle; they aren't seen as an essential skillset for a young company proving out technology with alpha adopters, but that means by the time they're added, they're working on projects with histories, ingrained UI metaphors (often chosen by the software engineers), and a culture that already sees them as default-superfluous. Google used to be notorious for this, and they burned through UI designers at an alarming rate as a result.

This is not an impossible situation, but you have to frame the problems the designers are solving to make them winnable. Designers want to see their ideas implemented (obviously), so it stings if they put in a lot of work to see the idea tossed because it doesn't fit the (crappy) design that had historically accreted. So a couple of approaches I've seen work alright:

- get your designers on greenfield projects (and rotate them; spread the love so that designers don't end up pigeon-holed playing patch-the-crap while other designers are enjoying seeing their work out in the open)

- give designers the freedom to explore novel ideas outside of the current model, but make sure when they do so they have the understanding that they're trailblazing and the final product may not look like their trail. This benefits both sides; engineers are freed up pondering the UI side of things, and designers have the opportunity to create something aspirational for the engineers to pursue. Note that to pull this off, your designers need to know how to user test a design, and should probably be operating off of either existing stories (what problems users try to solve today with the current implementation) or new stories the company wants to implement in the not-too-distant future.

- pull engineers into the conversation early, but make sure the designers are driving the conversation. However, make sure both sides settle on a comfort level for blue-sky design vs. discussion of implementation and nuance. Left to their own devices, engineers have a tendency to dissect, pick apart, and deconstruct a design because, hey, that's their job, they have to build this thing.... So if they drive the conversation, you tend to end up with a design that looks like what's already there. But designers may lack both the technical knowledge of how things work under the hood and the historical / cultural knowledge of weird corner cases that the existing warty design grew support for. Designers are in a prime position to pull those needs out of the existing solution and consider if there might be a better solution.

If you're a software engineer interacting with a designer, the best approach I've seen to make those meetings constructive is to phrase concerns / questions about the design in the form of a user story. "I see in the design you have a multiple-choice list here... We do have clients that want both pepperoni and sausage on their pizza at the same time. Can we support that use case?" What I don't recommend is getting drilled down too badly on the engineering minutiae ("We can't support that because the data'd have to be in a tree and we don't sort it that way") until, possibly, much much later meetings; for one thing, designers are most valuable when they can step back from the implementation minutiae, and for another, if the design justifies the cost of supporting it you end up building that tree.

The overarching takeaway piece of advice is there's no substitute for working together... Communication / collaboration challenges are only ironed out by interacting until both sides find a happy medium. Every team sorts out what that happy medium is on a case-by-case basis.

This is essentially the challenge that I've built my career upon solving. I actually prefer to back it up one layer further and suggest focusing on how to get the business and developers to collaborate.

My answer to that question--which I know isn't the original but I think helps solve it--is that bridging the gap is, to a significant degree, the designer's job.

Note that I'm saying this as someone with a dev background but who formally took the UI/UX path, so there's definitely an "if all you have is a hammer" angle here. :)

My view: It is on the designer to have a reasonably strong technical understanding of what the application can and cannot do. IMO, design as a discipline is at least 50% engineering, because how it works under the hood has a dramatic impact on the end user experience.

---

Tips if you're on the design side:

- Ask technical questions, even if you don't really grasp the terminology yet. For example, where is this data coming from? Push the dev team deeper than broad answers ("the data lake"). Is this data cached uniquely for our application? How often? What's the response time? Does it come back in one big query or 15 little ones? Not understanding this results in annoyed devs asking you for loading states you didn't know you needed and will annoy you with a laggy app.

- Ask what libraries and frameworks the dev team is using. Read up on how they work. Walk through demos. If dev wants to purchase XYZ charting library, invest in understanding how it thinks so that you don't design something impossible. Conversely, once you have a good understanding, you're in a much better position to push back when it really matters. By making 90% of the app compatible with the dev team's tooling (which, remember, may have been forced upon them by politics elsewhere), you're buying goodwill for the really important, high-LOE custom bit that really should override dev reticence sometimes.

- For most projects, UI/UX is all about designing systems. The art is in the elegance of the system. The consistency, how it all meshes together, how easy it is to build upon and evolve. Express yourself in the beauty of that first, then add aesthetic exploration on top.

- And I can't emphasize this enough, if you can build your skillset to the point where you can build an average application in a rudimentary sense (i.e. it works, but isn't wired up or scalable), you will open so many doors and understand the dev team so much better.

---

Tips if you're on the dev side:

- Work to view your designer as your advocate and help them want to be it. Your designer should understand the implementation details 90% as well as you do. If they don't, help teach them. Show them how the framework thinks and why you chose it. If both sides come from years of cultural antagonism, this will require a lot of patience from both players.

- Remember that the designer is often reacting to feedback and external pressures just like the dev team is. They're trying to strike a balance between their best judgement (both as an individual and on behalf of users), the dev team's needs, the dreams of the business, and many other stakeholders who may or may not understand the process.

- Understand your designer's background. Even today some digital designers come from traditional design backgrounds and are learning to adapt to flexible viewports, etc. Note also that design tooling, especially in years past, could easily produce designs that exceeded the capabilities of HTML/CSS/et al. at the time (consider Photoshop CS2 vs IE6). It took deep technical knowledge and sometimes reversion of design best practices to reign the tooling in to something that a browser could efficiently support. I say this not to absolve responsibility, but drive empathy. :)

---

Also, shoutout to the answers by thomasqbrady [1] and apricot13 [2], who are capturing the "empathy" message I was trying to go for way better than I did. :)

[1] https://news.ycombinator.com/item?id=32153989 [2] https://news.ycombinator.com/item?id=32151110

There are a lot of reasons you can end up in this situation, and as many solutions to apply. Identifying the problems, choosing the appropriate solution and implementing it is a job.

You cannot learn an entire job from a HN post.

However, one solution can be used to solve all those problems: put a product manager in charge with a background in ergonomics (in the steve krug sense), and have this person steer the project from start to finish, with the legitimacy to direct people effort and choose policies.

The hard part now becomes to hire a good one.

A good one will know programming (Xor design), ergonomics and customer support. This person will know how to talk to the customer/end users, to the boss, but also to the designers and the devs.

Because eventually that's what it is about: having a good product vision, but being able to make sure this vision matches what the customers need, sell that to the boss, then direct the team to get it.

Expecting all of those people to behaved optimally is like hopping to win the lottery. It may happen, but chances are low:

- the boss may want fast things for cheap, or have another agenda/point of view about the project

- the customer don't know how to express what they really need. Sometimes they don't even know before you ask them.

- the designers are skilled at making visual things, but not all of them get out of their way to make sure they are making the visual things that are needed.

- the devs are skilled at making programs, but not all of them get out of their way to make sure they are making the things that are needed.

- they don't talk the same language, so every conversation means one should be capable and willing to make the effort of taking in a foreign jargon and context.

So unless you are very lucky to have most of those doing exactly what you want them to do, you need somebody that will steer the ship. And it's WAY easier to hire one single person with those skills than to make sure every single team member you hire is going to be able to see more than one's own area of expertise.

If you can't hire that person, then the next best thing is becoming that person.

In that case, you may want to read "Don't makes me think", all 37signals books, and "the mythical man month" for a first step into the marvelous world of building products with reality as it is, instead of what people wish it to be.

The rest of course is a lot of practice, talking to a lot of bosses, customers, designers and devs, then try to get the product in the right direction.

It's a long (yet interesting) journey, though, so good luck.

PM has the last word.

This topic is near and dear to my heart. My encounter with this issue, and the way I approached it, have defined my career (been doing this about 22 years, now, and have gotten to work at some dream jobs with names you've heard in the meantime and currently). I did a few conference talks about it, but I won't link those unless someone is curious, just to make sure it doesn't seem like I'm trying to get views or something.

TLDR: No shock here, if you think about it long enough, but the answer I found was empathy. This professional relationship between designer and engineer (which I've found through many interviews—formal and informal—to be the same for architect and engineer, stage designer and carpentry shop, etc.) is still a human relationship. It's easy for a lot of people to forget that, or to think that professional relationships don't require emotional intelligence/work/etc.

Fairly early in my career as a front-end engineer I landed at a fancy advertising agency. We built high-end interactive marketing sites for big names. We had a lot of hot-shot designers who were VERY excited about themselves, and were, frankly, watching Mad Men a little too closely and drawing the wrong inspiration. It was quite easy for me to start blaming them for the parts of the design -> engineering hand-off process that weren't working. Their designs seemed to ignore the constraints of the technology, the budget, the schedule, etc. And several of them jerks who would quickly throw the engineers under the bus and say "the engineering team at the last place I worked could have done this in a week."

Then one day I started a new project with a new designer. He dropped by my desk with design specifications that contained all the info I normally had to go spelunking into design source documents to try to ascertain myself. This guy had put them all in one place for me to make it easy. I was shocked. I noticed something that wasn't technically feasible in the design right away, and thought I'd test the waters. "Could we do this differently? The technology won't allow this exactly because of [blah blah blah]." He listened. He asked if we could both think about it a little longer, him thinking of alternative designs and me seeing if there was some approach I hadn't thought of that might make it possible.

The next time I spoke with him, as he was about to walk away, I said, "Hey, quick question… how come you're not an asshole?"

I'm so glad I asked.

I've already gone on a while, so I'll try to summarize. Essentially, he told me a story from his days in art school. Final exams, which for his art program meant turning in a lot of finished graphic design projects, which meant getting a lot of digital artwork printed, which meant going to a print shop and handing over all the money left in his bank account and then just sitting there for hours waiting for the prints, realizing that he had not control over what happened at this point. Did the printer install the fonts the way he'd asked? Were the color spaces configured correctly? Did the printer know what they were doing? Were they any good? There wasn't going to be any time to re-print (let alone enough money to pay for that), so his final exam was completely in the hands of this printer.

"That's how we often feel working with engineers." He said. "We turn over to you design files that we're proud of. They're beautiful. Then we just have to wait and see, a lot of the time, what actually ends up getting shipped. Often what shows up doesn't resemble our designs. The wrong fonts, the wrong colors, padding, margins. Sometimes the layout itself isn't even close. And we're powerless to do anything about it, and if we speak up too loud we're called prima donnas."

I immediately realized how I'd been complicit in this pattern so many times. How many times had I totally missed things like padding/margins that didn't matter to me because my untrained eye couldn't even see the difference unless it was pointed out to me? How many times had I said "eh, good enough" rather than trying a little harder, or going back to the designer to see if we could find a middle-ground?

I thought of the design specs he'd dropped off and how helpful they were. I realized that the only way forward was to mimic his style: respect for each others' disciplines, empathy for the struggles that each of us had in our work, dedication to work together—to set each other up for success and put the quality of the work before our own personal convenience.

For me that approach got me jobs I thought I would never qualify for. I got so good working with designers I became one. I've worked as a front-end engineer, a design technologist (hybrid designer-developer), and even as a straight up lead designer (UX/interaction design) for the past 15 years. My career has been rewarding (getting to go to/speak at conferences around the world, getting to co-author an O'Reilly book, etc.) beyond any dreams I had early on, and I think I owe so much of it to that designer and his lesson in empathy.

This is a side-note that might be as important (or more so) than the main thread. Why was I able to empathize with him so quickly, instead of getting defensive, as was my wont at the time (and still is more often than I'd like)? I think the key was the STORY he told. It's so easy for us to drop ourselves into a story as the main character. When he told that story, I was the art student frustrated with the printer. When the tables turned and I realized I was actually the printer in this story, it was a powerful moment because I had put myself in the designer's place. My defensive instincts were coming out in defense of the main character of the story (me as the designer).