Traditionally, in any kind of publishing business there has always been a big gap between designers and implementation. Traditionally after the designers were done, whoever needed to implement designs had to do a lot of work importing the artwork into their work environment, and post processing assets. This has been a lot of pain for both designers and implementors as it required a lot of back and forth between different parties.
In modern web design there are now tools that allow us to have smooth, integrated website projects. Our vision is happy designers and happy developers! Happiness is now in your reach! 🙂 Please read on.
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:
Size: 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. If this happens, sometimes a complete redo is needed!
Grid: Design mockups that dont respect a standard grid like bootstrap4 are hard to implement!
Tools and Formats: Source file formats that are not intended for web design (such as Adobe Indesign) cause severe headaches amongst frontend developers.
Assets: If not all the assets are available in the quality required (vector shapes such as SVG icons, high-res images, webfonts, etc.) or the assets are not exportable from design tools, the frontend developers need to ask back, causing delays and unnecessary communication loops.
Process: Frontend development is really challenging when there are last minute changes and many feedback iterations, because frontend development requires a lot of time and therefore is costly. Also, if there are many different layouts and design elements, it's very expensive to fit them into standardized CMS components.
Read on to learn how we resolve these issues.
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.
Mockup Width:
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.
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>)
Font Size
The default global font size is 16px by default (= 1rem).
We recommend that the main body content should be between 16px and 20px,
The global default font size is important because it defines a global unit of 1rem that can then be used to define the height / size of other elements.
other sizes (e.g. H1) should be relative to the global default font size, measured in rem units . Please include such sizes for headings and other elements with a defined height in a note in your briefing to us.
Height of Vertical spacing
In CMS projects, the editor can select different vertical spacing items. It's important that vertical spacing is standardized across the site so that there is a limited number of items for the editor to select. We recommend not more than 5 items. Feel free to remove a default spacing or add a new spacing to this list please include a note in your briefing to us. Specify additional spacing items in rem or px.
FYI: By default, we use the bootstrap4 responsive spacers (technical info here)
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 an industry wide best practise.
Recommendations for Designers:
Use a standard 12 or 24 columns Bootstrap v4 grid.
⚠️ If you would like to use a different grid, please let us know before the start of the project.
There are many templates that facilitate designing for a responsive grid, here are some examples:
column gutter: Please be aware that the column gutter width is global (default: 30px) - This value should be identical across all designs. If you change the column gutter width please add a note to your briefing (in px).
These days, Designers that would like to provide assets to frontend developers overwhelmingly use Design Hand-Off Tools - see here for an intro: Design Hand-Off Tools.
Legacy or print software is a huge headache for Frontend Developers, as assets are rarely exportable in a quality / format that is apt for web development.
Recommendations for Designers:
Use a Design Hand-Off Tool that has a web interface. There are currently these options:
Sketch (web based, sketch.cloud)
XD (web based)
Avocode (web based)
Zeplin (web based)
Invision (web based, also note that there is Invision Studio, it's free.)
Further Notes:
Permissions: Make sure you assign permissions so that the web-based inspectors are available to frontend developers. Beyond link-sharing it's best to invite frontend developers with their email addresses and assign all available permissions to them.
Exportability: shapes (such as SVG icons), images and text should be selectable separately, and exportable in high quality. Please test this before handover and if in doubt, provide it as separate asset (see below).
Even when using a design handoff tool as described above, hand-offs remain tricky, because it's not always intuitive for designers to organize designs in a way that makes single images and shapes exportable.
Recommendations for Designers:
Images: Images need to be exportable from the web inspector in an optimized format (jpg or png) - make sure transparency still works! If the web inspector (i.e. invision) doesnt support asset export, please see below.
⚠️ Pay special attention to use the sRGB color space! Browsers may not fully support color spaces other than sRGB.
Non-exportable assets: If the inspector doesnt allow to export some assets (i.e. in invision web inspector, images are not exportable, upload and share them on Google Drive. Think about vector shapes (SVGs), images, stock photos, videos and web fonts.
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. Text copy should be selectable for copy and paste.
Styles: 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. Please test prior to handover.
Gradients: 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 project estimates.
Source files: Upload source files (.xd or .sketch) to Google Drive.
File Sharing: Do not use tools that provide links that expire after some time, as information might get lost that way.
File names: Please give your assets speaking file names so that the frontend developer doesn't have to rename assets.
Fonts: Please use a Google Font. If that's not possible, 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 (in this case you are responsible about Web Font Licensing. It's better to use open-source (non-licensed fonts) - please consider such an open-source alternative font.
Paid Assets: 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.
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.
Shared Folder Access: If you don't have access to the project's shared folder on Google Drive request access with the responsible project manager
File Versioning: Do not change the file name after updating a source file or asset (i.e. do not add a version 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).
Frontend designers expect signed-off, highly accurate (pixel-perfect) design mockups that leave no room for interpretation.
Recommendations for Designers:
First Steps:
Join the team on Slack! As a designer you are a crucial part of every project. Therefore please join the project channel on the what-digital slack organization
Join the project! Please ask for access to the gitlab project where all the tasks are managed.
Join Google Drive! Also ask for access to the project's shared folder on Google Drive so that you have A) access to any existing design assets and other briefing material and B) can upload (and keep up-to-date) the source files you create.
Components: In the end, all design and UX work for a website project that is based on a Content Management System (CMS) boils down to implementing reusable components (a.k.a. sections, elements or plugins) for the website editors. These components can be freely added, removed and stacked in any order, on any page, by any website editor. The fewer components, (i.e. the fewer exceptions), the easier and faster it will be for the developers to implement your designs. Keep a list of components and share it so that the developer can estimate the implementation efforts needed.
Completeness: frontend developers need your guidance across all screens and all aspects and states of the website or application. Make sure to include all states (i.e. menu-open state) and all screens. For complex application logic create wireframes (we recommend miro.com) for all functionality (all screens) and update the wireframes during the work on your separate design mockups.
For very big applications we recommend to create a design catalogue of components and high-fidelity wireframes that refer to those designed components.
Sign-off: In order to avoid loops and work done multiple times, get a full design sign-off based on your finalized mockups before handing them off to the frontend developer. The Frontend Developer doesn't expect the designs to change anymore.
Pixel-perfectness: As a designer, be aware that Frontend Developers will take your mockups literally. Make sure you are 100% accurate in every aspect of the design before you your work over. What you see is what you get.
Technical Requirements Documentation: Ask the developer to share his technical requirements documentation. Developers specify their point of view on the business logic and how they would like to solve certain challenges. By providing feedback on the developer view you can push the project in the right direction from the start.
Real content: Work with real content. If your designs contain Lorem Ipsum it is not possible for the developer to understand how much space to allocate and whether to account for special circumstances when it comes to website responsiveness. The content doesn't have to be the very final approved version, a draft version of the content is sufficient. The goal is that you convey a general idea of the content to the developer. Pay special attention to translations. The French or Italian version (as an example) is often longer than the English or German text that you might work with. If your design requires it, show a version with longer text that, for example, causes a heading or title to wrap into multiple lines of text instead of just one line. In general try to vary content to show all possible situations that could happen in real life. This is especially important for projects that allow editors to change content later on in a CMS (Content Management System).
Additional Documentation / Designer Notes: Provide a documentation for anything that is not clearly visible on the designs. In the designer notes explain your thoughts around certain elements that you think are non-obvious or counter-intuitive. Upload your mockups to miro.com and add visual signals (we recommend to use the speech bubble shape), thus documenting any special requirements and behaviors. Things that normally require additional documentation: Animations, responsiveness, and anything else that is outside the area of dominant web design standards and best practices.
Hand-over Meeting: Organize a hand-over meeting (we use Slack or Google Meet for online meetings) so you can go through your designs with the Frontend Developer. The "sound track" helps to provide context and avoid misunderstandings.
Design Implementability Review: The Frontend Development Team will do a design implementability review after the handover. They will check whether the designs are technically feasible and fit into the budgets for implementation. Please anticipate this and involve the frontend team from the start, so the Implementability Review goes smooth and no retrospective design changes need to be made by you.
Responsiveness: Sometimes designing only one breakpoint (i.e. only desktop, or only mobile) saves time and avoids over-specification. Our Frontend developers will apply the simplest possible responsive solution. This is sufficient for simple content pages. For application logic and more complex pages, mobile and desktop screens are required.
Design Review: Ask the frontend developer to schedule a design review with you once he's done so that you can give feedback, resolve open questions and influence the final touches, before the work is handed over to the client for approval.