Для начала уточню, это единственный раз, когда я в посте упомяну Photoshop. 2017-й год на дворе, сделайте себе одолжение и скачайте Sketch (или Figma — не суть, главное, что это не Photoshop).
Дизайн интерфейсов прошел долгий путь, как и графические редакторы (сейчас их уже так и не назовешь). Мы помним, как создавали первые пользовательские интерфейсы в GIMP, а теперь у нас есть MacBook-и и Sketch.
Sketch создавался для дизайнеров. Он был разработан с целью помочь дизайнерам создавать пользовательские интерфейсы. И вы можете создавать в нем потрясающие проекты. Но не забывайте, что когда вы создаете продукт, ваши обязанности кончаются на моменте, когда ваш дизайн сверстан, а не когда вы «финализируете» свой Sketch-файл с графикой.
Ваш дизайн должен пройти через программиста, чтобы его встроили в среду разработки. Вот где лежит проблема; если вы посмотрите на Sketch и UI-билдер в среде разработки (или IDE, такие как Xcode и Android Studio), вы вряд ли увидите хоть какое-то сходство.
То, как разработчик интегрирует ваш дизайн, фундаментально отличается от того, как вы, как дизайнер, создаете его в Sketch. Сравнивание этих двух подходов выглядит как-то глупо, правда?
Это нормально! Данная статья описывает подход к созданию дизайна, который приближен к тому, через что проходит программист при верстке вашего дизайна (все эти страдания…).
Думайте «представлениями»
Знаете опцию Символы в Sketch, да? Мы были в восторге от нее, когда только перешли на Sketch, потому что она очень напоминает программистский подход построения UI. В большинстве случаев, когда есть повторяющиеся элементы вроде пунктов списка или строк меню, все они имеют одно исходное представление, которое отображается снова и снова.
Самое важное правило дизайна в стиле разработчика — продумывать дизайн представлениями. Представление (View) — это независимая группа элементов, у которой заданы границы и которая упорядочена в иерархическом порядке.
В качестве примера, экран Search Results (Результаты поиска) нашего приложения Nimber на Android разделен на два главных представления; Top View, который содержит строку меню, а также карточку с введенными пользователем локациями и фильтрами, а также List View с результатами поиска.
В Blueprint и Skeleton выше, вы можете видеть, как границы представления четко заданы в дизайне. Это слои, которые невидимы в файле Sketch (непрозрачность 0%), но они очень полезны при передаче дизайна разработчикам.
Ниже посмотрите, как меню (Action Bar) делится на более мелкие представления.
Постарайтесь группировать свои слои правильно. Четко задайте их размеры и отступы (избегайте нечетных чисел) и сортируйте все в иерархическом порядке.
То же касается и стилей слоя для случаев, когда нужно использовать одни и те же параметры контуров, закругленных углов, теней
Приложение под названием Zeplin здесь очень поможет. Вкратце: вы импортируете сюда свой дизайн, приложение извлекает все размеры представлений, размеры текста, цвета
При передаче дизайна разработчик может смотреть в Zeplin и извлекать размеры, границы, отступы и создавать их IDE в соответствии с этими параметрами.
Рисуйте в 1x
Создавая дизайн в 1х, вы помогаете себе — не нужно вычислять размеры для разных плотностей экранов, а также вы и ваш программист будут пользоваться одинаковыми числами. Так вы избегаете любых расчетных ошибок, придерживаясь постоянного набора значений.
Это применимо к размерам представлений, текста, высотам линий, практически всем числам…
Дизайн в 1x: идеальный рабочий процесс в sketch для дизайнера
Постоянная палитра цветов
Создайте один раз и пользуйтесь на протяжении всего проекта. Постарайтесь свести количество цветов к возможному минимуму.
Вы заметите, что по большей части программисты используют названия Primary, Secondary, Accent, Enabled, Disabled (Главный, Вспомогательный, Акцент, Активный, Отключенный)
В Sketch вы можете сохранить эти цвета в селекторе цветов, но насколько я знаю, нет способа поделиться ими вне файла Sketch. Вместо этого можете создать артборд с цветами своей палитры, их названиями и hex-кодами. Так разработчики смогут быстро извлечь их через Zeplin и вставить в код приложения.
Дизайн на все случаи
Помните, что программисты создают интерфейс не только для идеального сценария. Им также нужно позаботиться о случаях, когда нет подключения к сети, или произошла серверная ошибка, или когда нет контента для отображения
Поэтому разработайте дизайн под каждый такой сценарий. В частности, сделайте дизайн любой страницы под пустое состояние, состояние загрузки, ошибки и идеальное состояние (когда все хорошо). Для 99% случаев этого будет достаточно. В этой статье Скотта Херфа более глубоко описаны состояния, рекомендую к прочтению.
Размеры экрана
Мы живем в эру многообразия размеров экрана, так что соответственно нужно создавать дизайн под разные разрешения. Это непростая задача для дизайна под Android, потому что есть масса устройств с самыми разными размерами экранов.
Проще всего решить эту проблему с помощью плагина вроде Sketch Constraints во время дизайна в Sketch. Когда вы используете что-то подобное, вы можете дублировать артборды, изменять их размеры и обновлять содержимое. Волшебным образом интерфейс будет адаптироваться в зависимости от размера экрана.
Правильно же будет создать версии дизайна UI под разные размеры телефона (до 7 дюймов), 7-дюймовых планшетов и 10-дюймовых планшетов. Это особенно полезно при использовании шаблона Master-Detail Flow (комбинирование панелей списка и деталей в один макет), как в примере ниже.
Хотите знать, что это? Вам повезло!
Что нужно помнить
- Не все ваши пользователи будут пользоваться англоязычной версией приложения. Помните, что текст может быть длиннее (или короче) в других языковых версиях, и вам нужно учитывать это при дизайне своих макетов.
- У вас нет контроля над каждым пикселем. Некоторые части приложения неизбежно примут неидеальный вид из-за непредсказуемого объема подгружаемых данных.
- Пытайтесь использовать взаимодействия, жесты, переходы и анимации, встроенные в платформу. Программисты будут очень вам благодарны.
Последнее, но не менее важное
Общайтесь со своими программистами! Пусть они вас учат. Инструменты вроде Zeplin и Flinto хороши для передачи дизайнов программистам, но в них нет возможности пояснить поведение каждой части приложения. Обменивайтесь знаниями и старайтесь достичь лучшего для продукта результата.
Надеемся, в этом посте вы нашли для себя что-то полезное, и примените это в своей работе.
Нет комментариев