Constraint Layout (for Designers)
An introductory guide to handoff responsive mobile layouts
Back in my day *adjusts glasses* designers had to take development classes and red line all of our files by hand!
Now with nifty tools like Zeplin and Abstract, designers spend little to no time on handoff. Unfortunately a lot can get lost in translation. Is this button a fixed size or responsive to the screen size? Is it this specific amount from the bottom or centered within a larger object? Let’s bring back the craft of the handoff with constraint layout symbols.
Constraint layout is defining the rules that govern the content in your app. The rules encourage consistency across platforms, environments, and screen sizes by using uniform elements and spacing. It exists in iOS and Android.
This Sketch file that has all of these elements ready for you to get started!
You start by defining your base unit that every measurement is a multiple of. I recommend the even number 8 to size and space elements because it makes scaling for a wide variety of devices easy and consistent.
- 8 is more divisible! 10/4=2.5 vs 8/4=2
- The majority of popular screen sizes are divisible by 8 which makes for an easy fit (vs 6 or 10.)
- Devices that have a 1.5x resolution will have a hard time cleanly rendering an odd number. Scaling 5 by 1.5x will result in a half pixel offset.
In Sketch > Preferences > Canvas, switch the “move objects  px using Shift-Arrow keys” to . It will save you a lot of headache.
Spacer units are visual representations of common spacing labeled with the multiplied amount of the base unit. For example, a “2 spacer unit” is 16 pt/dp because 2x8=16. These symbols should be used in design and the alias should be built it code so you speak the same language at handoff.
Sometimes there is not enough time in the day to be pixel-perfect — you’re going to make mistakes. By using these symbols instead of the auto-magic red lining, it tells your engineer the spacing intention vs the actual spacing. The number alias matches the number of times you ‘Shift + arrow key’ move an object instead of memorizing the multiplication table for 8s.
The spacers never change size. If it is a horizontal spacer, the vertical height is locked and for a vertical spacer vice versa. Meaning across different phones widths the size of the component will change, but the spacers used to create it’s margins will remain the same.
Sometimes elements align in-between spacers. The main ways to align in-between spacers are center alignment and base alignment.
Center alignment is when you want an object, or a group of objects, to be centered in-between two spacers. Objects can be centered horizontally, vertically, or both.
Base alignment is when you want objects to align to the base of one of the objects. This is common when you have two different text sizes and you want to align then at the baseline.
On mobile, the minimum tap target size is 48x48 dp/pt. This comes from the Material Design guidelines for a distance of ~12". (The HIG recommends 44x44pt, so I go with the larger one.) Account for the tap target size when placing elements next to each other. You can also use the tap target symbol to denote which parts of an element are tappable.
Let’s test out handing off using all of the constraints with some example components:
The component’s base size, it’s minimum height and width, should be based on the minimum tap target size. Components that are visually smaller than the tap target should still be triggered by the same minimum tap target size. This means if a user touches a little outside of the checkbox, we acknowledge that they tapped the checkbox.
Use spacers to indicate padding within a component.
You can set a horizontal limit of an element, like a text box, by setting horizontal padding. When copy gets too long, you need to indicate whether the text should resize, wrap and/or truncate. Wrapping to two lines is better than truncating one for translations!
Vertical padding is used most commonly in preparation for translations and Dynamic Type. Although your components may look great at the current phone size, current language, and current type size — all of those factors are variables that have worst case scenarios. When type grows, the component will become larger than it’s base size and you want to make sure it still has vertical padding.
Use centered and baseline markers to indicate how you intend for items that aren’t touching spacers on all sides to behave.
Now you’re ready to put together a screen! Use the spacers, tap targets, and alignment symbols the same way you did in the component.
… and voila! There you have it folks — a responsive mobile layout!
Tip — Create separate symbol artboards for your components that you reference inside the screen layout. In the component symbols you can include all of the component specifications in a folder that can easily be turned on and off. Nothing looks more like the diaries of a mad man than trying to markup a component and the screen layout at the same time.
Even a perfectly crafted handoff file doesn’t replace good ol’ fashion verbal communication with your engineer. This should be used in conjunction with kickoffs, handoffs, and written documentation. The more you keep your engineers in the loop with your design, the closer it will be to what actually ships. And! Handoff specific files for both mobile platforms — always.