Traditionally, in any kind of publishing business there has always been a big gap between designers and implementation. We come from a world, where after the designers were done, whoever needed to implement designs had to spend a lot of work importing the artwork into his work environment.
In modern web development, for the first time in the history of mankind, smooth, integrated handovers between designers and developers are in our reach! Here is how.
The challenge
For website projects, the handover between the design phase and the development phase can be difficult and time consuming. Here are a couple of reasons why:
- Some designs look smaller when looking at them as mockups than after they are implemented as websites. This is then a big surprise for customers.
- Not all the assets are available in the quality required (vector shapes, high-res images, webfonts, etc.)
- Developers cant work with source file formats that are not intended for web design (such as Adobe Indesign)
- The design doesnt use a standard grid and therefore requires significant additional effort for implementation
- Some frontend developers use Linux and therefore cannot open Sketch files because Sketch is not supported on Linux
Therefore we created some guidelines for designers:
1. Design Mockup Sizes
Have you ever read “Objects In The Mirror Are Closer Than They Appear” on a side-view mirror? The same happens to mockups. They often look smaller than they will appear once implemented in code. Also, designers often work with very big screens 19 or 22 inches, while clients often use their business laptops at 13 or 15 inches.
Recommendations:
- Use 1920px (wide screen version) and 1440px (normal desktop screen version) for the artboard width itself and 1170px for the content width. A suitable sketch template can be found here.
- This setup allows a frontend developer to see what elements should stretch out to full screen width, and what elements are limited by the content width.
- The 1170px content width will allow the client to preview the design in its full width even on smaller screens and in general is aesthetically pleasing.
- Main body content should be between 16px and 20px, and other sizes (e.g. H1) should be relative to that
- Show the mockups to the client in a way that is not zoomable. Use a design hand-off tool (see below) – why? It doesn’t auto-scale the mockups based on the window width of the browser. If you use images or PDF, the content of the window is auto-scaled based on the window width of the browser or image preview tool on the client’s computer. Alternative: Send the client an HTML where the mockups are added as background image of the body element (
<html><body style="background-image: url('img/mockup1.jpg'); height: 3500px; background-repeat: no-repeat; background-position: center top;"></body></html>)
2. Design Grid
These days, most websites are implemented using a responsive grid. Using a grid ensures that websites are readable and look good on many different devices and screen sizes and makes web frontend programming more efficient and robust.
The most commonly used grid is part of the Bootstrap v4 frontend framework, but there are also other grids on the market. Creating website designs and mockups that are compatible with such grids is a industry wide best practise.
We recommend that you always use a standard 12 or 24 columns Bootstrap v4 grid.
There are many templates that facilitate designing for a responsive grid, here are some examples:
3. Smooth Design Handovers
The topic of design handovers today is nearly fully covered by using Design Hand-Off Tools – see here for an intro: Design Hand-Off Tools
Best Case: Use a Design Hand-Off Tool!
How does paradise look like for a frontend developer?
The best case for frontend developers is when the design comes in a Design Hand-Off Tool. Like this, the frontend developer can extract all the required assets directly in the tool and use them to build the real high-resolution website. Awesome!
There are currently three options:
- Invision (also note that there is Invision Studio, it’s free.)
- Avocode
- Zeplin
Note:
- vector shapes (such as icons), images and text should be selectable separately so that it can be exported for production.
- For text: text properties (such as text size, text decoration, text style, font-family, etc.) should be properly displayed in the tool, when selecting the text.
- For layouts it’s important that properties such as border radius, shadows, height, width, etc. is properly displayed in the tool, when selecting a box or other type of layout.
- If the design has almost-unnoticeable gradients (eg for visibility of the text on top of bright images) – mention them explicitly during the hand-over, otherwise they might go unnoticed and end up being excluded from the estimates.
Second Option: Use a web design tool
If it is not possible to use a Design Hand-Off Tool, it’s still possible to do an efficient handover to the frontend developer. In this case please make sure that all assets can be exported separately and are available in high-resolution. Please check if the responsible frontend developer has access to the web design tool (i.e. Sketch is not available for Linux) and in case there is a problem please provide the assets separately (see below).
Here are the main options on the market (some of them are Mac OS only!):
Fallback Option: Use a conventional graphic design tool
Handing over design in a conventional graphic design tool will mean significant additional efforts for frontend developers, as the asset extraction takes more time. (TODO: add some more reasons why)
In this case please make sure that all assets can be exported separately and are available in high-resolution. Please check if the responsible frontend developer has access to the web design tool (i.e. Sketch is not available for Linux) and in case there is a problem please provide the assets separately (see below).
Such tools are:
- Adobe Illustrator
- …
Deprecated tools that shouldn’t be used anymore for web design handover and which we dont support anymore:
- Adobe Photoshop
- Adobe Indesign
- …
In this case please see below for a traditional hand-off as separate files.
Handing off assets as separate files
In order to maintain full compatibility with the frontend developer’s technical means, designers might need to hand off assets as separate files on Google Drive.
Assets like vector shapes, images, stock photos, videos and web fonts
Please provide all the assets separately on Google Drive (see below), so that the Frontend Developer can use these files to build the website. Use speaking file names whenever possible to facilitate the frontend developer’s work.
- images in high-resolution (.png / .jpg)
- web fonts (.woff / .woff2 )
- vector shapes (.svg)
Fonts
- Please help us by uploading a zip file of the web fonts to Google Drive
- if you only have .ttf fonts you can create a web font package on https://www.fontsquirrel.com/tools/webfont-generator
Assets that need to be purchased
- Normally, the client is purchasing any paid assets directly via credit card.
- While working on a design proposal that includes assets that need to be purchased, you can use preview or trial material, other sources (i.e. fonts you have already installed, etc.) for the mockups.
- Upon design approval you can create a gitlab issue on the respective Gitlab project, asking the client to purchase the corresponding assets. Please include the direct links to the items to be purchased for the convenience of the client. Many thanks.
Uploading your source files (.xd, .sketch, …) and any other assets to Google Drive
- In order to enable frontend developers to work efficiently, it’s important that all your source files are in the project’s Google Drive folder and that you keep them updated at all times so that the frontend developer always have access to the latest version.
- If you dont have access to the project’s shared folder on Google Drive request access with the responsible project manager
- Do not change the file name after updating a source file (i.e. do not add a version string or date to the filename). Google Drive automatically creates a new version of the file if the file name is the same. The old versions are still accessible via the context menu (right click on the file).