Geekly Articles each Day
📜 ⬆️ ⬇️

Transferring a project from iOS designers to developers



Currently, the mobile development department of Rambler & Co is actively expanding, including in terms of iOS developers and UX designers. A large number of people and projects led by them complicates the already difficult process of transferring design to developers. Everyone, one way or another connected with mobile development, is familiar with the problems and disagreements that arise at the intersection of the interests of the programmer and designer - starting with what units to measure distances, and ending with who should cut screen elements in different resolutions. In order to finally solve the problem within our company, we decided to prepare detailed guidelines for this interaction.

Main thesis: The design of the application is considered complete only when the following materials have been submitted to the developer:
  1. Map screens application
  2. Map of colors used in the application,
  3. List of fonts used in the application
  4. The labeled states of each of the screens,
  5. Cutting elements for all screens,
  6. Video / gif with all custom animations,
  7. Application icons.

Now we will go through all the designated points one by one.

1. Screen Map
')


The map of the screens contains all the screens of the application and all possible transitions between them. For each of the transitions, the action that initiates it (for example, pressing a button or a specific user gesture) must be strictly indicated. Each of the screens must be designated in a certain way (sequence number, name, code). In the future, it is this designation that is used as a link to this screen (for example, when naming folders that contain resource slicing).

Since this designation can be used in the names of files and folders, it must meet the following conditions:

What should not be on the screen map:

We should also mention that the interactive prototype of the application in Invision or other services does not in any way replace screen maps.
Format: png, jpeg, pdf.

2. Color map of the application



A color map is an image containing a list of all the colors used in the application (both repeatedly and once).

Each of the colors should be represented by the following data:

Ideally, the color code is a number or a short word. These codes are used in screen layout to indicate the colors used.
Format: png, jpeg, pdf.

3. List of application fonts
The list of fonts is a text document that lists all the fonts used in the application. Only the font name is indicated; size in this case is not necessary to write.

If it is intended to use a non-standard font, it should be attached to the set of documents provided.
A list of standard fonts is presented here .
Format: txt, doc, pdf (for the list of fonts) . ttf / otf for non-standard fonts.

Sample font list:
  1. HelveticaNeue Regular,
  2. HelveticaNeue UltraLight,
  3. SuperHipsterFont (this font is attached separately).


4. Layout of screen states



In most cases, each of the screens may be in different states. Each of these states, including the ground state, must be presented in a separate file.

Imagine that we are marking up a list of email messages. It is called “messages-list-screen” . Cells on this screen can be in three different states - they may not be selected, selected and shifted sideways. In this case, you must provide three different files:

The name of each of the files must include the name of the screen used on the screen map and the status symbol (default, selected, etc.). Full markup is required only for the default state. The remaining files are marked elements unique to these states.

What the screen layout includes:

All dimensions are not in pixels, but in points. If the application should look different on different screens (iPhone 5 / iPhone 6), you need to provide markup for all occasions.

About differences points from pixels and screen sizes of various devices are well written here . Also, to have an idea of ​​adaptive layout, it is worth reading this article .
Format: png .

5. Cutting resources
The following types of resources are required:

All resources are provided in three sizes - standard (corresponds to the size indicated on the screen layout in points), @ 2x and @ 3x.
All interchangeable resources must be strictly the same size. Interchangeable are understood as such images that can be substituted in place of each other. As an example, the button in NavigationBar, which in some cases is a map icon, in others - a magnifying glass.

The cut resources should be located in folders whose names correspond to the name of the current screen (not the state, but the screen). It is not necessary to split into separate folders based on the size (@ 2x, @ 3x).
Basic rules for naming sliced ​​images:

If an element has several states (for example, it is pressed / not pressed), for states other than the standard one, the corresponding prefix is ​​added (-selected, -disabled).

If the same icon is used on several screens, then it is cut only once and placed in the common folder. It is important to ensure that different icons (even those located in different folders) do not have the same name.

More detailed guide on the name of resources.
Format: png .

Example:


6. Video non-standard animations
Since it is impossible to single out a set of standard animations in general, all planned animations should be discussed with the development team.

For all non-standard animations, explanatory videos or gif should be attached. In addition, you need to prepare a text description of what is happening: which parameter is animated, for what time, for which object. For example: "the title is increased by 2 times in 1 second at a linear speed" , "the image is rotated 90 degrees in 2 seconds with the smoothness function easeInOutQuart" .

7. Application Icons



Application icons should be square (without rounded corners) and provided in all required sizes. A list of sizes can be found here .

Automatically cut the icons in the right sizes will help this psd .
Format: png .

8. Screenshots for the App Store
AppStore requires five sets of screenshots in different sizes:


A good set of psd templates for generating screenshots of all sizes.
Format: png .

File structure of the set of documents provided
After all the above files are prepared, you should have a folder with a structure similar to:

Of course, in many cases it is difficult to demand from designers a completely finished package before the actual development begins - some of the screens can be updated, animations can be changed, and screenshots and icons are generally drawn at the end. As a solution to this problem - keep the entire folder shared on the file server or in the cloud, gradually filling it.

Some of these requirements may seem redundant, but experience shows that following these guidelines saves time, not only for developers, but also for the designers themselves.

Similar guidelines are currently being formed by a team of Android developers, so if readers are interested, we will definitely publish them in the near future.

Useful links:

Source: https://habr.com/ru/post/256397/

More articles:


All Articles