Optimizing front-end teams’ workflow is hard, there is always something that comes in the way, but it is important to at least try to optimize the front-end work. It could save your team considerable time over a project. Front-enders could work more efficiently together and within the production team.

Let’s take a look at front-enders’ typical relationship within a production team: (take it lightly)

First, you got designers that, generally, do not really like front-end developers because they do not render exactly there graphic design, and you got front-enders that “hate” designers because they are doing complicated design, costing too much money and time to render to HTML.

Back-end developers also have a general tendency to be a bit careless with HTML, which, not visible at first sight, can cause trouble on older browsers and pass without no one seeing it on live versions. Improving this type of team relationships should be a priority.

Now that you have taken these relationships within your team in consideration, you have to know that every front-ender has a way of doing CSS a bit differently. Many ways of doing the same thing can be good in CSS. But somewhere in the middle, a team needs interoperability, everyone needs to be comfortable with the CSS and Javascript of the others. This is one of the main reason I launched my own “CSS Framework“.

My workflow

Assigning a lead front-end developer by project was a tough choice, but was inevitable. You need someone to refer to with a strong knowledge of the project and who can fix things easily. As he makes the main template, most of the CSS is based on his style of coding and he is clearly the man for the job if something turns bad. He is lead on the project but not necessary the lead front-end of the team.

Another nice thing here, there is actually someone in charge! You know how it goes in a project. Front-enders come and go, but even if one lead is not really doing any work on the project, he needs to take a look time-to-time to be sure the front-end code quality is matching his expectation.

Having the designer look at the first templates will also save you 90% of the problems a designer can cause looking at a final product. This can be disastrous if no validation is done before transforming the HTML template to the CMS..

Don’t be afraid to add your touch and present this to your boss. You will probably save time, and your boss’ money, and a boss really likes to save money.

What about you?

You’re doing this work yourself? Want to share your way? Send me your work flow with some explications and I will put it on this page, editorial [at] position-absolute.com.

7 thoughts on “Best front-end workflow within a production team

  1. The paragraph that starts “First, designers do not really like front-enders…”, I am so familiar with that situation! It’s quite funny that you’ve described it as I would myself.

  2. I really like the way it is presented and its a good thing you came up with the idea because i find it really helpful. Thanks

  3. I disagree with what you’ve said regarding the relationships between designers and front end developers.

    “First, you got the designer that, generally, does not really like the front-ender because they break their website design, and front-enders hate designers because they are doing nearly impossible design..”

    if there is correct and sufficient communication between the team then these sorts of issues you’ve outlined don’t have to exist.

    Front-enders need to work with the designer, so they understand the in’s and outs of html/css and what will and won’t work. That said designers also need to work with the coder to reinforce why certain styling has been introduced and what relevance it has towards the project.

    However, these days 99.99999% of designs can be built to look exactly as they are in the PSD and there really aren’t to many legitimate excuses floating round as to why someone can’t be done. “shouldn’t be done due to X, Y and Z reasons” on the other hand is a little more common given a valid argument..

    food for thought.

  4. @dan I went a bit in a big scenario case here. The legitimate excuse, in most cases, is the budget. When you work with a budget, x cannot be always done in the budget. This workflow in theory should also help your team relationship.

    I agree with most of your points tought!

Comments are closed.