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

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.