At their best, designers can be incredibly important members of the development team, making the team more efficient and the product better with visually consistent, practical and informed designs. At their worst, they can impede the whole project with sloppy and fanciful creations and practices. If you are a designer and wish to be the frontend developer’s ally, make sure you avoid these unbearable habits.

The development process is typically a teamwork. And good communication, chemistry, and efficiency make a team work much better. Unfortunately, even these will not suffice if your individual team members have problems with the basics of good web design. 

From the frontend developer’s point of view, this realization is often materialized in the form of poorly designed views received from the designer. The latter, as a true artist, would often love nothing more than lose themselves in creating vivid works of art. In doing so, they often forget about the more mundane, yet essential parts of the development process, making all kinds of web design mistakes that have a major negative impact on the project.

The designer can definitely become one of the frontend developer’s biggest allies, saving the latter and the entire team a lot of time and sanity. All they need to do is make sure they avoid some bad web design habits. Here are those I encountered most often in my projects.

Poor choice of web design tools

No matter how talented, experienced and hard-working you are, you will not be able to achieve your full potential as a web designer without using (all) the right tools. Unfortunately, a significant number of designers fail to make sure that they use some amazing and readily available design software, which not only makes it easy to produce designs, but also features many export and presentation options that provide a wealth of information to developers.

Some of the most popular and useful tools of this kind include:

  • Figma,
  • Sketch,
  • Zeplin,
  • Adobe XD.

So don’t be like this:

Modern UI/UX tools make life easier not just for you, but for frontend developers as well, by:

  • giving access to separate elements of the view,
  • providing information such as colors, fonts or sizes,
  • making it easy to take all measures in the view,
  • genering ready-made CSS code,
  • simplifying management of all pages in the app.

So please, next time you create a giant project full of views, lines, numbers, circles and other elements a poor developer will need to make sense of, use one of these tools.

No web design style guide

When you pick your tool, you need to make sure to use it efficiently. Just delivering the app’s views is not enough. A good design should use a proper style guide as its foundation. 

In this guide, both a designer and developer will find detailed information about all the building blocks of the application, including font size, color, spacing between elements, examples of headings, responsive design information for mobile friendly or mobile first website design, navigation styles, white space of a web page and more. These guidelines will make it possible to create a consistent design and user experience across the entire app – from the home page to every single little detail.

See the examples below:

Style guide – spacing and color

Style guide – typography

Aside from basic parameters such as measures of distances, sets of colours and typography, a good style guide needs to include reusable components and their states. It will ensure consistent design of all views and limit the number of mistakes.

No or insufficient attention to states of elements

Speaking of states, not taking enough care of them is yet another common problem. As frontend developers, we often complain about how incomplete (and sometimes even non-existent) the information about states is. The design of hover, focus or disabled states of buttons should be an absolute minimum for any designer.

Primary buttons and states

The same treatment should be given to all clickable and interactive elements. A UI design like this will drastically reduce the number of questions a developer will have to the designer.

Ignoring real-life scenarios in web design

The bad practices described above are typical of lazy designers. A somewhat less lazy one will be better than that. However, they will often still forget about accounting for common real-life ways in which the user will interact with their designs.

Let’s take a look at an example. Below, you will find a simple view with the latest added comments. It includes a list of example comments stacked one on top of the other. All of them are identical in terms of title and description length. In fact, they look exactly the same.

Recently added comments feature

At first glance, everything is fine– it’s just a simple list of comments, after all. Each comment consists of a title, date and description. Everything looks smooth and tidy enough. However, once real content from the database is added, one is bound to encounter a problem that should have been solved by the designer. Of course, the problem is that the title and descriptions can greatly vary in length.

These are some of the questions you should ask yourself when confronted with a comment section like this:

  • How long can the title be?
  • If a title can be two lines long, then how should it look inside the container?
  • How wide can the title container be and how close can it get to the date?
  • Is there a length limit set for a comment?
  • If there is a limit, how is it implemented (characters, words, lines)?
  • If the title or description is limited, how do we signal it visually (en ellipsis, shading etc.)?

As you can see, even a simple example like this can inspire many questions. They all require answers and may entail multiple updates to the original views, all contributing to (needlessly) extended product development. The same goes for responsive design, the needs of various mobile devices, navigation and other unique circumstances specific to a project.

Wrong component type

Another common issue in the designs delivered to the developer is a poor choice of element types. A typical example would be something like in the image below. The checkbox element is a vector rather than an object. As a result, the developer can’t find out what its properties are.

Vector vs object

The developer will definitely ask for some additional information on the border or radius size.

Not accounting for SEO

Nowadays, creators of web applications available publicly tend to consider search engine optimization (SEO) to be a very important aspect of their business strategy. Sometimes, it will make or break a project on the market. That’s why they create features and content for search engines as well as the content users expect. Despite this, SEO aspects are often underestimated at the design stage.

From the web designer’s perspective, the most important SEO issues include:

  • The order of headlines in the document, including adherence to HTML semantics.
  • Taking care of the mobile views (RWD) so that they include logical breakpoints set up in a way that does not generate needless and redundant structures in the code.
  • Realistic content of segments to properly account for all relevant measures.
  • Implementing WCAG guidelines in order to improve product accessibility, especially regarding contrasts and font sizes.

SEO is the job of all team members, including the designer!

Overly complex web design solutions

Designers can surely be creative and imaginative. It can be a great thing, but it can also lead to the development of solutions that are needlessly complex and costly. Using battle-tested solutions and familiar patterns of user behavior can often give better results than excessive originality and extravagance. For example, a radio button is natively round, while the check box is a square – users are familiar with it and it should stay like this. Let’s not reinvent the wheel!

It’s worth it to consult all the new elements with the whole team from the onset of the project. That way, you can create a solution with the best chance of satisfying both the client and the user.

Poorly performed export of elements

Modern software makes it easy to take measures and check the properties of each and every element. Unfortunately, designers often fail to export some elements, images in particular, in a way that preserves all the information. As a result, developers often struggle or even find it impossible to find all the necessary measures. 

In the example below, it is impossible for a dev to accurately measure the distance between the image and the right hand text block without resorting to some external tools. It should be clear from the view they get from the designer!

Measurement issues

No sub views

It’s hard to imagine modern websites and web applications without modules such as registration forms, newsletter or contact. Despite this, all developers are left with is a view such as this one:

Basic solitary form view

At first glance, it looks like a well designed form. What’s missing? It could definitely include the state of elements during validation errors (based on a style guide). Once an action (e.g. filling in the form) is performed, an interaction such as a thank you message is displayed. 

A properly delivered view would account for all the circumstances and states of the app.

Bad web design practices – summary

And that’s about it! Just to recap – you probably contribute to bad website design and are quite a pain to developers if you:

  • fail to use the right tools,
  • don’t follow a style guide,
  • ignore states,
  • create impractical designs,
  • use improper types,
  • fail to account for SEO,
  • come up with needlessly complex solutions,
  • export without thinking,
  • forget about sub views.

This article might make it look like all problems originate from designers. It really isn’t that bad!

However, given the designer’s involvement in the early stages of product development, it’s hard to deny that a lot is on their shoulders. Their role is to turn the client’s business visions into designs that provide great user experience and deliver them ready-to-code to the development team. The quality and accuracy of their web design has a huge impact on the end product’s quality as well as the pace of development.

The same sentiment is echoed by my friend and Senior Product Designer Aleksander Chmura:

“As a designer, I put a huge emphasis on communication with both the Product Owner and the entire development team right from the get-go. It’s a surefire way to avoid misunderstandings and information gaps, which tend to negatively impact the quality and pace of development.”

Aleksander Chmura

Aleksander Chmura

Senior Product Designer

Luckily, a designer can easily turn themselves into the driving force behind a project with good web design simply by ditching some bad design practices.

Leave a Reply