Handoff guide for pixel-perfect design. Part III
UI kits
A UI kit is an inventory of every element you use in a project. It helps you keep everything up to date and makes maintenance much easier when a team is working on large projects together.
A UI kit should capture the project's colors, typography, components like buttons, form fields and sliders, and their different states, such as hover, active and default. Apply the D.R.Y. principle ("Don't Repeat Yourself") when deciding whether an element belongs in the UI kit. If you have two similar elements across your artboards, move one of them into the UI kit. In the artboards of designers who don't use UI kits, you'll often find two, three or four different buttons with tiny, irrelevant differences. In those cases, the developer will most likely end up implementing all of them instead of building a single, unified version.
We recommend Craft for building your project's UI library. On larger projects, it's worth keeping an HTML and CSS version of the UI kit as well, and using it as the reference for everything else.
Exporting
Make the developer's life easier and boost your chances of achieving a pixel-perfect design by using one of these tools:
These tools help you pull colors, fonts, sizes, assets, spacing between elements, CSS properties and much more straight out of your Sketch or PSD file. Invision and Zeplin also let you write notes without forcing you to create extra layers, unlike Photoshop.
Element states
To avoid misunderstandings, we recommend using consistent terminology for the different states of an element, just like in CSS. That way developers will know exactly what you mean without needing lengthy explanations.
- Default
- Hover: the state of the element when the cursor is over it
- Active: the state of the element while it's being clicked
- Focus: the state of the element when it's selected via keyboard or activated with the mouse (for example, text fields and text areas)
- Visited: the state of links that have already been visited
Line-height
Line-height is a crucial part of both design and the handoff process. The key is understanding how the browser renders each element and how line-height affects that. Look at the image below: it's a typical example of a block of text as rendered by a browser. The height of the element matches the line-height, and the height of the individual characters doesn't match the height of the element as a whole.
One advantage of Sketch is that it renders text objects using the same logic. Photoshop, on the other hand, doesn't size elements based on line-height.
Best practice is to use a line-height that's consistent with your fonts. Don't use too many different, custom line-heights across the site. Every font has a default line-height. Roboto, for example, has a line-height of 1.4 times the font size: if the size is 16px, the line-height will be 22px. Even if you decide not to use the default value, try to keep the same ratio throughout the site. Common values range from 1.3 to 1.6 times the font size. Developers will love this, since they'd rather set a global line-height, forget about it, and just work with font sizes.
Now, a few notes on how different browsers handle decimals. Let's start, for example, with these values:
- Font size: 36px
- Line-height: 1.4
Chrome, Safari and Opera: these only calculate whole values and truncate the decimals. 36px * 1.4 = 50.4, which gets truncated to 50px.
Firefox: calculates with decimals. 36px * 1.4 = 50.4, and it keeps it at 50.4px. If you have two lines of text like in the example below, that comes to 100.8px. The main difference from Safari and Chrome is that, if you choose a line-height like 1.41, those browsers will give you 100px, while in Firefox the container will measure 101.533px.
The takeaway is that Firefox uses more precise line-height values, like 1.33333. If that's not a concern for you, stick with clean, round numbers, like 1.3.
Fonts
First, try to find fonts that work for you on Google Fonts. Browsers support different font formats, which means that to use certain custom fonts, the developer will need to prepare them using specific services that convert ttf/otf to woff, woff2 or eot. Fonts can lose quality during that process. So our recommendation is to only use custom fonts if you know your developers won't mess up the process. They need to know how to work with fonts.
A couple of things to keep in mind when using fonts:
- Don't use more than two fonts. It affects page load time, especially with custom fonts.
- Don't use too many different sizes or styles (italic/bold/light/thin/regular).
Developers and designers
Sometimes designers hate developers because they can't bring their ideas to life, and sometimes developers hate designers because they ask for features that are technically hard to implement. These problems are solved with something very simple: talking. Talk to your developers, and not just at the final stage. Share your ideas before you start drawing, because dropping an idea early on is no big deal. If you do that, you're less likely to end up disappointed with the result.
We believe it's always possible for developers and designers to reach a reasonable compromise and work together effectively to cut down the cost and timelines of their projects.
Part 1: software, naming conventions, image optimization, sprites, SVG and favicon
