Step 1. Requirements for Design:

Design team prepare design for 4 type of resolution: 1920 > PC > 1280 > Tablets > 1080 > Mobiles > 720

This is because design team does not use modular grid. The 720px is a largest screen checkpoint, 360px is most popular and design must respect it too. Thats why we need to use one column solution (etc) in mobiles.

Structure

1. Maintain order in the document Designers will follow the naming convention of pages and screens

   

   Bad Decision | Good Decision

   Frames that are connected in one logical group, will be on their own page, including different resolutions. Example:
   Login/registration page (mark approved) - include resolution for pc tablet and mobile.

2. Use Changelog

   Use Changelog, a frame that contains a maintained, chronologically ordered list of changes for each version of the project. This keeps the developer up to date on all changes.

   

Components

1. Build a library of components and UI KIT

   As you work, collect all of the standard interface elements into a separate document page and convert them into components. This way, by the end of the project, you will have a design system: the developer will see all the standard design elements at a glance

   

2. Watch the size of text blocks and modules

   It seems that if the text block is much bigger than it needs to be, then nothing bad will happen - there is no text there anyway. In fact, it's a sign to the developer that the text stops should be exactly like that, because the designer came up with something there. This can make the final layout turn into garbage.

   

   Bad Prototype | Good Prototype

   Another property of text is that it can be infinitely long. If you don't take this into account, prepare to have the final layout break all the time.

   

   Bad Prototype | Good Prototype

Other

1. Use integers numbers in design. Pixel perfection will be taken care of in the design.

   Developers make sites in CSS and HTML - they count all images and distances in pixels. The default pixel cannot be fractional, so it is very difficult to implement a 27,789 pixel size pinch or indent.

2. Show states and scenarios. Content will be provided

   If you show a checkbox, switch, or similar interface element, don't forget to demonstrate its states. Ideally, describe what it activates and how it should work within the system.

   

   Bad Decision | Good Decision

   Another important thing is that the screens communicate with each other. For the system to work the way you want it to, the developer must understand what will happen if the user clicks on one of the buttons inside the screen. This connection can be shown with arrows:

   

   Bad Decision | Good Decision

3. Make notes

   If you're worried that some of the effects the layout designer might do wrong, leave a comment for him with a description. This will save you time in coordinating the result.

4. Show the animation live

   Any animation is very difficult to describe in text or words - there's always a chance that the developer will misunderstand you. To avoid this situation, send the layout with live animations right away - you can make them right in Figma or provide links to pages, screencast with desired animation in existing products.

Step 2. Transfer to frontend

Readiness status and versioning

If you're submitting layouts for development and working at the same time, don't forget to indicate which layouts are ready. There are several ways to explicitly indicate readiness status:

• Indicate the status in the layout itself. Mark the statuses on each group or on each layout.

• Divide into separate paging. Split layouts into tabs according to their readiness: ready for development / in progress.

  

Design validation