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

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

> "But... you ONLY did a wireframe of 3 screens, for iPhone 13 only, in portrait, and ... we already have to support desktop/tablet/mobile."

> "Stop deviating - we already interviewed customers!"

> "But... you don't actually show what should happen in various hover/transition states. You haven't accounted for multiple lines of text in these screens. You haven't accounted for different font sizes... etc"

> "Stop deviating".

I've worked with a lot of designers in my career. It has never gone the way your examples went.

A conversation between colleagues with context provided is enough to allow us to work through differences. Explaining that the animation they're suggesting is bespoke, requiring more work across different browsers to ensure behavior and performance is what we want is enough to move us to something more simple, for example.

What I do run into often is developers without an eye for detail, who don't understand things like white space, padding, colors, and assume they're unimportant who then are told they're not and get upset that they need to go back and fix CSS and layout.

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

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.