I'm worried by this point in your question, which I feel may be at the core of why you are asking this at all: > I'm working to expand our capability by adding front end devs so we can have better relationships with the developers via the front end dev, or translator. > > ... > > 5. Serve as translator between dev and UX *That's not what a front-end developer position is about!* A front-end developer, in accepted parlace, is a developer who happens to work on the front end (user visible parts) of an application. For example, if you advertise a front-end developer position for a company producing web-based software, you should get people who are strong in technologies like CSS, Javascript, HTML and who *might* have some knowledge of graphical design. They will expect to be given reasonably solid designs for how something should look and interact with the user, and be tasked with writing the code to make those things happen. If you advertise a front-end developer position and people find out that instead of doing development work they will be asked to "translate" between your other developers and the UX team, then at best, your applicant acceptance rate will plummet, and if it does not, then your *retention* rate will plummet. The developer position opposite of front-end is not a developer that doesn't interact with your UX team, but rather a developer that works on the parts of the application that are not directly user visible (web services, database code, that sort of things). Your other points (build reusable code and libraries for future use, ensure the technical feasibility of UI/UX designs, optimize application for maximum speed and scalability, and assure that all user input is validated before submitting to back-end) are things that any developer should be working towards (or be capable of working towards) anyway. If *any* of your developers are not, then find out why and work to rectify that situation; adding another layer between the people who want things and the people who build things isn't going to make any real difference there. # TL;DR: It's great if you are able to have a dedicated person to serve as a contact point between UX and development, but that's not really a development position, but rather a [human/computer interaction](https://en.wikipedia.org/wiki/Human%E2%80%93computer_interaction) design role ideally filled by someone with some insight into programming. In practice, unless you are a big company, it's more likely that the work of ensuring the implementability of what the UX team wants (based on specifications, user stories, UI mockups, etc.) will fall on different members of the existing development team depending on the focus of the issue at hand and the individuals' respective skills. A good development team will be able to shoot something back at the UX team with a rough estimate like "yes, we can do it the way you want, and it will take X days, but if we change A to B instead, we can get it done in a quarter of the time and it will work almost as well".