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.