4 Common pitfalls in front-end web development and how to avoid them

A handy guide for anyone who wants to start into front-end development or would like a refresher about the essential design principles and UX best practices for creating interactive websites and online applications.

Subscribe to our blog

As a front-end web developer with over a decade of experience I've come across lots of development practices and as a visitor of webpages for a much longer time I've experienced their effect on me. This subjective, perceived ability to effectively use an interactive application, the cornerstone of my job, is referred to as user experience or UX.

There are lots of coding styles, patterns and philosophies that I believe should be used according to a developer’s personal preference, but when it comes down to the effect they have on the end user, I have a much stricter viewpoint. Web interfaces that confuse or downright irritate the user have a near impossible chance to be revisited.

Among these violations of UX design etiquette there are a slew of malpractices that seem to crop up time and time again. I think it's time to name a few in the hope that they might be given their final send off. Some of them are a bit technical, but all of them have a profound negative impact on what should be enjoyable user experiences, and all of them need to go.

1. user-scalable: no

Web developers make use of meta tags to provide additional, invisible information about the webpage they're presenting to a visitor. These can include information for search engines to identify the content, but they can also affect the appearance of the page on a user's device.

The advent of smaller web browsing devices called into life the introduction of the viewport metatag, which allows a developer to adept the presentation of the page's content to the user's screen, enabling the much-lauded responsive layout. However, the viewport metatag also allows a developer to specify that the user is prohibited to enlarge the webpage.

This might make sense in very complex applications, but in the majority of webpages it absolutely does not. Taking away an inherent behavior of the device (everybody knows how to use pinch to zoom) is not only counterintuitive but it potentially prevents visually impaired users from accessing the content all together. Using ‘’user-scalable: no” viewport metatag often causes several layout problems. As front-end developer, your goal is to create flawless and responsive layouts for optimum user experience.

2. Tiny touch targets

Web designers often create beautiful artwork that invokes an immediate emotional response in the viewer, but they might forget that the visitor should be able to easily navigate, usually with mouse-clicks or just by touching on the screen. It’s a front-end developer’s responsibility to ensure usability of the design created and adjust whenever necessary.

If the appearance of an element that the user can interact with (such as a link or a button) is too small, interacting with the adjacent space around it also needs to activate it. The visual space that activates an element is called its touch target and it too often is identical to the element itself, potentially causing a frustrating user experience, especially on touch devices.

Example: Implementing touch targets for carousel navigation

Left: touch targets are too small and break the website visitor experience. Right: the way to implement carousel navigation, with a larger touch targets.

Left: touch targets are too small and break the website visitor experience. Right: the way to implement carousel navigation, with a larger touch targets.

3. Lack of form labels, validation and keyboard navigation

The user’s input is essential to build responsive layouts. When this input is clear and streamlined, it definitely benefits both the interactive application’s visitor and its creator.

We’ve come to recognize a text input field whenever we see a rectangle that indicates we can type something into it by visual cues such as the mouse cursor changing to a type symbol when placed above it. A series of grouped text fields on a page is called a form and it’s crucial that the user knows what to type in each field. This is achieved by placing an adjacent label in the code, which identifies what specific kind of input is expected. This is a mandatory practice with regards to web accessibility but it’s often forgotten, be it for aesthetic reasons or by negligence.

Then there is placeholder text, a short sample of text that occupies the field before the user has provided any input, which is often misused as the field’s label. The problem with this practice becomes apparent when the user has filled in the fields and lost a reference of what they are supposed to represent.

Equally important is validation of the user’s input and the application indicating where and if it needs to be corrected. There is as of yet no standardized way of implementing form input validation on all major browsers. This is one area where thoughtful and functional front-end code can inspire the implementation of new browser features.

Another area that is often lacking in website forms is the ability to scroll through its different fields just by making use of keyboard navigation. Because the user has entered a “typing” mode in which the keyboard is the primary input source, it should be possible to complete the entire form without having to return to other input devices.

Example: The problem with using form placeholder text as labels. Context is lost when the fields are filled in.

Using form placeholder text as labels

4. Ambiguity on how to close a popup window

Thankfully gone are the days of web pages opening new, smaller browser windows because of popup blocking having become an inherent feature of modern browsers.

There is, however, a clear use case for providing information on top of the regular content and it’s now up to website developers to implement these so called modal windows from within their own HTML code.

The most frequently occurring problem is that there’s no clear way for the user to close the window. There might be a close button (and there should be, according to accessibility guidelines) but it might not be where you’d expect it.

There’s also no standard defined as to what should happen if the user interacts with the content that is being overlapped by the window. Should this action close the window, potentially causing the user to lose any information provided within the modal window, or shouldn’t it?

In my opinion, it should at least notify the user and confirm if closing the window was indeed the desired action. The same logic should be applied to a press of the Escape key on the keyboard, which is a commonly known action across multiple interactive user interfaces.


Front-end development is growing in complexity, with new tools and best practices emerging every other day.

Working in front-end or web design, your job is to create flawless layouts, so you can never have too many tips on staying on the path to UX design success. Not only front-end developers should be aware of these common mistakes, but also UI designers, back-end developers, functional analysts, as well as the other members of your digital project team.

In the end, we all work towards building interactive websites, online services or ecommerce portals that are as efficient and usable as possible, aiming for exceptional customer experiences.

Published on    Last updated on 12/11/2019

#Web Development

About the author

Mathijs Provoost is a Front-end Web Developer at Amplexor, based in Belgium. He’s responsible for writing and maintaining well designed, testable, efficient code for our clients’ public facing web-sites, web applications and lines of IT infrastructures. Mathijs also works closely with designers, developers, QA testers and support services teams to set the direction of our front-end technologies and lead their implementation.


Participate in this discussion