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

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.