Translating Design into Code: Why is it so Hard? And How Can You Optimize it?

How can you bridge the gap between development and design to create the best app possible? Follow this guide for some tips to optimize the way design and development teams can collaborate.

As simple as it sounds, translating the work of a UX designer into code is not as straightforward as you think. 🤷🏼‍♀️

I don't even have to argue this with you. Because if you're reading this article, at one point or another, you have felt the pain that comes from the gap between nerdy developers and artsy designers. 👩🏼‍💻👨🏾‍🎨 (I'm a developer, so I can call us nerdy.)

That's why I decided today to dig deeper into that gap and how can we rise up to the challenge to actually optimize this collaboration process. Let's translate beautiful design into awesome code!

🧐 Why Are We Making such a Fuss about Collaboration Between a Designer and a Developer?

The answer may be obvious to you, but let's review all of our assumptions and try to answer this question for the skeptics out there.

The product owner (a client for instance) is the one who sets the guidelines for a project: what the finished product should look like, what value a user gets from it, etc.

This all comes into play for the UX designer. They define the product based on the needs of its expected users while making sure the interfaces are easy to understand and to use. On the other side of the curtain comes the all-hail developer whose goal is to bring this baby into life.

Having a designer and a developer working together is a true thing of beauty ✨ because:

• You end up with a cohesive product with a great UX, UI and aesthetics. 🎨
• It won't be necessary to work and rework components or pages due to misalignments/miscommunication. In other words, you save everyone's time in the long run.
• Which means the product will be shipped faster and the code base will be clean and maintainable. 👊😎

And when they don't work together, you get the opposite of all these beautiful things we've mentioned. Plus, Design-to-Development (D2D) workflow inefficiencies tend to compound over time. You know it 'cause you've seen it... 👻

The Harsh Reality... 🙄

Let's have a reality check: while working together on the same product (hell, even the same feature), we work apart. 😶

That's because the striking MAJORITY of projects adopt an Over The Wall Design-to-Development (D2D) workflow. In which the only exchange of information that happens between a designer and a developer is when the former sends the files to the latter.

Sometimes this handoff isn't even a proper one, just two-dimensional images that don't tell you the user story, the specs, nor how the product interacts with the user.

Another case that I find utterly frustrating is when there are iterations after hand-off with new or modified components and/or layouts.

This can completely dismantle the initial logic a developer built the code base upon. Which not only makes merging the modifications tedious and time-consuming, but is in itself an error-prone process.

Bottom line, what we don't take into consideration is the fact that the designer's true client is not only the product owner or the user. It's also the developer. So it's mind-boggling that there is such a gap between them. 🤯

🥺 How Did We End up Like This?

There are obvious answers and some that are less so:

• Focusing on very short-term goals (finishing a sprint / going through features backlog) instead of sometimes just pausing to solve the inefficiencies, not just in the code base but in the D2D process.
• Remote teams who live cities / countries apart. Or simply a design team and a dev team that are housed in different departments or even buildings. And, well, poorly managing the D2D process.
• Misalignment between the amount of time needed to implement the design and time left to launch. Most times, we can thank the project manager for not sharing this little detail to our friend the UX designer. So they will just take into consideration their own deadline and design some awesome custom-made UI perhaps...
• Tools are great. Tools are made to make our life better. Some teams just don't use them. Why?! Just why wouldn't you use a tool that automates sharing UI specs?! Go figure!

For instance, Storybook is an open source tool for developing UI components in isolation for React, Vue, and Angular. It makes building stunning UIs organized and efficient. You can find an example here with the UI from Coursera.

• Imagine making your voice heard as one single UX designer who has to work with a team of 10 developers... That is insane, but common. How can the user's voice be heard if the UX ("user experience") designer's voice isn't?

So What's the Solution? 🤠

Some would say become a jack-of-all-trades to avoid this hassle. A bogus good idea 🚫 or as we say in French une fausse bonne idée mes chers.

I've entertained the idea though. But I believe that designing and coding great quality experiences in an optimal timeframe is very very very hard. As the saying goes: "Jack of all trades, master of none."

I've read many articles arguing that the best way to solve the gap between designers and developers is to learn each other's craft. The underlying idea behind this argument is that developers and designers come from two different worlds and think differently. That they are like aliens to each other, geeky nerds versus artsy hipsters. That this would help them gain perspective. But this is wrong on so many levels!

First, I don't agree with the way each party is portrayed. Many of us, designers and developers alike, come from different backgrounds and have different hobbies and interests. So, no, sorry, we're not like two different species.

Second, you could gain perspective by learning some basics from each other's craft. However, if the right workflow is not implemented to smooth the D2D process, it's useless, and it only makes for good coffee table conversation between colleagues.

On the other hand, the component paradigm that emerged with React or Vue is gaining new fans every day. Sketch also encourages you to design your interfaces using components. The combination of these tools really seems to me like a deal made in heaven. Having some skills for each of these tools (or knowing how they work) will make you so much more productive. It will help you think about interfaces and design them with the job your partner will have to do in mind.

🛠 What's the Optimum D2D Workflow?

A workflow by definition, is a series of steps with tools that achieve a goal. 🎯 The purpose of a D2D workflow is to get designers and developers to work in an orderly, organized, and comprehensive way in order to start, evolve, and finish a project.

It is not meant to add extra work on both sides. Quite the opposite, the steps we're going to discuss are actually meant to:

• Help designers design for the users instead of the ego
• Let developers get more done instead of focusing on pixel distances

Involve the Dev Team From the Start

I'm not saying that developers should be over everyone's shoulders before and during the design process. Just bringing the lead developer into the mix is usually enough. This way the designer is aware of what can be done given the stack used and the timeframe available.

If you've ever had to deal with Android apps, you know what a headache it is to stick to the original design. Someone has to remind designers to take into consideration the Android specs, to reduce design rework. Or even worse, to avoid having an app that looks and feels off compared to the original design.

Some frameworks come with prebuilt font icons with default components and different layouts and margin settings. Let's say the dev team will use Bootstrap, and you started designing your canvas without this information in mind. Which means that there will be discrepancies like margin settings in your artboard that are different from the margin set in Bootstrap.

It's important that the designer knows which framework will be used instead of having to make adjustments or compromises later on—whether in the quality of the design or of the final product.

Responsive Templating

For any new project started, designers should always have three templates with different widths: mobile, tablet, laptop. And that is the MINIMUM. I've already gotten projects in which the designer only provides one screen size, and leaves you guessing everything else to get the website responsive. It makes the whole dev team lose precious time with a result that will most likely be not good.

Honestly, I prefer designs based on a grid system, because you can easily design for different screen breakpoints. At the same time, it allows you to respond to screen sizes slightly smaller and larger where your layout breaks.

But let's take it another step further... 🤓 Let's all use Auto Layout! A simple Sketch plugin that will change your life as a designer: It allows you to design responsive screens for all (emphasize on ALL) screen sizes by turning pixel distances into percentages, and then lets the developer export them to HTML. 🙏 Exquisite!

Implement a Design System

Not having a design system means that your design will have a few inconsistencies at least, if not many. Which will translate into a frustrated developer, because they'll certainly have to create messy, overcomplicated components to respect that design.

It also means that we're wasting our dev team time that could be put to better use. Future dev changes will be more complicated, and you will have to maintain a heavier code base. On the other hand, having a design system will tremendously help in aligning design and devs from the start.

What's not to like about a Design System? It's a comprehensive list of the reusable components and layouts properly structured and organized, with each one serving a purpose along with its different variations, states, and specs. This makes it so much easier to make future UX and UI iterations.

In your design system pays close attention to:

• Including a Style Guide. It's the base on which upon a design system is built. It includes the color palette, typography and iconography used, the CTAs, shadows and contrasts, and any other repeatable element in your design. Without it, it will be hard to develop a consistent design throughout the project, and don't be surprised if the dev team creates discrepancies in terms of UI styling. You can find great pieces of advice here.
• Use Naming Conventions. Each component, layout, page, asset, and file must have a consistent label. Don't just use generic names and versioning labels. It doesn't mean anything and is pretty useless. I'd recommend going for labels that describe their function.
• Providing all possible States. Please, don't keep us guessing! 🙏Go through all the error states, validation messages, and disabled states for inputs and buttons that a user can encounter.

Note: You can find an awesome list of more than 80+ design systems curated here. I recommend you take a look at it in case you need some inspiration. 📖

User Flow

In truth, what you hand off to the dev team is not just design screens, but a user flow that you should be able to narrate. If you can't narrate, it means you make their work harder. If you're lost in your design, the user will be too, and the developer will also struggle to patch those designs together.

Narrating the story of your design is simply being able to tell what happens when a user clicks somewhere, why they do it, what happens when they do it, and what happens when something that shouldn't happen does happen (like with forms).

Note: User flows are usually when you can ask your marketers and growth hackers to collaborate with you. Especially regarding the product onboarding or all the important funnels your application can have.

Furthermore, a developer uses the UX story to plan their approach around how to build the features. So make sure to also link all the screens together. EVERY SINGLE ONE. Don't leave some screens out and think the developer will figure it out. No, they're usually not mind-readers. 💁‍♀️🔮

You can use tools like Principle, Figma or inVision to link your screens and make a clickable prototype.

I recommend Principle. It allows you to create animated and fully interactive design prototypes in a snap. It really feels like magic. 🧚‍♀️

Prototypes from Principle are really formidable. Because as a developer, we never get handed out the animations that go with performing an action in the design. It's quite astonishing, knowing that animations and micro-interactions are not just the cherry on top, but actually an essential part of usability.

A quick note for developers: Try to use CSS animations instead of JavaScript ones. They are much lighter and perform better.

Auto-Generate Visual Specs

I still have a hard time understanding why a designer would hand me a project without using a tool that allows you to see the exact specs for a component (margins, paddings, color codes, sizes, etc.). You can easily auto-generate this in tools like InVision or Zeplin.

It's simple and it helps the developers avoid spending their time pixel-distancing things. Yet, it's common to not use this option or to simply forget about giving them the proper access to see those specs.

Assets

There are two things that any designer should do when it comes to assets:

• Store them all in one place (Zeplin is great for that)
• Include SVGs every time you can

That's it. 👌

Maintaining a Checklist

Countless times, I was reminded by my product manager of last-minute designs that I've missed. This could have been avoided by making a list of all the features and case scenarios the design deals with (if and when they are not well documented in the user flow or the design system).

So? Where Do We Go From Here? 👨🏼‍🎤

Even if you can't follow all of this (and it's okay if you can't), just start by implementing these methods one by one in your work routine. Even one more good practice will move the collaboration between a designer and a developer a step further.

One final recommendation I have is doing post-handoff meetings that include the project manager, the developers, and the design team. Usually there are meetings between the PM and the dev team, but they solely focus on meeting the deadline. Including the design team is an opportunity to not only compare each product build against the final design, but to also determine what practices could have been implemented to avoid this in the future.

You can ping me on Twitter @RifkiNada if you want to talk more about all this. 😇