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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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