Good post from Jim Nielsen about the case for design engineers. He gives a good example of the kind of implementation detail where you might need insight from both the design and dev perspective. I find that some of my best work came from where code intersected with design.

Lately I am on a path involving a lot of pixel perfect design with a semi-traditional handoff, combined with research.

Sometimes I yearn for the days of yore where I did not have to direct details from a distance, only hoping that the implementation matches my dreams. Moreover, the whole problem with trying to describe something is that your description will just be incomplete; you have to feel the implementation, you have to be actually use it.

One problem I have is the multi-platform-ness of our implementation (iOS/iPadOS/Android/Web), combined with the actual design problems and research; which does not leave me with time to also concern myself about code.

But when I do, I get a lot of pushback when I push for prototypes, with the arguments that it’s going to lead to throwaway code; will not fit in the system; or I just seem to leave the other side of the table puzzled with what I am talking about.

The point that my respondents in my opinion do not get, is that the point of a prototype is to get to a conclusion, to learn something. You can then go ahead and implement the actual thing in production ready code. A prototype can be throwaway code, specifically because it helps you on your path to learning where you need to be in the end. The deliverable is testable and something to iterate further on.

In my experience, when talking about a semi-complex UI, iterating on something once is just simply not enough. I find that in practice that it happens all the time that a design goes straight to implementation.