Front-end development at Foolproof and why it’s important

The role of the front-end developer (FED) has changed significantly over the last five years.

Advances in web standards mean that web browsers can now cope with far more complex designs than ever before. This has created the need for FEDs to become more involved in the early stages of the design process. At Foolproof we work closely with designers in three key areas.

Before we look at the role of FEDs at Foolproof, it’s worth taking a quick look at the main way in which the job has changed. Traditionally, a designer would have handed the pictures for how a website would look to the FED. They would then have turned those pictures into code that a web browser could understand and that a back-end developer could turn into templates within a Content Management System. Although the role has evolved beyond these tasks, they are still a key part of what a FED does.

Since responsive design hit the mainstream, delivering static pictures of what a website should look like has ceased to be a good strategy for design companies. Maintaining multiple versions of a design to show how it should look on different device sizes is costly. Static designs also don’t consider the outlier cases - either with different amounts of content or at different sizes. Delaying getting to the bottom of these things makes your life easier in the short-term, but long-term you’re creating a bigger mess for yourself.

Design must now show an intention of how it should look and feel and that’s where the FEDs come in. But these design subtleties can often be lost on a developer who is more engineering focused. A design focused FED on the other-hand will seek to understand what it is that the user is trying to achieve and then collaborate with designers to come up with a design that works. So, although FEDs do not need to be designers, they do now need the skills to be able to consider how a design will look on different platforms and be able to work collaboratively with designers.

The FEDs at Foolproof

At Foolproof, code is our preferred design deliverable and that’s where the FEDs come in. We could be writing front-end code for a prototype for testing, production ready code for a website, or creating a pattern library for a larger design system. It’s our job to liaise with the client’s tech team to understand the technical constraints that we’ll have to work within and feed this back into the design team.

It is not uncommon for the FED to be the last Foolproofer involved on a project and therefore the last advocate for the customer. We stay connected with our clients and the back-end development team to be a champion for the user and to ensure that the intended design becomes reality. It’s about protecting the design and the experience up until the product launches.

1. Prototyping

We get involved early on in design; prototyping components, behaviours, animations and transitions. Importantly, we are proactive contributors to projects helping designers to solve design challenges.

There are many things that coding is able to do that prototyping tools used by designers can’t. This affords more control when designing how elements move in a page and animate. By involving FEDs at the prototyping stage, we can work with designers to substantiate concepts earlier on. Using code rather than prototyping tools also makes it possible to iterate designs easily and quickly during user research.

Making changes during the prototyping stage means we don’t waste time testing code across different browsers and devices and fixing associated bugs for features that might not make the cut. This allows us to develop more accurate products faster.

2. Production ready code

Once a design solution has been proven to work with users we get it ready to deliver to our clients. This is called making the code “production ready”. During this phase, we finish anything that was only partially built for the purposes of the prototype and we make sure it works across the required browsers and devices.

At this point it is ready to hand over to the client’s back-end development team - although on larger projects we prefer to make multiple handovers. New constraints often come up during implementation. Handing over code earlier gives us time to work together with the client’s back-end team to find acceptable compromises that both maintain the design vision and tech feasibility. 

FEDs are an essential part of the user experience design process, helping improve design outcomes. We understand and champion UX design and work as a bridge between designers and back-end developers. Without an engaged, design-focused FED on a design project the key messaging of designs can be lost when they are handed over to the back-end team.

3. Pattern Libraries

On larger programmes, we are often asked to create the first piece of a wider strategy; one in a series of websites that will be rolled out that all need to look and feel the same. On these projects we create pattern libraries, which catalogue all of the component parts of a user interface. These components are smaller pieces that can be combined to make a greater whole, in the same way that different types of Lego bricks can be combined to make a model.

By breaking down an interface in this way we benefit in two ways. First, we can document how certain problems should be solved – “Need to present a long list of nested links? This is the pattern for that”. This can help ensure consistency as a product / service grows, which is a problem many businesses struggle with.

The second is that we are also future proofing against designs that we haven’t created yet. To go back to the Lego analogy, the studs on a Lego brick are always the same size and spaced in the same way. This allows all bricks from different sets to fit together. You wouldn’t want bricks that only worked with pirate Lego, and we don’t want to create (to pick a completely contrived example) product tiles that only work if they’re put inside an accordion. By forcing each component to stand independently of all the others we know that we can, within reason, combine them in unforeseen ways.

What next for the FED?

Front-end development is a term that is extremely varied and often quite confusing. I expect that over the next couple of years we’ll see greater specialisation and therefore more descriptive job titles such as “React Developer” or “Front-end Operations Engineer”.

If the term Front-end Developer does turn into several more specific roles, I see the equivalent role at Foolproof being called “Front-end designer” in some places, or “Design Technologist”, as per this Jory Cunningham article but I’m not ready to put either of those on my CV just yet.

Hopefully, you now have a better understanding of what front-end development means here at Foolproof and why it’s important to us. In short, by involving FEDs in the design process you get an outcome that you know is going to work because it has already been built.