3

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!

  • Just curious... who currently does the work of the "front end dev"? (And where do they sit?) It sounds like you don't currently have any (dedicated) "front end devs"? – MrWhite Sep 9 '16 at 21:48
  • 1
    Give your team member portable workstations - or let them use their own laptops - and they will self-organize. This is a classic "management" issue that really doesn't need to exist anymore. – lunchmeat317 Sep 9 '16 at 23:20
  • 4
    Not sure "where does employee X physically sit" is answerable. It's going to depend entirely on your team, your office, office politics, org charts, egos, your personalities, and a plethora of additional variables. – DA01 Sep 10 '16 at 4:15
  • 1
    Our front-end guys sit with other devs because of historic reasons, but it would be better if they sat with UX designers because they have "scrum" meetings together (they watch results during them). – nuoritoveri Sep 10 '16 at 9:02
  • I didn't mean physically sit, sorry I wasn't clear. I meant reporting structure and organizational arrangement. We currently have a lot of devs, they all pick up front end or back end depending on the backlog and their "expertise". And we have 2 dedicated Architects. None are solely dedicated to front end. – narbuckle01 Sep 12 '16 at 16:39
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.

17

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.

  • 1
    we are indeed an open environment office and a geographically distributed organization – narbuckle01 Sep 9 '16 at 17:29
  • 5
    You work with what you have. I work in an open environment, and I can't tell you how frustrating it is to be debugging code, have like 10 things going on that I'm trying to keep track of, then someone comes up and starts gabbing about stuff. I wear headphones just so I don't have to hear outside conversation. I think a good idea might be to sit them BETWEEN your UI guys and Engineers. But, your project design should go through the project manager, so FE Devs shouldn't need to consult with UI guys as much I wouldn't think. – Christine Sep 9 '16 at 17:31
  • 3
    Front-end dev here. RESTful APIs have made frequent communication between front-end and back-end teams less necessary. Often, the back-end devs on my team design an API with little input upfront, and when they show it to me to solicit concerns, I have few criticisms. On the other hand, UX requirements are often confusing and subject to change, and I need to be able to show designers my work and ask them if it's what they had in mind. Furthermore, UX designers are less likely to frequently ask me questions because they aren't working on the same types of problems, – acbabis Sep 9 '16 at 20:23
  • 1
    ...so while I agree that engineers should ideally have quiet working conditions, I think it's better for front-end engineers to sit with UX designers than with other engineers. – acbabis Sep 9 '16 at 20:24
  • 2
    When I think "Front-End Developer," I think of someone developing the Front-End of like, a Web Project. I'm a web developer. So to me, Front-End means like, jQuery, HTML5, CSS3... working with Views in MVC... third-party tools like bootstrap... stuff like that. Not someone who develops APIs. But, I know that different shops apply different meanings to these terms. For instance, a Sr in one place may be a Jr in another. – Christine Sep 9 '16 at 21:25
5

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.

...

  1. 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).

  • 3
    You're not wrong, but I don't agree with this particular answer. Treating UI developers as "the people that build what we design" is a disservice to the UX of the project as well as the talents of the team. The best UI developers, IMHO, are very much attuned to UI design, visual design, and sometimes can do that just as well (though they don't have to, of course). – DA01 Sep 10 '16 at 4:19
  • I definitely don't want our developers to be seen as someone who just "builds what we design". I couldn't agree more with DA01's comment. – narbuckle01 Sep 12 '16 at 16:47
  • been doing front-end for almost a decade, and every job required translating from design to dev and vice versa. answer has lots of information, but disagree with the opinions. – albert Sep 12 '16 at 21:43
5

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.

  • 2
    +1 If I had the choice I would prefer to be more closely connected with the designers, one benefit being that it aids my creativity. – user28987 Sep 10 '16 at 11:24
2

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.

  • 1
    "direct a body of work you don't understand" is totally correct, I dont like it, but you are correct. :) – narbuckle01 Sep 9 '16 at 18:23
  • 2
    In my opinion, it's entirely open to debate. :) I'd argue UI dev's peers are just as likely to be UX/UI designers as it would be other developers. Ideally, it's both. As for 'being a part of the team and not one of those creative times' that's a common dysfunctional set up on a lot of corporations. If UX isn't part of the team in the first place, things will fall apart. (Again, it's common. It happens a lot). – DA01 Sep 10 '16 at 5:13
  • 2
    Also, if the UX team "doesn't understand" UI development, then they aren't going to design good solutions. It's like an architect not knowing how buildings are built. Ya gotta know what you're working with. (And, sadly, this is also common...I've been in several companies where the UX team was really just run by art directors who not only didn't know UI dev--they didn't care, much to the detriment of the product and, ultimately, users) – DA01 Sep 10 '16 at 5:14
  • 2
    (All that said, yes, kill silos. I agree. But as long as half the team is run by one branch of the company, and the other half another, you really can't avoid the territory grabs and infighting a lot of the time. Which is unfortunate) – DA01 Sep 10 '16 at 5:16
  • 3
    We can disagree on this. It really does come down to the teams. In my personal experience, in the companies I've worked at, the UX was much improved by having UI dev aligned with the UX team. A good UI designer, IMHO, absolutely understand interaction patterns and cares deeply about the UX to the point I'd call them a UX designer...just one that knows code. – DA01 Sep 10 '16 at 17:35
2

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.

2

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)
  • This is exactly the system that I want to set up, and everything is in place currently, except the FE sitting with our team to help transition the design to something that is executable within the time frame and given the tool sets we have available. Thanks for this! – narbuckle01 Sep 12 '16 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.