It is important to clearly communicate your design vision and specifications to the development team in order to avoid any confusion or uncertainty. We suggest that you create a prototype, as well as a design handoff document in order to communicate intentions.
Inconsistency in the high fidelity mockups can lead to unnecessary complexity in creating custom CSS. It is best to reference the styleguide and variable documentation versus measuring specific spacing or font sizes.
Each team and organization will have their own process and procedures relating to the design handoff. We recommend the following best practices during handoff:
To help your developers translate your design to code, create an iron-clad design system. Ask yourself:
- Are the units of spacing you’re using for padding and margins consistent?
- Do you have a defined colour palette — including neutrals — with clear notes for usage?
- What fonts are you using, and for what purpose? Do you have a prescribed range of font sizes and weights?
- What icons are you using? What sort of spacing should they have?
- Do different styles of buttons have different meanings?
- Have you considered different states? (e.g. focused, active, disabled.) Are they consistent between different elements?
Maintaining a system will make it much easier for your developers to code your designs, and maintain in the long-term.
The layout on the right uses this system:
Creating a Design System
The best systems are derived from a minimal set of rules, which encourages consistency and visual rhythm. A lot of the systems work we’ve done is around layout and micro-layout. A layout describes the arrangement of components (discrete pieces of the user interface). Micro-layout describes the arrangement of elements within components.
Here’s how you’d get started creating a design system:
1. Choose a default font size
This should be the body text size and be large enough to read on small screens at the typical viewing distance. We recommend choosing
16px for this value. This is because Google's Lighthouse audit takes font legibility into account, and broad use of fonts that are below
16px in size will result in an SEO penalty. We generally consider 14px and less to be too small for body text as most people don’t have perfect eyesight, and anything below this value is difficult to read at an average reading distance. (For more information, read Typography In Ten Minutes.)
2. Choose a default line-height and leading increment
The default line-height should be derived from the font-size and the typical line length (measure) of the text.
On phones (mostly in portrait), the measure is short, and doesn’t require quite as much leading as long line-lengths as on desktop.
A line-height value for desktop of
1.5 is a good starting point. For most of our designs, we’ve used something between
1.4. Usually, for a size with
16px font size, we’ll use a
20px line-height (but your own typesetting may vary depending on the font used).
The leading increment determines your other possible line-height options. It should be the smallest sensible factor of the line-height; you should usually go with
4px (20 ÷ 5 = 4). That way it allows more flexibility in setting incremental leading, and is an even factor of the unit as well.
3. Choose a basic layout unit that is a multiple of the leading increment
Usually you can use
8px. The layout unit is used to define a grid over the viewport that acts as scaffolding. Components should align to the grid, or, if necessary, halfway between grid lines. In our stylesheet scaffold, the layout unit is simply called "unit."
More Decisions to Make
Many other decisions can now flow from these initial three:
- A type scale can be built around the default font size:
- heading B:
- heading A:
- A leading scale falls out from the default line-height and leading increment. For mobile, only two or three additional line-heights need to be chosen:
- Outer layout margins (left and right) are usually set at
16px(2 × unit), which is as little as you can really get away with with a base font size of
- Additional keylines can be drawn as alignment points for various elements. The main one is about
64pxin from the left viewport edge. This defines the left edge for inset text when accompanied by markers at the margin: list bullets, checkboxes, or icons.
- Gutters, and spacing in general, can be whatever is needed in multiples of the
Creating a Styleguide
The styleguide records the logic behind your design system and any notes and you may want to communicate to developers. Start your styleguide before you start your mockups and adjust it as you go to ensure accuracy.
If you create your styleguide sections on artboards that the same width as your mockups, you can add them to the internal InVision project! That way it’s easy for developers to find and ask for clarification (with comments).
This is the basic overview of the design system that will be used for the project. This will help in setting up the project and making sure that the design is consistent throughout. Styleguides should include content relating to:
- Color Swatches
- Brand Colours
- Units and Margins
- Tap sizes
- Sections & Separators
- Font family
- Font sizes
- Line height
- Default typeface
- Alignment practices
- Calls to Action
- Text links
- Form Elements
- Text input
- Checkbox & radio
Design Mockups & Assets
Provide links to the design mockups and supporting assets you have created as you progress through sprint work. Links might include:
- Dropbox (or similar) link to the source files (
- InVision Prototype links
- Zeplin, Sketch Measure, or InVision Inspect links
Writing General Design Notes
Design notes should detail a walk-through of all interactions, elements, and components. General design notes should start by documenting all the global elements and components referencing specific asset names and variables so that the development team can easily cross reference as needed.
Once the general global documentation is complete further documentation should match the sprint deliverables for the project.
The following are a couple tools that we’ve used here in the past at Mobify. These are completely optional, but you may find that using these tools can save on a lot of back and forth communication between designers and developers.
InVision Inspect is a web-based design inspector that integrates with InVision. We strongly recommend providing designs using InVision Inspect. It provides many of the features of Zeplin, whilst being fully integrated into your InVision prototypes. Using InVision Inspect is as simple as uploading a .sketch file, or syncing your .sketch file with InVision Sync, or pushing up individual artboards with CraftSync. Read more about InVision Inspect.
Zeplin is a design specification app that provides both a native and web view. Zeplin is meant to bridge the gap between developers and designers by providing a detailed inspector that reveals design details that include (but are not limited to), colour values, spacing values, icon asset export, typographic specifications and more.
We don’t use Zeplin at Mobify exclusively, but this can be a handy resource when in mixed OS working environments. For example, if designers in your organization work in Sketch for macOS, but developers work on Windows, cross-platform Zeplin would resolve the issue of sharing
.sketch files with Windows users. (Sketch is available only on macOS.) Read more about Zeplin.
Sketch Measure is a free plugin that provides many of the features of InVision Inspect, including colour values, spacing values, icon asset export, typographic specifications and even Sketch defined comments. Note that if you export design specifications using Sketch Measure, you’ll need to webhost the outputted HTML markup and associated assets for easier sharing. Read more about Sketch Measure.