Where does your front end dev sit?

Question

Hi I manage a CX team of writers, trainers, UI architects, and designers. 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. I am wondering where your front ends sit? Do they sit with UX or sit in engineering? I report up to marketing instead of engineering which is also a bit different than the norm.

Some of the problems I am trying to solve are:

1. Build reusable code and libraries for future use
2. Ensure the technical feasibility of UI/UX designs
3. Optimize application for maximum speed and scalability
4. Assure that all user input is validated before submitting to back-end
5. Serve as translator between dev and UX

Thank you for your help!

Answer 1

In the old company, we have sit closer to Back-end Developers. So basically receiving the designs from an external agency, then after the implementation, working with back-end to help them implement their code, and do some modification if needed.

In the new company, back-end does build api's, and I deliver a complete solution top to bottom. I do not need them, unless I have api questions. That will happen if they created a really strange structure inside. A thing to remember is that the api's need to be as flat as possible, so UI will not do any heavy processing, resulting in a faster application. So force the back-end guy to create api's for front-end (which is hard with today mentality, that back-end is the main arhitect of the application). By experience will be that back-end will slow front-end developing process, and also force him to not do clean code.

Best workflow will be for front-end to work closely with the design team (because they usually don't follow patterns, and if you use frameworks to speed up the process, then eventually they will work against the framework itself, because they will need to follow the design). Front-end to develop the application and also build mock.json structures for the api structure. and then will pass that to back-end. Front-end need's to be 3 steps if not 4 in front of the back-end. Because let's not forget optimisations, seo, bugs, change's in business requirements, changes in the design, etc...

good luck ;)

p.s. ultimately you have to remember that the front-end is the one that know's all the latest trends in web developing and design, and no back-end will keep up with that.

Answer 2

Ideally, they sit in their own office by themselves, so they aren't distracted and aren't quick to distract other developers. Studies show that millions of dollars are lost every year JUST by developer distractions. Essentially, it sounds like you're asking where they should be strategically located, so as to make it quicker to find assistance and interact with team mates. Ideally, you don't want your team members interacting with each other constantly throughout the day. Developers need "blocks" of time dedicated to writing code without interruptions. To that right, it shouldn't matter where they're seated really, because distracting team mates is not something that should be made convenient to them.

But, if they sit in an open, SCRUM-type environment that's highly interactive, I would say with engineers. Front-End developers are developers. And, if you have dedicated UI people, your Front-End guy should be just that... a developer. They're going to need to interact with middle-tier and back-end developers more, because the code they're writing will have to be compatible with the code on the back end.

But, to be honest, I would rather not work on a team that has dedicated "tier" developers. In my experience, environments like that are borderline impossible to maintain, and people end up stepping on each others' toes. I prefer working on teams where each person has a dedicated project. But, that's me.

Answer 3

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!

Notwithstanding the issue of separating development of various application tiers onto different individuals, which is a point well worthy of consideration raised in other answers to this question:

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 knowledge of graphical design and/or human/computer interaction, but those latter aren't their main focus. 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, and if anything, would seem to introduce risks.

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 design role ideally filled by someone with some insight into relevant areas in programming and software development. Ideally, this person should also be a subject matter expert in the use of the software you are building, particularly if you are building specialized software that targets a niche market rather than something generic like an e-mail client or image viewer.

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" or possibly "sure, we can do it the way you want, but lots of people are likely to expect the software to work in [describe some other way] instead". It is then the job of the UX team, together with the stakeholders, to judge whether doing A instead of B is worth the estimated additional cost (in time/money spent on development, and/or user frustration when the software violates the user's mental model of how the software should work).

Answer 4

As a front end developer / engineer myself, I find it to be more valuable to work with designers. After all, I do turn design into interaction (which is a form of design).

After the design is implemented correctly, I leave data dependent snippets easily able to be "plugged into" by a data specific developer.

So, in short. I "sit" on the design team, but preparing the code to be handed off to data specific teammates.

The only issue I experience in this approach is that occasionally a developer will find a solution that may break part of the existing code binding interaction. In which case working with that developer to resolve the issue is critical.

Answer 5

Organize by work type

A front end developer should sit with Development. In my opinion, that isn't a topic to debate. It serves a couple of purposes:

1. They are located with and inspired by their peers. Developers.
2. They gain more credibility by being part of the team and not "one of those creative types".

They write software. All facets of the software will impact the user, not just just the "pretty" part. Drawing an artificial line in the organization will communicate a perception of value on that role (either positive or negative). That message is not productive.

Bringing a developer into the Experience team will also saddle you with trying to evaluate and direct a body of work you don't understand. You will not be able to set the right goals and metrics for this role because you aren't a developer. This is not something you need to add to your plate.

Kill silos

Just because dev and CX are different teams doesn't mean they don't work closely. Cross-functional teams working on iterative projects and reporting out to their respective departments is the answer. If you don't sabotage this structure with territory grabs and infighting, it's going to produce results and solve the organizational misalignments you're concerned with.

Answer 6

From my personal experience as a Frontend Developer I find it more convenient sitting with the UI/UX team. Because I am implementing their designs in to actual prototypes and it's easier to polish the UI because I have them right there to consult and critique as the implementation progresses even after completion. So I would summarize to say "Very often as a Frontend Developer I seek consultation from the UI/UX Designer for guidance in regards to an uncertainties that I come across in the design". I rarely ever had to consult the Backend Developers about anything at all.

Answer 7

As I commented, this is a really impossible question to answer conclusively. It all depends on your company and the project and any other number of variables.

That said, I've been in this position many times, and the system that seemed to work best (for me, and the projects I was on, in the companies I was in) was for the UI devs to be on the SCRUM team.

The UX team may also have a UI dev or two, but for the most part, they were charged with working ahead of the sprints. However, the UI devs were constantly looped in on those work-ahead tasks and constantly consulting along the way.

The benefits were:

• by the time the UX design got to the SCRUM team, the UI Devs were already familiar with what was expected, and likely contributed to the solution
• this allowed the UI devs to get stuff pumped out fast during the sprint, giving the rest of the devs time to wire it all up
• the UX team wasn't designing the impossible. By having UI devs that knew UX and the technologies, scope was kept to a realistic level and solutions were pragmatic rather than pie-in-the-sky (which I find always happens in a pure waterfall process where UX designs a solution independent of implementation)