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

Agree. In my experience, the design team tends to work closely with the client and the dev team is either silent or left out. Silent, because offering opinions on how something affects the backend may be completely moot when the next iteration is developed; or left out, because the dev team can't communicate "you can't do that" to the client in a way that doesn't sound annoying.

The project manager's primary job is to keep the client happy, so they tend to overpromise. Which is weird, because (especially in Web design) they client was more or less happy with the limited set of functionality that Facebook gives them. They don't endlessly complain to Zuckerberg that their business's page is slathered in Facebook Blue, but if the Web site's buttons aren't the precise shade of mauve that matches their CMYK offset press business cards, they pitch an unholy fit.

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.

IME the primary friction point is constantly having to ask designers to consider transitional and error states, and constantly having to ask for image files to be shared in a consistent size (including consistent padding).

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.

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.