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!
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:
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... 👻
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. 🤯
There are obvious answers and some that are less so:
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.
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.
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:
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.
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!
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:
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. 📖
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. 💁♀️🔮
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.
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.
There are two things that any designer should do when it comes to assets:
That's it. 👌
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).
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. 😇
Subscribe to be the first to get our expert-written articles and tutorials for developers!
All fields are required