Как подготовить макет интерфейса мобильного приложения к передаче в разработку?

Или «как сделать вашего разработчика счастливым, а финальное приложение точно сверстанным по макету».

Каждому, кто так или иначе связан с мобильной разработкой, знакомы проблемы и разногласия, возникающие на стыке интересов программиста и дизайнера мобильного приложения, когда речь заходит о том, как правильно подготовить и передать дизайн в разработку.

Проанализировав свой многолетний опыт работы, я с уверенностью могу сказать, что:

Дизайн мобильного приложения считается законченным только тогда, когда разработчику переданы все необходимые для его верстки материалы, а это далеко не только один макет.

Основное, что должен получить от вас разработчик:

1. Дизайн-макет приложения, выполненный в Sketch, Figma, XD, Photoshop, Illustrator, в виде файла или ссылки.
2. Дизайн-макет приложения, загруженный в Zeplin, Sympli или другой инструмент для «просмотра макета глазами разработчика», в виде ссылки.
3. Карту экранов приложения, выполненную в XMind, MS Visio или другом похожем по функционалу инструменте, в виде файла или ссылки.
4. Кликабельный прототип, выполненный в Marvel, InVision или другом похожем по функционалу инструменте (Sketch, XD, Figma, Framer, UXPin, и пр.) в виде сслыки.
5. Иконки и иллюстрации использованные в дизайн-макете для всех плотностей экранов в виде файлов: mdpi, hdpi, xhdpi, xxhpdi, xxxhdpi — для Android и @1x, @2x, @3x— для iOS.
6. Шрифты, использованные в дизайн-макете, в виде файлов.
7. Видео-файлы со всеми нестандартными анимациями или ссылки на примеры таких анимаций из других приложений.

Немного расскажу поподробней про каждый пункт.

Непосредственно сам макет

Дизайн-макет приложения может быть выполнен в любом удобном вам и вашей команде инструменте. Как правило, это Sketch, XD, Figma, Photoshop или Illustrator. Другие инструменты are fine as well, но лучше использовать что-то популярное.

В чём бы вы ни работали, ещё раз проверьте, всё ли внутри макета в порядке, а именно:

1. Используются pt в качестве единиц измерения.
2. Используется сетка 8x8 pt для Android и 10x10 pt для iOS и к ней включена привязка (а не к пикселю).
3. Все артборды созданы для базового ppi (в @1x или mdpi).
4. Все артборды, группы и, по возможности, все слои адекватно проименованы («Rectangle copy 59» или «Group 12» быть не должно).
5. Все иконки и иллюстрации помечены как «exportable» и имеют понятные имена.
6. Нет пустых или недоделанных экранов, элементов.

👉 Зачем это? Это просто контроль качества. Если макет сделан некорректно, то это так или иначе приведет к конфликту или правкам. Лучше сделать хорошо сразу.

Макет для «просмотра глазами разработчика»

Макет нужно загрузить в Zeplin или Sympli. Ну или сгенерировать ссылку для разработчика, если вы работаете в Figma или Sketch.

👉 Зачем это? Это делается для того, чтобы разработчик мог посмотреть все спецификации (отступы, размеры, цвета, названия шрифтов и пр.) и при этом не открывать оригинальный файл с дизайн-макетом в редакторе, которого, к слову, у него может и не быть.

Карта экранов

Карта экранов — это изображение, которое отражает в себе все экраны приложения и все возможные переходы между ними.

Не самый наглядный пример, но при ближайшем рассмотрении всё понятно

Для каждого из переходов желательно обозначить действие, инициирующее его (к примеру, нажатие кнопки или определенный жест пользователя). Каждый из экранов должен быть определенным образом обозначен (например, номер или название).

Карту экранов лучше всего рисовать в инструментах для составления mindmap’ов. Мои любимые, например, XMind и MS Visio.

👉 Зачем это? Карта экранов поможет разработчику разобраться с логикой приложения. Из нее он сразу получит ответы в стиле «что будет, если нажать на это?».

Кликабельный прототип

Кликабельный прототип — это интерактивный макет, цель которого в данном случае также показать разработчику, как должно работать приложение, согласно вашей задумке.

Кликабельный прототип в Marvel

👉 Зачем это? По тем же соображениям, что и карта экранов. Одно можно заменить другим. Но, как правило, кликабельный прототип более нагляден для разработчика и для клиента.

Экспорт иконок и иллюстраций

Нужно экспортировать и разложить по соответствующим папкам все использованные в макете иконки и иллюстрации в формате PNG для всех 6-ти плотностей экранов (mdpi, hdpi, xhdpi, xxhpdi, xxxhdpi) для Android и в формате PNG или PDF для всех 3-х плотностей экранов (@1x, @2x, @3x) для iOS. Также можно использовать SVG, тогда достаточно по одному файлу.

Обязательно все иконки и иллюстрации должны быть адекватно проименованы в соответствии с принципами:

1. Только латиница.
2. Вместо пробелов нижнее подчеркивание.
3. Только нижний регистр.
4. Для иконок префикс «ic_», для иллюстраций «ill_», для фото «pic_».

Итого, у вас должна получиться следующая структура:

👉 Зачем это? Если разработчик будет сам экспортировать иконки, то что-то обязательно пойдет не так. Поедет цвет, иконки станут мыльными и так далее. К тому же, он будет вынужден потратить время на то, чтобы разобраться с тем, как их экспортировать и как назвать, вместо того, чтобы кодить. Лучше избежать этого и сделать всё самому. Тогда разработчик просто скопирует всё в Android Studio или XCode и будет счастлив.

Шрифты

Нужно сложить в отдельную папку все шрифты, использованные в макете. Если это платный шрифт, то ссылку на место, где его можно купить. Но лучше не использовать платные шрифты.

👉 Зачем это? Если разработчик будет искать использованные вами шрифты сам, то есть вероятность того, что он найдет не тот шрифт или, например, устаревшую версию шрифта. Лучше всего будет просто потратить 2 минуты и сохранить шрифты отдельно.

Видео с анимациями

Если вы сделали очень клевую нестандартную анимацию интерфейса в After Effects или Principle и хотите её реализовать, то её тоже нужно экспортировать и передать разработчику. Можно как в видео-формате, так и в формате GIF.

Если же вы просто хотите сделать «как вот в этом приложении», то не забудьте положить ссылки на примеры таких анимаций.

👉 Зачем это? Если разработчик не увидит вашей анимации, он просто её не реализует и ваша задумка окажется лишь задумкой.

Итого

Таким образом, финальный идеальный ZIP-архив, который отдается счастливому разработчику должен иметь примерно такую структуру:

Кроме этого в файле ReadMe.TXT или в сопроводительном письме не забудьте добавить ссылки на:

1. Кликабельный прототип, выполненный в Marvel, InVision (или в Sketch, XD, Figma, Framer, UXPin, и пр.).
2. Дизайн-макет приложения, загруженный в Zeplin, Sympli (или в другой инструмент для «просмотра макета глазами разработчика»).

Буду рад вашим комментариям 💬 и аплодисментам 👏.

1. Я на Behance: behance.net/AlexMomotov
2. Я в ВК: vk.com/momotov_sasha
3. Я в Telegram: t.me/AlexMomotov