Overcoming Tension Between Developers And Designers

A sigh erupted from behind my monitor. I popped my head up.

"Are you okay?"

"Goddammit! I swear this design looked different just a minute ago!" she exclaimed.
She poked at her face briskly. The black plastic-rimmed glasses lodged back into place.

"And this padding! I'm pretty sure it's off by a few points!"

This sounds eerily familiar, doesn't it?

I develop software on the front end, and I feel this way, too, sometimes.
Sometimes? Heck, oftentimes!

Many designers and developers alike will become frustrated at some point, no matter the size of the team or the significance of the project. I think it's just part of the game.

We get frustrated with ourselves because our design files become wildly out of tune with the software based on them.

We get frustrated with others. Because they never implement what we've so thoughtfully designed. Or perhaps they did, but they left out all of the finesse, the soul. Usually, in the interest of "keeping the implementation simple."

In general, I don't think there's a real problem with frustration.

In fact, I've found it's often quite helpful.

It can guide us toward improving our workflow as long as the team culture is open. If the people experiencing this frustration feel safe enough to express and address it openly, frustration can be a powerful enabler for improvement.

However, I've also seen teams go sideways when they lack the tools to address this frustration. They allow it to be the source of bugs and inconsistencies. The software just "feels off" and lacks the sense of quality you thought you were putting in.

So, what is the key to overcoming all of this?

Dig into what's hampering the designer-developer collaboration. And break it wide open.

Drifting Design Fidelity

This is an insidious negative effect because it goes unseen for a long time.

When your project just starts out, there isn't much in the way of design iteration. You can keep the feedback loop with your stakeholders short.

It's easy for your developers to keep up and code up your initial designs.

After all, it's easy to go fast when you're small.

However, as you progress, your design library starts to grow exponentially. You add exceedingly more to your product's design language in the form of more colors, components, and larger features.

This goes on for a good while, and everyone is happy. Your product is out there. Outshining the competition and racking up downloads and users.

Congratulations, you're done!

Gotcha! You're not done! This is just the beginning.

Indeed. It's just the beginning. Now, you start revisiting your 1.0 features.

You add new bits of functionality.
You rejigger them to fit new usage patterns.
You find this little widget really works on screen A. Let's copy it to screen B and see how that goes.
How about we add a gradient here? Or tweak this font size so it's a little more legible.
Add some more space.

The avalanche of change continues to roll down the hill. It may even pick up the pace some more. Your users and your stakeholders can't get enough. You're on fire. It's quite the wild ride.

Until it screeches to a grinding halt.

Your Figma workspace has ballooned to unsightly proportions. Design files are randomly scattered across the floor. No structure in sight. How you find what you're looking for is beyond everyone. But you manage.

You continue chipping away at it. Responding to your stakeholders' requests as fast as you can, but something has changed.

Every screen looks different.
Some buttons feature text shadows, while others don't.
Which shade of gray is this background?
This box uses an 8-point radius, while this other one uses 6.

Others have started noticing, too.

Calls with developers are getting increasingly more frequent. They want to know why things feel so inconsistent. They want to know which of the 4 variations apply to the feature they've just started working on.

"Do it like we did in feature B," you appeal.
"But it doesn't match the rest of the feature."
"I see," you admit. "Let's revisit this later. I'm swamped."

This scenario repeats itself many times. It's frustrating, but you deal with it ad hoc. It's the only way. You have work to do.

Then, the developers stop asking.

But you haven't changed your workflow. You can't. You're swamped.

Slack is taunting you. Its red dot is menacing. You're nearing your lunch break, so you click. There's a message from a designer colleague at the firm.

He's raving about something called "design systems." It's the new hotness.

It'll solve all of your problems and improve your relationship with your developer coworkers. You continue reading.

Drifting Implementations

Hop over the fence onto the greener pastures of development, and you'll find a similar situation.

What's so hard about converting a static graphical design into working software? That's a straightforward question! The answer is less straightforward than one might expect. In the ideal world, it's very simple.

You've received the functional requirements for a given user story. Better yet, your team has co-created this feature shoulder-to-shoulder with its business stakeholders. You've prototyped it up the wazoo. You've user-tested it left and right. You've even touched on a few technical edge cases. A product owner's dream, this one.

You've received pixel-perfect designs in Figma. As it happens, your designer friend was involved in the creation process, so it's perfectly aligned with the functional requirements. It's pretty, too, all shiny, decked out with golden ratio corner radii and smooth multi-stop gradients. A feast for the eye.

No stone was left unturned. Developer bliss ensues.

You settle in with a steaming cup of Ethiopian single-sourced coffee, and you start crafting this feature to perfection.

Lather, rinse, repeat.

This iterative process really works, and it moves your product beyond the 1.0 stage. Your product has become a fixture in the firmament of its industry.

Your product has grown up. You're often held up as a reference by competitors.

A look under the front-end code covers reveals a different story. The codebase is scattered with color codes, gradient values, and corner radius numbers. Even a not-so-keen eye will notice things are a little out of kilter. Margins and paddings jump around as you tap. Buttons aren't all the same size. The list goes on.

"Fear not," you say one foggy morning.

"I've started consolidating our design parameters into a bit of a system. Just a few classes with constants. There are too many inconsistencies across our features, and it's becoming difficult to figure out which design value goes where. This should help."

Others chime in, "Uhuh. We have the same issues. But our OS has a different way of consolidating this. It uses bubbling and cascading and stuff."

Despite everyone's best efforts, the developer-designer relationship is strained. You backtalk. You complain about the inconsistencies. Many calls and meetings are required to get a feature's design to a point where it's good enough.

Sometimes, it's just too much. You start cutting some corners, thinking, "No one cares about this drop-shadow." Besides, drop-shadows are performance hogs.

Does this interaction need an animation? "It's not in the design," so you move on.

At this point, your team has started iterating on old features. Tweaking them, adding to them, and linking them to other features. The once pristinely designed feature has become a Frankenstein monster. Heck, even Microsoft can't completely get rid of Windows 95-styled dialog boxes. How are we supposed to compete?

"We don't have a hundred developers working on a single feature," you preach to anyone who doesn't want to hear it. "We're not Facebook!"

One fruitful morning, trudging down the carpeted hallway to the coffee machine, you notice excited talking sounds emerge from behind the neglected monstera plant in the back.

"... tokens. And you can link them from different design files."
"... all the same color."
"... JSON files. On Github..."

The brown liquid sloshes around as you approach to listen in. More brown stains make their way to the carpet. It's obscene, but you're too engrossed to notice. They're talking about something called Design Systems.

Shut Up And Listen

If you recognize yourself in some of the stories above, you've identified a similar problem in your workplace. Perhaps you even feel responsible for taking the first step in looking for a solution.

Great! This is exactly the mindset we need.

So many problems in work (and life) can be boiled down to "people problems" rather than technical ones. I realize this is fluffy and not at all what you were hoping for.

Because people are not rational and, therefore, a little non-deterministic.

Technical problems usually have predictable solutions, much like a mathematical function where what comes out is directly related to what was put in.

"People problems" require an open mind, a lot of listening, and compromises.

When we're caught up in the product development carousel, we sometimes lose sight of the human side of JIRA stories and their statuses. It's natural to feel only our own pain.

A developer may have a hard time seeing the designer's struggle and vice versa. Deep down, you know it's there. But it has become too abstract, and thus, not so much your problem.

"I'm gonna call a meeting and invite all developers and designers," you think, so "we can talk about it and get it out of the way."

Speaking openly about both the designer's and the developer's perspectives is definitely the right place to start. However, tread with caution when tensions have been running high for a long time.

You don't want to come across as preachy. Sometimes, it's better to test the waters and have a few one-on-one conversations. Make a concerted effort to listen more than you speak.

Realize that if a developer is an engineer at heart, a designer is an artist. While it's true that artists and engineers have different sensibilities, you'll also find a lot of common ground.

You both struggle with your tools, endlessly trying to get the most out of them.
You both struggle with getting a real understanding of the functional requirements of a problem.
You both struggle with not getting enough done.
You both struggle with why the other side doesn't "get it."

Lay It All Out

Take a step back and take a critical look at how developers and designers have been collaborating to this point. Take both sides into account.

Which tools are you using? List them. Also, list the ones you wish you could be using but aren't. Why not?

How do functional requirements get translated into UX and graphical designs? What process has come before? Who is involved? Is it an iterative process or more top-down? Can you take technical constraints into account when making designs?

How are designs "handed over" to development? Are you using tools that can help? Can developers extract all of the design specs without help from a designer? Is it clear when a design is "ready for development"? What does ready for development mean to a designer? What does it mean to a developer?

Have you spoken about a formal "design language" or some sort of system to help guard consistency across features?

How is the design library structured? Are you using components? Are you using multiple files? Where are fonts stored? How do you define colors? In hex, RGBA, ARGB, or perhaps HSL?

The list goes on. Go a little further than you are comfortable with. You don't need to act on everything all at once. The goal is to broaden your perspective.

There's a lot more to this collaboration than you realized.

Work Uncomfortably Close

Civilization is built on collaboration. Life is one big group assignment. There is no work if you're not doing it together.

So you've opened your eyes to your counterpart's plight. What now?

Work together so closely that it gets uncomfortable. It's unlikely you've spent so much time with a developer or designer before. What do you even talk about? Can you even get along?

By spending so much time together, you will naturally formulate answers to all of the questions listed in the previous section. You'll work through all of them in the context of a real feature.

Some of your answers may look like the following.

Design As A Source Of Truth

The design file is so often the starting point for development work. Why not make it the real starting point by making it the source of truth for everything non-functional?

Align naming conventions across design and development. Use the same names for colors and basic components. For example, choose "sidebar" instead of "side nav" or "tab bar" instead of "bottom bar."

Use and learn design tools to their fullest extent. Enable versioning if your tool offers it. Factor common building blocks into your tool's equivalent of "components." If possible, use developer enablement features (e.g., Figma Developer Mode or Zeplin for Sketch).

Your design is a blueprint you work on together.

Give Access To The Source

Software development requires a lot of interpretation and translation.

Getting from a pixel-perfect design to working software requires many such interpretations. Remove as many as you can.

You could go one step beyond enabling developer inspection features in your design tool and give developers direct access to the source design files. Knowing your developers are scrutinizing your design files may incentivize you to structure them differently.

Make sure versioning is enabled, and give your developers a crash course on how to use your design tool.

I realize opening the kimono like this requires trust. But only good things will come from it. You'll be collaborating more closely than ever in a cross-functional way. Diversity, also in this narrow sense, always leads to better work.

Admitting designers to the developer playground should also not be taboo. This, too, requires trust, but again, only good things will come from it. Give them a similar crash course. How do you build the project? Where do you go to make small design-related changes?

Turn Design Into A System

This step is next level and probably not for everyone.

A good rapport between designers and developers is a minimum requirement, as trust and collaboration are essential for it to work.

Everybody and their uncle appear to be talking about design systems. It seems we're still collectively looking for a definition, but I can give you some takeaways from my own recent experience. There's definitely no one-size-fits-all solution when it comes to building your own design system, so be prepared to fill in the gaps yourself.

The Design Process "Developerized"

A design system is born when we apply development principles to design.

Figma is a wildly popular tool in designer circles today, and it appears to be at the forefront of the design system movement. In addition to its other developer-centric features, it also offers Figma Tokens Studio, a plugin that enables design system automation.

The design system formalizes all of the points I've spoken about in this article. Designers and developers collaborate closely on design, extending the design process into development with a concept called "design tokens." Tokens can be seen as variables, controlled directly by the designer, and are used directly in development.

With Tokens Studio, these tokens are delivered as JSON files and describe design parameters like colors, fonts, radii, spacings, etc.

The developer can take these JSON specs and mold them into whatever appropriate form. Many convert them into native iOS and Android code and CSS for the web. Tools exist to help you with this, but they're not required.

A typical design token workflow might look like this:

1. Assign tokens to parts of the design, resulting in a set of JSON specs.
2. Commit the token set into version control, usually directly from the design tool.
3. A continuous integration pipeline picks up the change and transforms the JSON specs into code.
4. The resulting code is published as a library somewhere, e.g., NPM or whatever makes sense for your software stack.

This results in a direct link between the design and the code that draws the component. When the design changes, the software component follows with next to no effort.

You can imagine the kind of compounding benefits that come from such a close partnership!

And I'm starting to see the upside, too, in the workplace.

But make no illusions. Developing an effective design system is intense, with many ups and downs and a lot of fuzzy lines. It's no longer just the developer or the designer deciding how a design parameter is defined, updated, or used. You need to agree on all levels, along the entire software design and development process.

Almost like true teamwork!

It's by no means a panacea, and it might not even be the right tool for the job, but it's worth the try if you're a mature software team with sprawling Figma workspaces and prickly codebases.

If it ultimately does fail, you'll have gotten to know your developer/designer counterpart in a way you never would have.

You will have learned invaluable lessons about your product, your team, and yourself.

So. Go forth and build.

But like everything in software, start small and iterate.

No designers were harmed in the making of this post.
All stories were made up.