Дизайнер и его роль в разработке мобильных приложений

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

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

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

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

Итак, у дизайнера, независимо от его профиля и направленности, существует множество инструментов, с помощью которых он может отрисовать то, что от него требуют. Только вот просто отрисовать экраны мобильного приложения недостаточно. Это не веб-сайт и не веб-приложение. У этой категории цифровых продуктов более строгие правила, которым нужно подчиняться. Под платформы IOS и Android созданы отдельные гайдлайны (см. раздел «Полезные ссылки»).

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

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

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

Дизайнер — часть команды

Это не просто пафосные слова. Дизайнер должен быть частью команды до сдачи приложения в магазин, постоянно общаться с коллегами, уточнять вопросы и быстро реагировать на запросы разработчиков. Минимальный срок его нахождения в команде — до первой сдачи MVP.
Как показывает практика, дизайнеры не всегда качественно сдают свои макеты, и при дальнейшей разработке всплывают какие-то недочеты, например, не отрисованные пустые экраны или какие-то состояния элементов, неверно нарезанные блоки элементов, отсутствие каких-то ресурсов. Бывает также, что клиент хочет что-то добавить.

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

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

Как уже было сказано выше, разработчику сейчас приходится столько всего изучать, что времени разбираться в графических редакторах просто нет. Поэтому дизайнер не должен отрисовывать элементы в Photoshop / Illustrator и сдавать макет в *.psd / *.ai файлах. Такие файлы довольно много весят и требуют установки пакета Adobe. Даже если это не играет особой роли, на изучение этих редакторов просто нет времени.

Разработчик хочет просто выбирать элементы и видеть, как их верстать, а не разбираться в структуре слоев одного огромного файла. Сейчас существует много графических редакторов для отрисовки мобильных приложений: Sketch, Figma и другие. В общем, есть из чего выбрать. От выбранного редактора будет зависеть то, как дизайнер представит кликабельный прототип и “живые экраны” для фронтенда.

Если дизайнер выбрал Figma, то “живые” экраны, кликабельный прототип, юзер стори, переходы экранов, семейства шрифтов и колористика, ресурсы можно скачивать самостоятельно — все находится в одном месте. Изменения дизайна видны сразу. Как и у многих сервисов, у Figma есть свои минусы. Но это довольно удачный выбор, хотя бы потому, что данный редактор не требует установки специального ПО. Нужен просто переход по ссылке на проект. Главное, чтобы был интернет.

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

Дизайнер должен знать гайдлайны под разные платформы и их отличия

Довольно часто дизайнеры рисуют проекты, не разбираясь в гайдлайнах, смешивают стили или создают нестандартные элементы, думая о красоте экрана. Таких примеров довольно много на Dribbble и Behance. Клиенты, не зная об этих нюансах, одобряют макеты. Когда дело доходит до разработки, дело стопорится. Дизайнер не хочет переделывать неправильно выполненную работу. Заказчик требует именно такой экран или эффект, который он одобрил, но его невозможно сделать.



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

Ресурсы

Это самый больной вопрос при взаимодействии с дизайнером. Обычно дизайнеры не нарезают ресурсы. В большинстве своем они считают, что: не обязаны это делать; это долго и монотонно, и если разработчику надо, он сам все нарежет или можно сбросить *.svg; не знают, что именно нужно нарезать и в каких размерах.

Тем не менее, если взглянуть со стороны разработчика, решение этого вопроса очень сильно сокращает время работы. Ему достаточно взглянуть на название ресурса на прототипе и найти в папке ресурсов такое же — и все, он продолжает верстку. А если представить, что разработчику нужно самому нарезать ресурсы? Он должен полностью выделить нужный элемент на экране, найти экспорт, указать размеры и путь.

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

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

ТЗ с описанием работы экранов

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

Как говорилось выше, члены проектных команд часто меняются. Никто не хочет возиться с новичками. Возможно, коллеги сделают краткий обзор, скинут ссылки на все выданные дизайнером ресурсы — и все. От разработчика ждут, что он начнет работать с полным понимаем, как функционирует приложение. Чаще всего ТЗ, разъясняющего это, нет, поскольку дизайнер не знал о том, что оно требуется, или не захотел его делать. И что же выходит? Работа стопорится. Новый член команды не понимает, что и как функционирует, работает в полсилы, тратя при этом время команды.

Что делать, если ничего из вышеперечисленного нет, а работать нужно?

Так получилось, что все вышеперечисленные требования стали обязательными в одном из моих проектов.

Проект был связан с арендой недвижимости и разрабатывался под две платформы: IOS и Android. Процесс разработки начинался как любой другой. Позже оказалось, что дизайнер не полностью разбирался в мобильных приложениях. Что такое гайды он не знал. На дизайне присутствовали прозрачные элементы, шрифты использовались только под одну платформу. Колористику можно было описать как использование “50 оттенков серого”.

Мне дали *.psd файл. Вроде бы ничего плохого. Такие файлы сдают многие дизайнеры. Но мне пришлось установить пакет Adobe, чтобы взглянуть на макет. Файл был очень “тяжелым” и открывался минут 10. Не все экраны были отрисованы отдельно на рабочей области. Они находились один поверх другого как слои, и чтобы посмотреть один экран, нужно было отключить все остальные. Так как у меня не было значительного опыта работы с пакетом, я подумал об Avocode как об инструменте для обработки дизайн-материала. Конечно, эта программа не идеальна, но она меня буквально спасла.

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

Выводы:

Что я ожидал получить от дизайнера:

• кликабельный прототип и живые экраны (InVision, Zeplin или Figma)
• переработанное ТЗ с описанием работы экранов
• карту экранов с переходами
• пользовательскую историю
• нарезанные ресурсы в размерах @1, @2, @3
• шрифты

Из всего перечисленного я получил только кликабельный прототип и *psd файл.

Проект доведен до конца и выложен в магазин. Но чтобы добиться этого результата, моя команда прошла семь кругов Ада или, как говорится, столкнулась с определенными трудностями.



Многие не согласятся и скажут, что предоставленных материалов достаточно. Но мы говорим о профессионализме и о том, как ситуация выглядит со стороны разработчиков. В конце концов, дизайнер мобильного приложения — это не просто художник. Это член команды, работающей над сложным проектом. Свою работу он должен делать хорошо, ведь для него это еще не конец работы над проектом, а для команды — только начало.

Всем спасибо за внимание и успешных проектов!

Полезные ссылки:

IOS guidelines
Android guidelines
Problems of development the legacy mobile project
Figma
Sketch