Создавай дизайн в Sketch, как если бы ты программировал интерфейс в среде разработки

Для начала уточню, это единственный раз, когда я в посте упомяну Photoshop. 2017-й год на дворе, сделайте себе одолжение и скачайте Sketch (или Figma - не суть, главное, что это не Photoshop). Дизайн интерфейсов прошел долгий путь, как и графические редакторы (сейчас их уже так и не назовешь). Мы помним, как создавали первые пользовательские интерфейсы в GIMP, а теперь у нас есть MacBook-и и Sketch. Sketch создавался для дизайнеров. Он был разработан с целью помочь дизайнерам создавать пользовательские интерфейсы. И вы можете создавать в нем потрясающие проекты. Но не забывайте, что когда вы создаете продукт, ваши обязанности кончаются на моменте, когда ваш дизайн сверстан, а не когда вы “финализируете” свой Sketch-файл с графикой. Ваш дизайн должен пройти через программиста, чтобы его встроили в среду разработки. Вот где лежит проблема; если вы посмотрите на Sketch и UI-билдер в среде разработки (или IDE, такие как Xcode и Android Studio), вы вряд ли увидите хоть какое-то сходство. То, как разработчик интегрирует ваш дизайн, фундаментально отличается от того, как вы, как дизайнер, создаете его в Sketch. Сравнивание этих двух подходов выглядит как-то глупо, правда? Xcode, Sketch и Android Studio (и немного искр молний) Это нормально! Данная статья описывает подход к созданию дизайна, который приближен к тому, через что проходит программист при верстке вашего дизайна (все эти страдания…).

Думайте “представлениями”

Знаете опцию Символы в Sketch, да? Мы были в восторге от нее, когда только перешли на Sketch, потому что она очень напоминает программистский подход построения UI. В большинстве случаев, когда есть повторяющиеся элементы вроде пунктов списка или строк меню, все они имеют одно исходное представление, которое отображается снова и снова. Самое важное правило дизайна в стиле разработчика - продумывать дизайн представлениями. Представление (View) - это независимая группа элементов, у которой заданы границы и которая упорядочена в иерархическом порядке. В качестве примера, экран Search Results (Результаты поиска) нашего приложения Nimber на Android разделен на два главных представления; Top View, который содержит строку меню, а также карточку с введенными пользователем локациями и фильтрами, а также List View с результатами поиска. В Blueprint и Skeleton выше, вы можете видеть, как границы представления четко заданы в дизайне. Это слои, которые невидимы в файле Sketch (непрозрачность 0%), но они очень полезны при передаче дизайна разработчикам. Ниже посмотрите, как меню (Action Bar) делится на более мелкие представления. Верхний уровень иерархии представлений Представление ActionBar Элементы меню с границами представления при 100% непрозрачности Постарайтесь группировать свои слои правильно. Четко задайте их размеры и отступы (избегайте нечетных чисел) и сортируйте все в иерархическом порядке. То же касается и стилей слоя для случаев, когда нужно использовать одни и те же параметры контуров, закругленных углов, теней и т.д. Приложение под названием Zeplin здесь очень поможет. Вкратце: вы импортируете сюда свой дизайн, приложение извлекает все размеры представлений, размеры текста, цвета и т.д. способом, ориентированным на программистов. Это отличный инструмент, который как раз заполняет пробел между дизайнерами и разработчиками. При передаче дизайна разработчик может смотреть в Zeplin и извлекать размеры, границы, отступы и создавать их IDE в соответствии с этими параметрами.

Рисуйте в 1x

Создавая дизайн в 1х, вы помогаете себе - не нужно вычислять размеры для разных плотностей экранов, а также вы и ваш программист будут пользоваться одинаковыми числами. Так вы избегаете любых расчетных ошибок, придерживаясь постоянного набора значений. Это применимо к размерам представлений, текста, высотам линий, практически всем числам... http://ux.pub/dizajn-v-1x-idealnyj-rabochij-process-v-sketch-dlya-dizajnera/

Постоянная палитра цветов

Создайте один раз и пользуйтесь на протяжении всего проекта. Постарайтесь свести количество цветов к возможному минимуму. Вы заметите, что по большей части программисты используют названия Primary, Secondary, Accent, Enabled, Disabled (Главный, Вспомогательный, Акцент, Активный, Отключенный) и т.д.. Вы можете сделать то же самое. Цветами текста будут Главный и Вспомогательный, Акцент - будет ваш цвет бренда, ну вы поняли суть. В Sketch вы можете сохранить эти цвета в селекторе цветов, но насколько я знаю, нет способа поделиться ими вне файла Sketch. Вместо этого можете создать артборд с цветами своей палитры, их названиями и hex-кодами. Так разработчики смогут быстро извлечь их через Zeplin и вставить в код приложения. Это цвета, которые мы используем в приложениях Nimber

Дизайн на все случаи

Помните, что программисты создают интерфейс не только для идеального сценария. Им также нужно позаботиться о случаях, когда нет подключения к сети, или произошла серверная ошибка, или когда нет контента для отображения и т.д. Поэтому разработайте дизайн под каждый такой сценарий. В частности, сделайте дизайн любой страницы под пустое состояние, состояние загрузки, ошибки и идеальное состояние (когда все хорошо). Для 99% случаев этого будет достаточно. В этой статье Скотта Херфа более глубоко описаны состояния, рекомендую к прочтению.

Размеры экрана

Мы живем в эру многообразия размеров экрана, так что соответственно нужно создавать дизайн под разные разрешения. Это непростая задача для дизайна под Android, потому что есть масса устройств с самыми разными размерами экранов. Проще всего решить эту проблему с помощью плагина вроде Sketch Constraints во время дизайна в Sketch. Когда вы используете что-то подобное, вы можете дублировать артборды, изменять их размеры и обновлять содержимое. Волшебным образом интерфейс будет адаптироваться в зависимости от размера экрана. Правильно же будет создать версии дизайна UI под разные размеры телефона (до 7 дюймов), 7-дюймовых планшетов и 10-дюймовых планшетов. Это особенно полезно при использовании шаблона Master-Detail Flow (комбинирование панелей списка и деталей в один макет), как в примере ниже. Хотите знать, что это? Вам повезло!

Что нужно помнить

1. Не все ваши пользователи будут пользоваться англоязычной версией приложения. Помните, что текст может быть длиннее (или короче) в других языковых версиях, и вам нужно учитывать это при дизайне своих макетов.
2. У вас нет контроля над каждым пикселем. Некоторые части приложения неизбежно примут неидеальный вид из-за непредсказуемого объема подгружаемых данных.
3. Пытайтесь использовать взаимодействия, жесты, переходы и анимации, встроенные в платформу. Программисты будут очень вам благодарны.

Последнее, но не менее важное

Общайтесь со своими программистами! Пусть они вас учат. Инструменты вроде Zeplin и Flinto хороши для передачи дизайнов программистам, но в них нет возможности пояснить поведение каждой части приложения. Обменивайтесь знаниями и старайтесь достичь лучшего для продукта результата. Надеемся, в этом посте вы нашли для себя что-то полезное, и примените это в своей работе.

---

Перевод статьи Chris Basha