The designer-developer relationships seem to be a hot topic dramatic enough for Shakespeare to write a play on their cooperation.
I often hear from business owners how worried they are about the design implementation. “What if designers do something wrong?” or “What if developers go astray?”. So many “what if” when just one is right — what if you don’t fret about it so much?
The problem is slightly overhyped, or better to say, “the devil is not so black as he is painted.” There is nothing that can’t be fixed by consistent communication, attention to detail, mutual respect, and stellar specialists on both sides of the fence. Oh, and a few strategies to make the cooperation between tech and design teams a smooth ride. For them — I turned to my colleague Alex, a Webflow developer with 10 years of experience in design and development.
So grab a pen or, I dunno open a Google Doc, and get ready to take some notes. Off we go!
Close cooperation: why it’s important
Kseniia: You’re a Webflow developer, so tell me first if you’re going to talk specifically about design in Webflow.
Alex: Mostly yes, but the following principles are relevant for designs created using web languages too. And a short disclaimer: some of my advice might sound quite categorical. But I urge readers not to treat them like that but to pass through the prism of their experience, projects they’re working on, business needs, etc.
K: Do you agree that designers and engineers should stick together when working on the project?
A: First, let’s get this straight in our mind: designers and developers should always work side by side. They must be in touch throughout the project, discussing design solutions, implementation methods, technical restraints, and everything in between. But it doesn’t matter whether they are from one company or not. For example, an independent design agency might create a design and then hand it to the client’s development team or another agency that does development. This approach works just fine.
K: That’s what I usually say to those who are about to redesign or design their products from scratch. If both designers and developers have a knack for what they’re doing and coordinate their efforts, there shouldn’t be any problems.
A: And the project manager’s role is quite important here. They should make it clear that miscommunications lead to cost and production problems, so they have to be reduced to zero.
K: Right, both sides must be interested in effective collaboration. Still, the project manager is the one who cultivates this delicate balance between designers and developers to come up with both user-centric and technologically savvy products.
Design principles to keep in mind
K: Let’s cut to the chase and discuss more specific things that should be considered when working on a project. What exactly should designers keep in mind to help the development phase to be as smooth as possible?
A: A myriad of things. For example, fonts. Sometimes designers use fonts without first checking if they’re paid or not. They might apply a free version forgetting that it may be a bit different from the paid one in line height, for example. So I recommend purchasing the font right off the bat and using it when working on the design and for development.
When handing the project to the development team, designers should send the font as a link to Google Fonts or an archive. Don’t send its name only. Such a thoughtless act will only lay up trouble for an engineer who will waste time seeking and downloading the font. And let's not exclude the possibility that on the Internet they may bump into a different version of the required font, which will only impose chaos to the project.
A: Here is another thing — icons. Picture the following: there is a page with a block of benefits. It has four icons from one set. They’re of the same color, seem aligned, and everything is fine. But when a developer gets to that block, they find out that one icon has a size of 42x42 px, another — 42x40, the third icon uses the mask when two icons are combined to create one single-color shape, and the fourth isn’t even in vector but in png.
Sure, a client could ask for that specific icon, which wasn’t in vector. The situations may be different. But here is how designers should approach that: they can take an icon in png and draw it in vector or transfer it there. The frames of all icons should be aligned to the same size and grid. And it’s vital to organize their layers properly.
K: Not so long ago, blur effects got trendy. And now we still see their popularity isn’t fading away. They are applied to various elements like logos, backgrounds, icons, header elements, etc. But I know that blurs might cause problems during the development stage. Is that right?
A: Not that they’re so problematic and totally banned from being used. But you’re right; sometimes, they get in the way of the smooth development process. The reason is as simple as that: when they exceed in number, they reduce the page performance tremendously. So they have to be cut to a minimum.
But this is where designers should think ahead and ask themselves whether they need so many blurs or not. Maybe it’ll be more reasonable to replace them with gradients or other visual effects where appropriate.
K: I guess after blurs and gradients, it’s high time to mention images.
A: Problems may arise when a designer inserts a picture into a layout, forgetting about its quality. Well, stuff happens. But it’s vital to remember that the picture must be in excellent quality, not only in 1x but also in 2x.
If the image is shoddy, and you insert it, let’s say, into a layout with a width of 1440 px, it’ll get even worse when zooming in. Call to mind that users will open the webpage on different monitors including widescreen.
Last but not least — copyright to images. It doesn’t affect the development speed or the product functionality, but there is one “but.” It’s always good to know that the images you use go with the license from the copyright owner.
K: Can we move to favicons and open graphs? I always wonder who should create them — designers or developers?
A: Let’s just put it this way: both favicons and open graphs are a part of the design. So obviously, it’s up to designers to create them. I would even insistently suggest making a separate open graph for each page.
K: Got it!
A: Before handing the design to the development team, it’s also vital to double-check that contact forms and menus are drawn in all states: default, error, and success.
The same goes for CTA/toggle buttons and other clickable elements. It would be very helpful if a designer creates all their states, including enabled/disabled, pressed/dragged, activated/selected, etc. Otherwise, developers will jog their memory or do it by themselves. And that’s where their look will depend only on the engineer’s skills and vision.
A: I’m not gonna go deep but also give you a gist of sub-pixels. They may pop up when a designer presses “K” in Figma to scale the layout in one fell swoop. This method is used to make an adaptive design, which isn’t good or bad; let’s just say it works fine. But only when a designer takes some time to put what they’ve done under a microscope and rearrange the blocks, check and correct each of them, and eliminate fractions. Otherwise, this easily avoidable mishap can lead to design inaccuracies and inconsistencies. And this work definitely shouldn’t fall on the developer’s shoulders.
A: There is one more thing I’d like to discuss. The screen height seems to be a tiny detail not worth mentioning, but it’s not like that.
Designers often use frames in Figma that don't correspond to the actual height of the viewport in a browser. But it’s crucial to remember that the page will be opened in full screen, so ignoring the bottom panel, the browser tab bar, and the bookmarks bar might play a trick.
Designers have to estimate the height accurately when working on a layout. And that should be considered during the design, not the development stage.
K: So many nuances of cooperation to keep in mind, but certainly nothing impossible or difficult to do. I think there is another essential thing to keep developers from problems. I’m talking about a style guide that is often underestimated. But this doesn’t seem right.
A: Well, the importance of the style guide is a rabbit hole we don’t have time to explore, but a crucial thing is this. It is improbable to ensure the logic and visual consistency of the product without a style guide, especially when different people work on the design. Some may leave, and others join the ranks — personnel changes are normal throughout the project.
If a designer quits in the middle of the process, leaving behind some completed pages, the next designer may continue working without a consistent idea about text sizes, palettes, grids, styles, graphic elements, etc. The changes may be tiny, like a slightly different color variation or text 1-2 pixels bigger, and a client may not even notice that. But you know who will notice them for sure? Right, a developer will see those failures. But it’s not their duty to jump through hoops to fix them.
At Lazarev.agency, we create a style guide and UI Kit, which is basically almost the same but with interactive elements and descriptions, for every project without a design system. We do care about consistency and a smooth project handoff to the development team. And a style guide lays an excellent foundation for that.
Final note
This is basically it for today! We hope that this short yet enlightening article in the form of an interview will come in handy whether you’re a designer striving to improve your approach to creating designs and cooperating with engineers; a developer who wants to know how to communicate with designers effectively; or a business owner looking for some insights to foster cooperation between tech and design teams for the sake of the project.
Don’t hesitate to make use of those recommendations. Share the article with everybody it may be helpful for.
.webp)
