DEV Community

Cover image for Programmers, beware! Designers attack!
Mateusz Zdrzałek for Emphie

Posted on

Programmers, beware! Designers attack!

Obligatory (my editor made me add it) Disclaimer 😉
All scenarios presented in this article are intended purely for humorous purposes and reflect the personal opinions of the author. The intention is not to offend anyone or specifically target real situations or projects. Any resemblance to actual events or projects is purely coincidental.

Intro

Are you familiar with that feeling when you come across a design that immediately triggers a cascade of expletives in your mind, making you question every decision that brought you to that particular moment? No? Well, consider yourself fortunate. Certain design practices have the uncanny ability to evoke such reactions from front-end developers. Regrettably, encountering one of these design challenges in a project often implies a high likelihood of encountering more. In this article, we will delve into the realm of designs that pose significant obstacles during development. Brace yourself for an insightful journey into the world of frustrating design choices. Let's embark on this adventure together!

Diagonal lines

Let's dive into a common predicament that many web developers face, regardless of their experience level. CSS, known for its love affair with rectangles, tends to make life difficult when it comes to anything else. You can squeeze out some rounded corners if you're lucky, but anything beyond that requires delving into the realm of hacky solutions. And that's exactly what we're about to explore. Picture this: a well-intentioned designer decides to spice things up with a "dynamic" and "interesting" divider between different sections of a website.

A website design with a diagonal divider

There are numerous approaches to tackle this problem, but my personal preference would be to employ an SVG triangle, as demonstrated in the illustration below. Implementing this solution isn't overly complicated, but how should it behave when scaling the browser? This crucial consideration should be in every designer's mind when creating any application element. Should the triangle maintain a fixed height or scale down accordingly? How will it affect the elements positioned below it? These are the pivotal questions that must be addressed in the design notes if the designer chooses to incorporate this element.

Illustration. Square and triangle under it on the left and two different scaling suggestions on the right.

Floating elements

I can’t count how many times I had to deal with this one. Picture this scenario: the designer sees a bit of empty space on the page and starts thinking: “How can I make it more interesting?”, after exactly 0.01 seconds he figures it out: “Let’s add some floaty stuff and make the devs hate me!”.

Block of text with image inside. There are floating icons over the image.

I hate them so much 🥲 Those things are impossible to make them responsive. Usually, I just implement them on desktops, pray that they work on all the desktop screen sizes and completely remove them on mobile and tablets.

Illustration. Image between text with icons fitting the desktop on the left and icons outside the screen on mobile on the right.

Inconsistent components

Here is another scenario. Your team has dedicated an entire week to diligently implementing the sleek and modern form components meticulously crafted by your designer. As the next sprint kicks off, you eagerly await the designs for a new contact page, only to be greeted by a jarring sight. The designer, seemingly in a quest for uniqueness, has opted for completely different components on this particular page. Faced with this situation, you have two possible routes to take:

  1. Take a break to cry in the toilet and implement a second set of components to confuse the rest of the devs working on the project
  2. Try to persuade the designer to use the already implemented elements, fail at it and finally go with route no. 1

Two forms on top of each other. Each has a different styling.

Untranslatable design

Block of text within a gradient box. Image behind it.

Here's another familiar scenario that frontend developers often encounter. Imagine you're working on a multilingual page, and everything seems to be going smoothly with the design in the English version. However, as soon as you delve into different languages, the trouble begins to rear its head. Take a glance at the design above: a visually appealing offset image positioned behind a text box. Yet, when you switch to a language with more condensed text, such as Chinese, or one with wider text, like German, things start to appear a bit off.

Illustration. Long “German” text on the left, short “Chinese” text on the right.

So, how can we address this issue effectively? Well, the key here is open communication and collaboration with the designer. It's essential to consult with them and discuss potential solutions. And here's the twist: we might just need to make those delightful language-specific adjustments. Oh, the joy of adding complexity and messiness to our code! Who needs streamlined and clean code anyway, when we can have a tangled web of exceptions? However, by actively collaborating with the designer, we can find the right balance between accommodating different languages and maintaining code cleanliness. Together, we can navigate these challenges and ensure that the design looks fantastic, regardless of the language used.

Ending notes

One of the fundamental aspects of working with designers is creating a collaborative environment and ensuring a seamless exchange of ideas and experiences. As a programmer involved in a project, it's crucial to actively participate in the design process. By providing thoughtful notes and explaining your reasoning behind them, you can save valuable time by avoiding the need for extensive revisions or complicated design implementations. It's important to acknowledge that as a developer, you may not always have the final say in design decisions. After all, applications are built for users, not for developers. Keeping this perspective in mind will help foster a user-centric approach and ensure the ultimate success of the project. Remember, effective collaboration and embracing the user's perspective are key ingredients for creating remarkable applications!

The example design used in this article is available here: Figma Design. Send it to all your designer friends to either teach them something or just have a laugh! Those are only some of the annoying elements to code. Are you interested in learning more? Let me know in the comments because believe me, I have a lot more of them…

Top comments (15)

Collapse
 
hendrikras profile image
Hendrik Ras

Happens to me regularly that a design works for desktop and few mobile devices and does not scale to anything in between.

Or the designer just shared some examples of the happy flow, no page loading or errors of any kind are expected on those applications..

Collapse
 
mtzd profile image
Mateusz Zdrzałek

Yeah, especially larger screens or tablets are the problem for me. Most of the time I just have to improvise. Loaders are also rarely seen, but fortunately usually I do get error states in the designs.

Collapse
 
koivma profile image
Koivma

I consider myself a designer, and I think you should level up your development skills! Also, change your mindset, my friend. If diagonal lines and simple :before and :after elements leave you puzzled, then beware! The AI will snatch your job faster than you think—probably in two or three years, or maybe even quicker. Keep up, mate!

Collapse
 
mtzd profile image
Mateusz Zdrzałek

I think you may have missed the point of this article, my friend! I’ve highlighted that there are many approaches to addressing the diagonal separator issue, as it is quite common. Personally, I am not particularly fond of using :before and :after in that case, as they feel a bit hacky to me. The main idea is that designers can significantly simplify development by avoiding some practices. By achieving easier and faster development, the client's costs can be minimized. As for my job, I must say that I feel quite secure. Thank you for your concern, and I hope you have a pleasant day!

Collapse
 
toddpress profile image
Todd Pressley

i feel pseudo elements are a great fit for this use case, since the diagonals aren’t semantically important. 🤷‍♂️ who cares 😂

good article and sense of humor… thanks for highlighting the importance of intra-team comms.

Thread Thread
 
koivma profile image
Koivma

Pseudo elements, in my opinion, are also a good solution, especially when dealing with a wave-like shape. If it's just a straight, non-horizontal line, then I would use CSS clip-path

Collapse
 
koivma profile image
Koivma

I understood the idea of your article - designers and developers need to communicate with each other. And the communication must be reasonable, so that people can learn and grow. As for untranslatable design and the inconsistency of elements, those are clearly problems faced by beginner designers. Let me tell you something, everyone has to start somewhere and learn, so don't mock and assume that you know better.

Considering that you struggle with basic CSS, you're probably a complete beginner yourself. When two beginners come together and one mocks the other, the result is always bad.

As for the notion that offering a lower price to the client through simpler and faster development is rubbish. Maximize your profit and maximize it in long term. Always give your best and try different things, so that all team members evolve. If you only stick to boxes and circles in CSS, you'll keep scraping pennies.

Collapse
 
cloutierjo profile image
cloutierjo

Try to persuade the designer to use the already implemented elements, fail at it and finally go with route no. 1

Saw that way too often 🤣

But yes in all case, communication is key, and as early as possible.

My other "fights" is overly complex feature that will take 5 months to build and doesn't make sense to be split in smaller chunk as everything is designed to fit with everything else...

Collapse
 
ivorator profile image
ivorator

Spend a month arguing something won't work due to conflicting concepts, being talked down to, as if you are missing some secret insight.
Spend two weeks hacking your way implementing two disjoint parts which will never fit together.
Spend couple of more weeks finding a semi working way to build adapter and build the two.
Get feedback from users that they are really confused.

Throw away one of the concepts.

Try to see your brain by rolling your eyes while listening that this is how "agile" works, and we needed to do all this extra shit to discover what some people have been saying from day one

Collapse
 
fruntend profile image
fruntend

Сongratulations 🥳! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up 👍

Collapse
 
cloutierjo profile image
cloutierjo

Programmer vs Graphic Designer | Coder vs Designer - YouTube

Subscribe to @SarwarSateer #shorts #designer #programmer

favicon youtube.com
Collapse
 
bkpecho profile image
Bryan King Pecho

Inconsistent components can be a real headache for developers, but finding ways to collaborate and adapt can lead to remarkable applications.

Collapse
 
mtzd profile image
Mateusz Zdrzałek

Thankfully, in my case, usually it is an honest mistake on the designer side. If you tell them that we can keep the app consistent by using our pre-made components, they are fine with it. The trouble begins when they do it on purpose...

Collapse
 
ayabongaqwabi profile image
Ayabonga Qwabi

Or sometimes you are just given a desktop design and then you have to build the mobile site as well but then they complain when they don't look the same .

Collapse
 
cubiclesocial profile image
cubiclesocial

"Programmers, beware!" or "Designers Attack!" both seem like reasonable titles for an indie video game.

I know that's not what the article is about.