Существуют невидимые чернила, — прошептала она и, трижды коснувшись палочкой дневника, произнесла: — Апарекиум!
Мы дизайнеры и мы волшебники. Что-то для нас кажется обычным и привычным, но, к сожалению, мы работаем с простыми магглами. Всю нашу работу мы должны делать максимально прозрачно, чтобы нашим коллегам не пришлось использовать заклинание Апарекиум в поисках того, что мы написали невидимыми чернилами.
1. Много разных диагоналей, что делать
Если вы веб-дизайнер, но никогда не работали с мобильными приложениями, то скорее всего у вас возникнет вопрос про большое количество экранов мобильных устройств. А еще у них разные пропорции и на разных платформах разные стандарты экранов. О ужас! — скажете вы. Но все достаточно просто. Существуют основные разрешения девайсов под которые нужно рисовать дизайн. На iOS это 375×667, а на Android 360×640. Это основные пропорции, которые используются практически на всех девайсах. В большинстве случаев остальные смартфоны увеличиваются в высоту, а это не доставляет особых проблем, просто у вас будет видно чуть больше контента. В некоторых случаях стоит учитывать смартфоны с меньшим разрешением или другими пропорциями, например iPhone 4. Для него может потребоваться отрисовать отдельные версии экранов, если контент не помещается на экран.
2. Негативные кейсы
Достаточно часто на макетах присутствуют различные формы ввода данных и последующее получение результата по ним. Эти формы имеют различные состояния, дизайнеры рисуют основное состояние, состояние положительного результата и возможно подсказки. Но ведь вариантов негативных состояний у формы тоже достаточно большое количество. И об этом зачастую забывают.
Во время верстки макетов у разработчика возникают вопросы по состояниям формы и он видит, что у него есть 3 негативных ответа от сервера, а отрисовано только одно. Дизайн возвращается на доработку, тратится время, менеджер нервничает, сроки факапятся.
Во избежании таких ситуаций уточняйте у разработчика, а лучше у аналитика, какие состояния могут быть в той или иной форме и будет у вас счастье.
3. Активная клавиатура
В дизайне мобильных приложений немаловажно отображать все возможные состояния, т.к. размер экрана достаточно компактный, а элементы могут быть зависимы друг от друга, поэтому при движении одного элемента двигаются и другие, а не всегда это происходит корректно.
Одно из важных состояний является отображение активной и неактивной клавиатуры при вводе информации в текстовые поля. Нужно обязательно показывать состояние поля без фокуса, с фокусом и клавиатурой, введенным текстом и клавиатурой, ошибками и т.д. Клавиатура может двигать некоторые элементы при активации, а другие перекрывать. Повторюсь, что на смартфонах компактные экраны и блоки могут просто поехать при активации клавиатуры, за этим нужно внимательно следить.
4. Карта экранов
При создании приложения зачастую возникает достаточно большое количество экранов, в которых к середине проекта уже сложно разобраться. Для этого нужно создавать карту экранов приложения или карту навигации.
Карта навигации составляется как на все приложение, так и на отдельные блоки, которые потом будут встраиваться в приложение. Карту можно составить и на этапе проектирования/прототипирования приложения, когда уже будет понятна основная логика работы приложения. Но по своему опыту для выстраивания логики приложения и составляется карта переходов. Она позволяет выявить недостающие экраны, о которых вы могли забыть.
Карту переходов можно составлять в таких программах: Realtimeboard, Axure, Figma, Sketch. Но для меня самым удобным вариантом оказался Overflow.
5. Текст в контейнере
Практически на всех макетах присутствует текст. При добавлении текста на макет его можно добавить несколькими способами. Просто нажать инструментом текст и начать писать или сделать текстовый контейнер ограниченный по ширине и высоте. Первый способ можно оставить для заголовков, а вот второй использовать для большого количества текста. Текст помещенный в контейнер поможет разработчику сориентироваться в ваших макетах гораздо проще, т.к. отступы будут везде приблизительно одинаковые. В большинстве случаев при создании макетов у дизайнера нет конечного варианта текста и в макеты вставляется «рыба». Если вы делаете интерфейс, который будет в большинстве случаев использоваться только на русском, то ставьте текст на русском, т.к. есть большая разница в отображении шрифта на разных языках.
6. Нет указания типа навигации
Для разработчиков очень важно описание типа навигации в мобильном приложении, т.к. есть несколько типов переходов с одного экрана на другой. При создании дизайна приложения наилучшим образом показать типы навигации будет создание кликабельного прототипа. На данный момент почти все сервисы для создания кликабельных прототипов поддерживают основные типы переходов между экранами. Для разработчиков этого будет достаточно.
Еще можно показывать типы навигации элементами управления на экране. Например, крестик показывает, что это модальное окно, а стрелка назад, что скорее всего переход будет осуществляться путем пуша.
7. Удобный экспорт
Вы нарисовали макет, утвердили его у заказчика, выложили все макеты для верстки и вроде выдохнули. Но вот откуда ни возьмись прибегает разработчик и говорит вам о том, что иконка выгружается коряво. о_О
И тут вы понимаете, что забыли сгруппировать и/или объединить иконки. Поэтому всегда при завершении работы по дизайну проверяйте все элементы, которые могут понадобиться разработчику. Самый оптимальный вариант, это когда все элементы, которые разработчик не может сделать кодом размещать на отдельном артборде. Иконки и элементы должны быть сгруппированы для удобства экспорта, иначе все будет коряво выгружено и также заверстано.
8. Не всегда то, что нарисовано легко реализуемо
Дизайнеры творческие натуры и могут иногда нарисовать такое, что разработчик потом либо не сможет это реализовать, либо для этого понадобится очень много времени. Время сотрудников агентства обычно оплачивает заказчик, а для заказчика зачастую важны бизнес показатели и конечный результат точно в срок.
Поэтому во время отрисовки макетов, а лучше на этапе проектирования и аналитики уточняйте у разработчиков о доступности данных, и о возможности реализации вашей идеи. Иногда достаточно описать идею словами или нарисовать на листочке, чтобы объяснить разработчику вашу задумку. Возможно, что вы получите ответ на интересующий вас вопрос прямо здесь и сейчас, а, возможно, что разработчику понадобится время на ресерч информации. Но чем раньше вы узнаете о том, что можно реализовать на проекте, а что нет, принесет вам плоды в дальнейшем.
9. 50 оттенков серого
Если у вас большой макет сайта или приложения и цвет используется 2-3 раза на разных элементах, то уверенно создавайте стиль. Стили ускорят не только вашу работу и не дадут применить к элементу похожий, но не идентичный цвет. Но и разработчику будет потом намного проще, т.к. стили можно выгрузить в Zeplin. Главное не забывать о том, что при индивидуальном изменении элемента с привязанным стилем есть возможность того, что вы случайно можете изменить стиль. Лучше заранее отвязать от стиля элемент и редактировать его под свои нужды.
10. Кратности в макетах
Говорить на тему сеток можно бесконечно. Но в данном контексте хочется рассказать о личном опыте построения интерфейса. Недавно читал пост в facebook и там разгорелась очень интересная дискуссия. Кто-то настаивал на том, что все интерфейсы должны быть построены по определенному формату, т.е. никакой индивидуальности. И тут же спрашивают о том, что делать если экран имеет нечетные параметры? Например iPhone 8 имеет разрешение 375×667, что же делать в таком случае? Если отталкиваться от построения на четных количествах столбцов, то здесь едет вся логика. Google же предлагает использовать сетку основанную на 8 единицах.
Занимаясь мобильными приложениями, я пришел к выводу, что нужно брать определенный минимальный параметр за единицу. Учитывая гайдлайны или нарушая их, вы можете строить интерфейсы на любое разрешение при помощи минимальной единицы измерения. Не всегда это может быть четное число, знаю, что многие с этим не согласятся, но на то дизайнер творческая натура, чтобы придумывать что-то новое :)
Если сделать качественное описание макетов и пояснить в нем, что у вас минимальная единица для отступов 4, то разработчику станет гораздо легче, поверьте.
11. Нестандартный кернинг
Что же такое кернинг? Говоря простыми словами, это интервал между буквами. В зависимости от кернинга меняется внешний вид слов. При помощи кернинга можно улучшить или ухудшить восприятие текста.
Нестандартный кернинг не сразу заметен для разработчика. Макет верстается и вроде все хорошо, но выглядит он не как задумано дизайнером. В результате приходится вносить правки, а это дополнительное время.
Есть очень интересная игра, в которой вы можете потренироваться: https://type.method.ac
12. Своевременная актуализация
Зачастую один дизайнер делает макеты на две или более платформ. Когда разработка дизайна длится долгое время над одним продуктом, то количество макетов может быть бесконечно огромным. Следить за этим становится проблематично.
И вот приходит новая задача от менеджера сделать новую фичу в приложении. Соответственно, при создании дизайна существует ведущая платформа, на которую делается дизайн и утверждается с заказчиком. Выбор платформы может быть обусловлен требованиями заказчика, т.к. количество пользователей на одной платформе больше, чем на другой. Или дизайнер сам может выбрать платформу, которая ему по душе.
И вот макеты готовы, все утвердили, а менеджер забыл поставить задачу на перенос дизайна на другую платформу. Все об этом забыли. Наступает пора имплементировать дизайн в приложение и разработчики начинают смотреть ваш дизайн. У Андроид разработчиков он есть, а у iOS — нет, вот незадача. А с момента отрисовки макетов до реализации может пройти значительное время, все уже и забыли, что там нарисовано. Приходится искать задачу, перечитывать бизнес требование и вспоминать, что же там было тогда сделано.
Из этого всего следует то, что нужно стараться помнить о том, что дизайн должен быть отрисован под несколько платформ. Завести такое правило в компании или у себя в голове. Даже если менеджер не поставил задачу, а в компании действует правило: «если нет задачи в таск трекере, то и нет ее результата», то можно перенести дизайн на другие платформы и спокойно ждать пока разработчику он понадобится. И еще вдобавок можно тонко намекнуть, кто не поставил задачу :)
13. Тени картинками
В интерфейсах часто используются тени у объектов. Они могут быть различных размеров и форм. В большинстве случаев тень отбрасывается от объекта для того, чтобы показать положение объекта в пространстве. Тень позволяет ставить приоритеты над объектами. Но не стоит забывать, что тень является вспомогательным элементом и использовать ее нужно очень аккуратно.
При разработке приложений тень можно задать при помощи кода, а можно сделать изображением. Тень в виде изображения ускоряет разработку, т.к. разработчику не нужно выдумывать от какого объекта отбросить тень и по каким параметрам ее делать. Также тень, которую вы отдадите в виде изображения точно будет соответствовать задуманным параметрам.
Хотелось донести до вас, что упрощая работу себе, вы упрощаете ее и другим. Старайтесь делать все максимально четко и понятно. Объясняйте магглам простые дизайнерские истины, ведь они не волшебники.
Вкусного вам дизайна!