how to submit a layout for development
Designers and developers have their own ideas about how it should be, and often they do not coincide. In this article, I propose to figure out how to make friends between a designer and a front-end developer and transfer the layout to development without losses.
Step 1. Starting the project
Before any new project, a designer often asks himself: “What project data is there at this stage and what needs to be drawn.” After talking to the manager and receiving the technical task, there is not always enough information about technical limitations. Therefore, it is advisable to familiarize yourself with the capabilities of the API, find out what data sets we will work with and what can be done with them.
After reviewing the documentation, we need to understand where we start and which screen needs to be delivered first. For this, meetings are scheduled with the developers, where we can discuss project plans, stages of screen delivery, and determine their priority.
At the meeting, agree on rough guidelines with the development team in advance. This will help avoid potential issues with text style, color scheme, icon sizes, etc. Also, don't forget to agree on technical capabilities and development deadlines, for example, when designing complex animations.
Step 2. Working with layouts
Maintaining structure
For simple and convenient navigation, any project should have a clear structure. Name pages and frames meaningfully.
This will allow colleagues to understand the logic of the layout and begin to navigate the structure more quickly.
Use a Changelog, a frame that contains a maintained, chronologically ordered list of changes for each version of the project. This way, the developer will always be aware of all changes.
Components
Components save the designer from routine. Having set the type of the component once, its automatically modified copies can be used in different parts of the project. Use them to the maximum, creating a library of components. And do not forget to show all the states and descriptions of each component.
Component Description
When describing each component, try to put yourself in the shoes of the developer who is about to take the layout into work.
Create a dock frame for each component that will contain:
Think through and describe your component in detail, such as all types and sizes of the component, possible configurations, maximum and minimum width of the component, etc.
When creating a component, include all states in advance. All possible loadings, active and inactive states / on hover / click in empty and filled form / errors, etc.
Lifehack: you can see an example description for the “Button” component on the website Carbon Design System.
Adaptability and Grids
Adaptability
Adaptability is the ability of a layout to adapt to different screen resolution formats. Make it a rule to draw several adaptive layout options for different devices. Three to four versions are enough (For example, for the web: from 1280 to ∞, 1024, 768, 320).
Don't forget to draw layouts for the minimum size, or always check or set the size on 320px screens.
Show responsiveness with Constraints in Figma, i.e. bindings. If you draw four layouts, then for each of them you must write constraints.
Lifehack: when drawing an adaptive, you need to take into account the Landscape (horizontal position) state. Especially if the use of your product requires it. Relevant for maps, navigators, video playback.
Net
To avoid disagreements between the designer and the developer regarding indents and distances, a grid is used. The grid helps to organize the elements correctly.
For mobile devices, 4px or 8px grid is usually used.
As a result, any layout element except lines always has a size that is a multiple of four or eight. This automatically removes all questions about random offsets, fractional pixels, etc.
For the web, the well-known Boostrap grid is used.
There are two types of grid:
Fixed grid – a grid in which columns are fixed in width.
A flexible grid is a grid in which the speakers change their width depending on the size of the device.
Lifehack: add created columns/grids to the style. To apply columns to the artboard, simply select it and choose the style corresponding to the layout resolution in the Design panel in the Layout Grid section. Enable/disable display of columns and grid: Ctrl + G (for Mac), Ctrl + Shift + 4″ (for Windows).
Screen Maps
The screen map shows the entire User Flow, preventing the developer from getting confused in the product architecture. With the screen map, the logic of transitions and interaction with the interface for specific cases will be clear.
Lifehack: you don't have to draw paths manually, there are many plugins for that. I use AutoFlow, ArrowAuto.
Notes to the developer
Leave notes for the developer. Such as a description of the component's action when clicked. Select the Master Component, click the settings icon, and in the Documentation window that appears, enter text in the “How to use this component” field. The text will appear as a comment in CCS.
Before submitting layouts for development, remove all unnecessary things: sketches, layout options, references. But do not delete developments and layouts that have lost their relevance. They may be useful for future work. Collect them in a separate project page. For convenience, you can use the plugin Archive.
Automatically Organize and Clean Up Your Figma Document with a Plugin Clean Document. It allows you to delete hidden layers, ungroup single-layer groups, etc.
Step 3 Transfer to development
Readiness status and versioning
If you are handing over mockups for development and working in parallel, do not forget to indicate which mockups are ready. There are several ways to clearly indicate the status of readiness:
If there are global changes in the layouts, for example, the structure of a section on the site has been changed, then try to divide the layout into versions, i.e. create a new version for each new page.
Minor changes, such as changing the appearance of an icon in the interface, can be recorded for developers in the Changelog.
Prototyping
The developer does not always understand which element should interact with what and how in the interface. This requires prototyping. Transitions and simple prototypes can be assembled in Figma. For more complex animation, you will need additional tools: Principle, After Effects, etc.
Lifehack: if you lack complex animation skills, attach animation references in the form of screenshots and links.
Remember that any complex animation can make your interface attractive, but it can also slow it down a lot.
Graphic assets and fonts
Developers can request to upload graphics for each platform in its own format. To avoid wasting time on this, you can do the upload automatically using the plugin Export Presets. The plugin helps to generate assets in the required format in one click, including default presets for the most popular platforms.
When using non-standard fonts in the layout, do not forget to attach the archive or provide a download link.
Analysis of the scope of work and communication with the developer
After preparing the layouts, evaluate how much work has been done. Break the layout into several tasks, call the developer and discuss the work plan. Then transfer all the layouts to development.
If you don't work in Figma but use Sketch, you can transfer mockups to Zeplin.
Step 4 Design Review
At the design review stage, the designer’s task is to compare design layouts and the logic of the work.
Feedback from developers
At the review stage, additional nuances may emerge that were not taken into account in the work: they forgot to show all the states of the states, the font on the screens is hard to read, there is contrast in the design. Work with feedback from the developers. They have experience and programming skills and can advise how and where to simplify the interface, reduce the user's steps/clicks.
Lifehack: Use comments in Figma as an additional communication tool. Participants can read, add mentions, and leave comments on the file without restrictions.
Edits
It is almost impossible to do everything perfectly! Do not delay and write edits from the moment you receive the first build. Check everything on different device sizes, platforms. The sooner you start checking, the fewer errors will go to production.
Lifehack: take a screenshot of the screen assembly and attach it next to your layout. Record it next to the edit screens and send it for revision.
Once the developer has made all the edits, the task is transferred to QA.
I hope this guide will help you learn how to transfer layouts to development quickly and without losses, and will also save you time and effort on revisions.
And if you want to know how to know how to manage user attention, read my article about the laws of attention control.
