This should be a match made in heaven, a pair of qualified professionals working hand in hand to create highly functional applications that are beautiful and a dream to use.

In theory it should be the most natural working relationship on a software development team, but as most frontend engineers could attest it rarely works out that way.

Personally, I believe that designers and frontend engineers should be best friends. We should have the fun kind of working relationship where we're regularly sending each other cool Slack messages showing off how one brought the other's work to life or the really cool idea that's coming down the line and how it could work technically.

In a way the position of frontend engineer and UX/UI designer should be told halves of the same job. And it's not rare to meet more than one designer whose previous job was holding down both roles in a small startup, and vice versa for many frontend developers.

To me the biggest differentiator between frontend engineers and backend engineers - a love of creativity and beauty, is the foundation of being a great designer. And even though a frontend engineer can handle writing complex algorithms, there is a passion for creating something beautiful that can live, breath, and wow users and solve complex problems.

And yet from my own personal experience as a company ramps up in size, designers become an impediment to a frontend engineer's ability to deliver code quickly, while frontend engineers become a nagging irritation trying to remove a designers freedom of creativity.

How exactly does this happen?

Let me just be clear that I'm not sure this is necessarily universal but I've seen and heard it often enough that I do think this is a systemic flaw in the modern Agile-centered Scrum-centric software engineering team.

Over Specialization

Each employee becomes a specialized version of their role and I don't mean that in a good way. Engineers become more and more focused on engineering, designers become more and more focused on designing.

In a way, specialization is the magic formula behind modern economies. You're better at raising chickens, I'm better at cutting down corn, so you stick to the chickens and I'll stick to the corn, and neither of us are wasting time on the things we're bad at.

But like most black and white abstracted over-intellectualized theories, most people don't want to just raise chickens all the time and it would be incredibly beneficial for them to know how they grow their corn.

Of course the chicken farmer will still buy corn from a specialist but when they go to buy it make more informed decisions and won't be susceptible to other people's poor work.

This dynamic is no different from the relationship of designers and developers, and in my experience in large companies an engineer couldn't tell you a single thing about what it takes to create the design for an application's UX as much as designers are unaware of what the engineer's role entails.

I can't tell you how many times I've heard a designer say, "I have no idea how you do what you do!" like a badge of honor.

It shouldn't be.

The same holds true for any engineer that thinks their job is to receive designs and then translate it into code without any interpretation, or making sure the designs are following design systems and principles (or whatever design strategy your organization chooses to follow).

This also applies to an engineer knowing accessibility, color management, and general design systems. Just as a designer shouldn't be a developer to understand the role of an engineer, an engineer shouldn't be a designer to understand the role to be able to collaborate in an intelligible way.

Atomic Design

This is the design system I prefer and demand from designers. It's a totally coherent system and makes the most sense for design to align with frontend development.

If you don't know this is a pretty good short intro to what I'm digging into: https://atomicdesign.bradfrost.com/chapter-1/#systematic-ui-design

And from a programmer's perspective this should be very intuitive (unless you oddly aren't modularizing your components, which is a much bigger problem).

I know Figma is all the rage, but for this article I'll reference Adobe XD because it's free and it's the wire framing software I use on my own personal projects. Also, when it comes to Atomic design both systems are geared to easily handle it.

Check out this article from Adobe XD's documentation: https://helpx.adobe.com/xd/help/work-with-components-xd.html

Adobe XD's component organization is straight forward and easily allows you to build components within designs, allowing a designer to think as an developer and how components (or atoms) interact with each other based on their UI.

Of course, just like with development, if a designer isn't modularizing or Atomizing, then these functionalities are pointless anyway.

Getting Design and Devs on the Same Page

In an ideal world the designer's work flow would start with them breaking down a design concept into it's smallest atoms, creating them in their asset library, then building upward from there to create the page or feature.

Each time a new component is created developers would get a new ticket, JIRA or otherwise, and then after the new components are created, then the new feature would be implemented.

But like most of the best laid plans this rarely follows a team's process.

One of the major flaws here is that designers are pressured by the administration (that's Product Managers, Scrum Masters, and any other middle or upper management) of a team to not think of their work in this detailed process but instead make a demand for a new feature or functionality to be designed in completion.

Starting off on this foot the incentives aren't for a designer to collaborate with a developer but instead to create something they can present to the administration that can then be passed down to engineers.

I'd argue this disconnect is the number one issue keeping developers and design from being best friends but I digress.

While early on in an application's life designers might hold themselves to creating Atomic UI Libraries things falls apart quickly as an application grows and moves from creating from zero to molding and refactoring.

Part of this is due to the fact that no one, and I mean no one, including Frontend, Design, or Backend (more on this in another post) thinks of an application as the totality of UI Components, and instead become silo'ed only considering their own needs first.

As developers and designers focus separately on engineering and design there is zero alignment on what something like this means.

Aligning Components and Atoms

This is an extremely simplistic example of what I'm trying to touch on but I think anyone with some experience in web app development or design has dealt with something similar to this.

In this worst of worlds, which also happens to be the most typical way something like this is implemented, this is 3 different components.

Something like, CategoryCard, ProductCard, MultiCategoryCard.

This is the point where you can see clearly that developers don't understand design and that their architecture is going to be impossible to maintain as the codebase starts to have hundreds, if not thousands, of components.

An app that follows Components in a healthy way will architect this to be a single card, while children that handle the specific instances of variety.

Not my best work, but again it makes the point, and unfortunately something you've probably seen before.

And even though this kind of gets the point, it still disconnects the design from the code, and will inevitably grow out of control.

This type of architecture forces a disconnect between a designer and the code, breaking the best friends rule.

As much as we'd love for there to be a common language that we all inherently understand, a designer will never be able to automatically look at a feature and design it in the same way that an engineer would, so these types of data specific concepts will inevitably be confusing for a designer, and I don't blame them.

Think of it from their perspective, when they were in their initial meeting with Product, or whoever, and they received their directions for how to design a feature, do you think they're getting it as, "create a reusable card component that can handle various types of children components for different types of cards"?

Of course not, they're being told to make a row that has a card with multiple product categories, a single product, and a single category. Which then gets designed as three separate cards, which then gets developed as three separate cards.

The cycle continues.

Finding A Common Language

Of course it would be nice for the administration to be in on this party, but this is about designers and developers being best friends and that means finding a way to communicate with each other in a way that makes sense to both, even if it means disregarding the input of the administration.

That means to focus on the UI to define components in alignment with Atoms.

There's no need to let the administration see how the sausage is made but that does mean developers and designers taking more responsibility for what they build, reminding the administration that they're meant to support and not dictate (another post on this in the future too).

It means that a developer won't have to ask a designer to understand the difference between a Category Component with one product versus 4, instead it's asking how many rows and columns do you need in the card.

Which means your component architecture turns into: