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

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

![Image](img_1.png "рис.1")

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

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

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

### Поиск баланса между бизнес-потребностями и техническими возможностями

Дизайнеру часто приходится искать золотую середину между идеями и реализацией. Вы можете придумать крутые фичи (от англ. features — новые функции продукта), обсудить их с руководителем проекта, согласовать и подготовить дизайн… А потом прийти к разработчикам с макетами и узнать, что это технически невозможно воплотить в жизнь. Или возможно, но неоправданно дорого/сложно/долго.

![Image](img2.png "рис.2")

### Взаимодействие с разработчиками

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

Чаще всего мы общаемся с фронт-разработчиками (от англ. front-end developers — те, кто пишет код для интерфейса продукта и превращает строчки команд во что-то более визуально понятное и приятное). Перед тем как передавать макеты на утверждение, важно «синхронизироваться» с разработчиками и убедиться, что вся нарисованная вами красота реальна для исполнения.

Иногда приходится обращаться и бэк-разработчикам (от англ back-end developers — специалисты, отвечающие за то, чтобы сайт быстро работал, безопасно хранил данные и т.д.). Например, когда нужно настроить проверку данных при загрузке файлов.

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

### Единообразие интерфейсов

UI Kit (от англ. User Interface Kit — набор готовых элементов интерфейса: кнопки, иконки, поля и т.д.). А еще есть компонентная база — система, где хранятся стандартные элементы интерфейса. Они помогают упростить управление макетами.

Дизайнер должен следить за тем чтобы схожие «сущности» (то есть, элементы интерфейса) не плодились и не создавалось слишком похожих изображений. В противном случае в коде проекта появятся практически копии разных (по задумке) деталей, а это — лишняя трата ресурса разработки.

![Image](img3.png "рис.3")

### Объяснение причин для изменений

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

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

### Организация передачи макетов в разработку

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

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

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

![Image](img4.png "рис.4")

### Полезные советы

* Систематизируйте юзер флоу. Для справки: от англ user flow — это путь, который проходит пользователь при взаимодействии с продуктом. Его лучше максимально привести в порядок, используя стрелки и состояния элементов. Так вы упростите жизнь команде и, как ни странно, себе. Ведь если через полгода вдруг придется вернуться к конкретному сценарию, вся информация останется в макете.
* Ищите компромиссы. Дизайнеру нужно быть гибким, так как иногда его предложения бывают слишком сложными в реализации. Может, в какой-то другой сфере и прокатит «Я художник, я так вижу», но только не в IT. Здесь многое завязано на технических возможностях, поэтому решение должно быть простым в исполнении и не вредить работе продукта.
* Делитесь идеями. Все-таки одна из главных задач дизайнера — создавать и придумывать. Творить, если хотите. Не бойтесь выносить свои идеи на обсуждение с командой. Да, не все из них будут реализованы: на что-то не хватит ресурса, что-то может противоречить бизнес-логике. Но если ваши решения улучшают проект, это не останется незамеченным.
* Учитывайте технические детали. Как я уже упоминала, дизайнер должен плотно взаимодействовать с разработчиками. Например, стоит заранее уточнить особенности работы с фреймворками (от англ. frameworks —программные платформы для разработки). Если вы создали цветную картинку в Иллюстраторе и выгрузили ее в формате SVG, то в Flutter (фреймворк для разработки мобильных приложений) она отобразится как черный квадрат Малевича.