Меня зовут Серёжа Попов. Я занимаюсь разработкой более десяти лет, руковожу фронтенд-продакшном «Лига А.» и управляю талантами в HTML Academy. Я вижу две взаимосвязанные проблемы: дизайнеры не понимают техническую сторону, а разработчики — принципы дизайна, и это мешает. Поэтому я запустил интенсив по основам разработки для дизайнеров, чтобы они могли сами собирать страницы, создавать интерактивные элементы или как минимум понимать логику программирования. Спойлер: для этого не нужно быть технарем, порог входа нулевой, а по времени можно уложиться в месяц.
Когда между двумя процессами проходит четкая граница — и дизайнеры, и разработчики решают только свои задачи, — возникает недопонимание. Например, дизайнер делает механические ошибки: сливает в один слой всю графику, которая разработчику нужна будет по отдельности, или использует режимы наложения, которые плохо функционируют в вебе.
Есть и концептуальные ошибки. Когда дизайнер проектируют то, что невозможно или трудно сделать. Это может быть сложная анимация или обилие графики, из-за которой сайт будет медленно загружаться.
Часто разработчики читают в ТЗ: «при прокрутке этот элемент вылетает справа, этот — слева». Делают, как написано, а потом начинается «здесь надо чуть быстрее, здесь — медленнее, здесь — плавнее». Чем больше неочевидного интерактива (калькуляторы, сложные слайдеры), тем выше вероятность запутаться. Например, дизайнер задумал два блока рядом — в одном ссылки, в другом картинки. И нужно, чтобы при нажатии они менялись местами. Моя реакция: «What?! Никогда бы не подумал, что так может быть».
Причина таких ситуаций — непонимание, как строится разработка, какие есть правила, ограничения, технологии. Например, на старте разработчики оценивают проект в 100–120 часов, а на этапе дизайна получают 200 часов. Пытаются судорожно уложиться в вилку и, естественно, не успевают, например, оптимизировать сайт. В итоге проект отрисован круто, а собран не очень качественно.
Дизайнер примерно представляет, как все устроено в разработке, и вот в этой примерности и кроется проблема. Например, он не до конца понимает, в чем творчество разработки, не понимает ее циклы, среднюю длительность реализации фичи. И поэтому не может адекватно и непредвзято выйти на контакт «с другой планетой», чтобы проговорить по релизам, синхронизироваться, настроить передачу макетов, проинтервьюировать разработчиков и создать для них дизайн-систему (а не только для себя или клиента).
Отсюда удлиняются сроки — рушится процесс. Это плохо и непрофессионально.
Макс Авдеев, основатель студии MAX
При этом у всех одна цель — вывести качественный продукт на рынок. Для этого важно действовать как единое целое, то есть понимать друг друга. Разработчик, например, должен участвовать и в составлении ТЗ, и в отрисовке прототипа и дизайна. Он сможет исключить нереализуемые решения, а это сэкономит время и силы. Дизайнеру лучше тоже продолжать следить за проектом. Если он выключится из продукта полностью, разработчик будет делать все на свое усмотрение.
Это все я рассказываю не к тому, что дизайнерам нужно становиться разработчиками. Нет. Но важно понимать принципы и уметь делать руками простые вещи.
На мой взгляд, чтобы продукт получился целостным и классным, всем участникам необходимо постоянно общаться и обсуждать свои решения. Так результат работы превзойдет простую сумму их экспертиз и превратится в настоящую синергию. Пользователю не важно, какую красоту в макете создал дизайнер, если на продакшене он видит менее качественный результат.
Для меня хорошая коммуникация с разработкой — одна из гигиенических основ качественного дизайна продукта. Дизайнерам важно быть открытыми к обратной связи. Моя практика показывает, что чаще всего вопросы от разработки — это просто попытка лучше понять логику и принципы, по которым дизайнеры принимают решения, а не прямая критика, какой они могут сначала показаться.
Чтобы дизайнер и разработчик могли лучше понять друг друга, им нужно уметь говорить на одном языке. Много дизайнеров на рынке уже увидели эту возможность и стали изучать программирование пару лет назад. Я тоже заметила этот тренд и в 2016 году пошла учиться в Moscow Coding School. Разработчики, кстати, тоже стали частыми гостями на курсах по основам дизайна и визуального восприятия интерфейсов. После курса мы с MCS сделали совместный проект — объясняли основы дизайна для менеджеров и разработчиков, которые хотят лучше разобраться в предмете и наладить коммуникацию с дизайнерами из своих команд.
Александра Ермоленко, дизайн-директор Mail.ru Group
Попробую развеять главные страхи, которые наблюдаю у дизайнеров при слове «код».
Страх #1. Для этого нужен технический склад ума. Все программисты с трех лет собирают микропроцессоры.
Реальность. Разработчики давно не такие сложные, как кажется. К нам в HTML Academy на фронтенд-разработчика часто приходят не технари, а люди из других сфер, и потом пачками устраиваются работать. Технический склад важен, чтобы прыгнуть выше определенного уровня, когда нужно понимать алгоритмы, но это касается специалистов, которые больше пяти лет занимаются фронтендом.
Страх #2. Нужно освоить сложный около-фронтенд инструментарий: систему контроля версий, текстовые редакторы, сборщики, автоматизация и прочее.
Реальность. Когда говорят «дизайнеру нужно учить код», речь не о том, чтобы разворачивать проекты, работать с консолью или файловой структурой или настраивать сервер. Например, в интенсиве мы используем Webflow — no-code конструктор сайтов. Он избавляет от всего фронтенд инструментария благодаря шаблонам. Дизайнер может создавать каркасы страниц, публиковать проекты одной кнопкой, подключать сторонние сервисы и не только. И, зная код, он может интегрировать его в готовые страницы, чтобы кастомизировать сайт: делать слайдеры, галереи, анимацию, аккордеон, онлайн-оплату.
Я обучаю трем языкам, на которых основана веб-разработка:
— HTML — язык разметки.
— CSS — таблицы стилей.
— JavaScript — язык программирования. Есть пласт JS, который взаимодействует с интерфейсами, и он прост для понимания.
Необязательно уходить в тонкости каждого из них. Чтобы освоить базовое взаимодействие языков, понимать их возможности и самому собирать отдельные компоненты, достаточно месяца или полутора. Например, у вас задача сделать галерею или слайдер, а в Webflow по умолчанию этого нет. Вместо того, чтобы забить или позвать разработчика, вы можете написать свой код и вставить его в платформу.
Несмотря на постепенное размытие границ экспертизы между всеми участниками команды продукта, я верю, что роли и ответственность должны быть четко распределены. Дополнительные знания в программировании или дизайне должны помогать ключевым задачам участника команды, а не отвлекать от них. Поэтому я не считаю, что хороший дизайнер продукта обязательно должен уметь программировать на профессиональном уровне.
Эксперта определяют не только его компетенции, но и то, насколько он заинтересован в том, чем занимается, и насколько готов нести ответственность за общий результат. С такой позицией необходимые знания приложатся.
Александра Ермоленко, дизайн-директор Mail.ru Group
Бенефиты могут быть разные.
- Карьерный рост. Я знаю пример, когда дизайнеры, освоив код, перешли в другую компанию на позицию лидов и выстраивали там процесс с нуля. Внутри компании тоже можно получить повышение. Руководитель видит: дизайнер понимает техническую сторону, мыслит свою работу как часть большого процесса и не предлагает нереализуемых решений. Коммуникация с разработчиками становится лучше, команда работает эффективнее и приносит компании больше денег.
- Востребованность на рынке. Дизайнер, который может собрать простые вещи или внести несложные правки в код самостоятельно, становится универсальным специалистом на такого рода задачи. Плюс для заказчика это сокращает время и стоимость.
- Создание макетов, которые разработчики смогут реализовать. Не придется тратить время на споры и обсуждения.
- Накидывание прототипов с помощью кода. В некоторых компаниях дизайнеры и разработчики вместе создают дизайн-системы и переводят их в код. Когда стоит задача собрать новый раздел или виджет, дизайнер сам может закодить прототип, который разработчики уже потом докрутят.
- Кастомизация сайтов, даже на конструкторе. Все no-code платформы неизбежно состоят из стандартных элементов и базовой стилизации. Дизайнер, который понимает, как пишется фронтенд, может запросто добавить собственной магии в шаблон, собрать с нуля компонент, которого нет в базовой библиотеке. То есть выпускать на рынок продукты, которые не выглядят как конструктор, но собираются без привлечения разработчиков.
Когда ты знаешь, что в принципе может разработка, то расширяются границы. Например, вот эту анимацию можно сделать кодом, а не рисовать в Афтере. И уже можно придумывать более сложные технические истории и выходить на новый профессиональный уровень. Развязываются руки, клиенты офигевают и думают/говорят: «Как это он придумал?!»
На встречах перед клиентами, ты становишься экспертом, начинаешь что-то рекомендовать, придумывать как удешевить MVP, как можно что-то переиспользовать (не рисовать, например, какой-нибудь фид фейсбука в проекте, а подключить решения из коробки) и так до бесконечности. В коде границ нет. А стык линейного и креативного мышления — редкая находка.
И еще! Недобросовестные разработчики не смогут обмануть дизайнера, знающего код. Вы просто скажете: «А вот используйте keyframes, че вы, вот вам ссылка на стэковерфлоу или на кодпэн, я там подкрутил, поглядите, все работает, все реально». Шах и мат! Можно пойти выпить кофе за это:)
Макс Авдеев, основатель студии MAX
Не думайте, что я пытаюсь решить проблему в одностороннем порядке. Дизайнеры, которые шарят в коде, с каждым годом все больше будут востребованы на рынке. Но и разработчики интерфейсов тоже должны учиться понимать базовые принципы дизайна, качаться в UX и так далее.
Мы вместе создаем продукты и запускаем их на рынок. Так давайте запускать, а не спорить.
Загрузка...
