Что делает дизайнер в команде разработки?

Статья для тех, кто думал, что дизайн — это просто рисовать картинки за деньги :)

Всем привет! Меня зовут Анна, и я уже 9 лет лет работаю дизайнером, 2 из которых в сфере IT. За это время у меня накопилось немало опыта, интересных историй и полезных лайфхаков, которыми я буду делиться в своем блоге.

Что делает дизайнер в команде разработки?

Дизайнер — это не просто человек, который «рисует картинки». В IT-сфере этот специалист выступает мостиком между пользователями и разработчиками. Именно мы создаем решения и концепции, которые помогают закрыть потребности потребителя, сделать продукт простым и удобным, а также легким для реализации.

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

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

Кстати, о них.

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

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

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

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

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

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

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

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

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

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

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

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

Как-то так в общих чертах и выглядит работа дизайнера в команде разработки. Надеюсь, было интересно.

Подписывайтесь, ставьте лайки, задавайте вопросы в комментариях!