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

The max issues weren’t corner cutting on quality, it was corner cutting on investment in a new design and type rating and available pilots.

Although it could have quality problems; stories of 787 quality problems are concerning. But quality skimping was not the cause of the 2 fatal crashes

FAANG has evolved from the acronym about rising stocks into a term representing companies that pay high salaries in SWE circles.

If you see FAANG+ they might be referring to companies like Data Dog or SalesForce or Crowdstrike, companies that pay extremely well but maybe not as much as Meta or Netflix.

At least that's how I read it.

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.

Lookup product management. They typically do this.

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.