Why we involve front-end developers from project start

When I started my career as a front-end developer I spent most of my time crafting HTML & CSS layouts from design mockups. I was one of the final steps in a generally linear process, where decisions were made by designers, project managers and clients. Beyond writing code, my input was limited to confirming whether it was possible to build certain features.

I suspect I’m not alone in having experienced this. Whilst projects can certainly be delivered this way, it imposes a fairly low ceiling on the quality of the outcome. At best the end result will be nothing more than a faithful representation of a web designer’s idea, at worst it can mean serious problems aren’t flagged until it’s too late.

At Browser we have a very different philosophy. We assemble a core product team on day one of a new project, and that team works closely throughout the entire product build.

As a front-end developer, this is really liberating. It means that I’m able to express my own opinions on how something should look and feel, and also develop a much deeper understanding of why there’s a need for the product at all. It’s much more enjoyable to build something when you’ve met users, experienced a company’s pain points and understand the market need for what you’re making.

So on an individual level, this has proved invaluable. But we also do this because we genuinely believe this approach creates better products. Here’s why.

More perspectives = better product

In my experience, a more varied and diverse collection of viewpoints results in a better, more considered product. As a front-end developer, I’m conditioned to think about the ‘what ifs’ and edge cases of what we’re making, and these are exactly the kinds of things that can slip through the cracks if there isn’t a front-end developer involved in the process early on. Thinking about these issues usually means problems are solved in a more robust, scalable way.

Problems are highlighted early

If developers are only given the chance to raise issues after a design has been signed off, then the end result is likely to involve compromises.

By contrast, involving everyone in all stages of the project, including the discovery phase, means problems can be highlighted and solutions proposed early on. This leads to a better end user experience through better service design (which is where the real value lies) and also has other knock-on effects, such as…

Knowledge sharing is encouraged

I had a scenario just recently where I raised a potential issue with a design idea from one of our team. We came up with a solution, but also ended up organising a weekly design and development knowledge sharing hour which is helping all of us approach things from a new perspective.

The client appreciates it

Development can seem like a very foreign field to anyone not working in the tech industry, and if developers are hidden away from the client then it promotes this impression of it being a mystical kind of thing that just happens somewhere in the background. It creates a barrier between the client and the people making the product, and if something isn’t technically feasible then this makes it very difficult for the client to understand why.

Because we involve the entire product team in client interactions, we’re much better able to explain any technical challenges, answer questions and even get the client thinking in new ways.

The list could go on, and I’m uncovering new benefits all the time. As front-end devs, our role today is about so much more than just writing code, and the best companies recognise that and provide the platform for us to utilise our skill set to the fullest.