Реально ли дизайнеру «заговорить» на языке разработки, а главное — зачем?
Меня зовут Серёжа Попов. Я занимаюсь разработкой более десяти лет, руковожу фронтенд-продакшном «Лига А.» и управляю талантами в HTML Academy. Я вижу две взаимосвязанные проблемы: дизайнеры не понимают техническую сторону, а разработчики — принципы дизайна, и это мешает.
Поэтому я запустил интенсив по основам разработки для дизайнеров, чтобы они могли сами собирать страницы, создавать интерактивные элементы или как минимум понимать логику программирования. Спойлер: для этого не нужно быть технарем, порог входа нулевой, а по времени можно уложиться в месяц.
Дизайнер и разработчик — инь и янь
Когда между двумя процессами проходит четкая граница — и дизайнеры, и разработчики решают только свои задачи, — возникает недопонимание. Например, дизайнер делает механические ошибки: сливает в один слой всю графику, которая разработчику нужна будет по отдельности, или использует режимы наложения, которые плохо функционируют в вебе.
Есть и концептуальные ошибки. Когда дизайнер проектируют то, что невозможно или трудно сделать. Это может быть сложная анимация или обилие графики, из-за которой сайт будет медленно загружаться.
Часто разработчики читают в ТЗ: «при прокрутке этот элемент вылетает справа, этот — слева». Делают, как написано, а потом начинается «здесь надо чуть быстрее, здесь — медленнее, здесь — плавнее». Чем больше неочевидного интерактива (калькуляторы, сложные слайдеры), тем выше вероятность запутаться. Например, дизайнер задумал два блока рядом — в одном ссылки, в другом картинки. И нужно, чтобы при нажатии они менялись местами. Моя реакция: «What?! Никогда бы не подумал, что так может быть».
Причина таких ситуаций — непонимание, как строится разработка, какие есть правила, ограничения, технологии. Например, на старте разработчики оценивают проект в 100-120 часов, а на этапе дизайна получают 200 часов. Пытаются судорожно уложиться в вилку и, естественно, не успевают, например, оптимизировать сайт. В итоге проект отрисован круто, а собран не очень качественно.
При этом у всех одна цель — вывести качественный продукт на рынок. Для этого важно действовать как единое целое, то есть понимать друг друга. Разработчик, например, должен участвовать и в составлении ТЗ, и в отрисовке прототипа и дизайна. Он сможет исключить нереализуемые решения, а это сэкономит время и силы. Дизайнеру лучше тоже продолжать следить за проектом. Если он выключится из продукта полностью, разработчик будет делать все на свое усмотрение.
Это все я рассказываю не к тому, что дизайнерам нужно становиться разработчиками. Нет. Но важно понимать принципы и уметь делать руками простые вещи.
Научиться коду можно
Попробую развеять главные страхи, которые наблюдаю у дизайнеров при слове «код».
Страх #1. Для этого нужен технический склад ума. Все программисты с трех лет собирают микропроцессоры.
Реальность. Разработчики давно не такие сложные, как кажется. К нам в HTML Academy на фронтенд-разработчика часто приходят не технари, а люди из других сфер, и потом пачками устраиваются работать. Технический склад важен, чтобы прыгнуть выше определенного уровня, когда нужно понимать алгоритмы, но это касается специалистов, которые больше пяти лет занимаются фронтендом.
Страх #2. Нужно освоить сложный около-фронтенд инструментарий: систему контроля версий, текстовые редакторы, сборщики, автоматизация и прочее.
Реальность. Когда говорят «дизайнеру нужно учить код», речь не о том, чтобы разворачивать проекты, работать с консолью или файловой структурой или настраивать сервер. Например, в интенсиве мы используем Webflow — no-code конструктор сайтов. Он избавляет от всего фронтенд инструментария благодаря шаблонам. Дизайнер может создавать каркасы страниц, публиковать проекты одной кнопкой, подключать сторонние сервисы и не только. И, зная код, он может интегрировать его в готовые страницы, чтобы кастомизировать сайт: делать слайдеры, галереи, анимацию, аккордеон, онлайн-оплату.
Я обучаю трем языкам, на которых основана веб-разработка:
- HTML — язык разметки.
CSS — таблицы стилей.
JavaScript — язык программирования. Есть пласт JS, который взаимодействует с интерфейсами, и он прост для понимания.
Необязательно уходить в тонкости каждого из них. Чтобы освоить базовое взаимодействие языков, понимать их возможности и самому собирать отдельные компоненты, достаточно месяца или полутора. Например, у вас задача сделать галерею или слайдер, а в Webflow по умолчанию этого нет. Вместо того, чтобы забить или позвать разработчика, вы можете написать свой код и вставить его в платформу.
Хорошо, вы научитесь кодить. А зачем?
Бенефиты могут быть разные.
- Карьерный рост. Я знаю пример, когда дизайнеры, освоив код, перешли в другую компанию на позицию лидов и выстраивали там процесс с нуля. Внутри компании тоже можно получить повышение. Руководитель видит: дизайнер понимает техническую сторону, мыслит свою работу как часть большого процесса и не предлагает нереализуемых решений. Коммуникация с разработчиками становится лучше, команда работает более эффективно и приносит компании больше денег.
Востребованность на рынке. Дизайнер, который может собрать простые вещи или внести несложные правки в код самостоятельно, становится универсальным специалистом на такого рода задачи. Плюс для заказчика это сокращает время и стоимость.
Создание макетов, которые разработчики смогут реализовать. Не придется тратить время на споры и обсуждения.
Накидывание прототипов с помощью кода. В некоторых компаниях дизайнеры и разработчики вместе создают дизайн-системы и переводят их в код. Когда стоит задача собрать новый раздел или виджет, дизайнер сам может закодить прототип, который разработчики уже потом докрутят.
Кастомизация сайтов, даже на конструкторе. Все no-code платформы неизбежно состоят из стандартных элементов и базовой стилизации. Дизайнер, который понимает, как пишется фронтенд, может запросто добавить собственной магии в шаблон, собрать с нуля компонент, которого нет в базовой библиотеке. То есть выпускать на рынок продукты, которые не выглядят как конструктор, но собираются без привлечения разработчиков.
Не думайте, что я пытаюсь решить проблему в одностороннем порядке. Дизайнеры, которые шарят в коде, с каждым годом все больше будут востребованы на рынке. Но и разработчики интерфейсов тоже должны учиться понимать базовые принципы дизайна, качаться в UX и так далее. Мы вместе создаем продукты и запускаем их на рынок. Так давайте запускать, а не спорить.
Мне кажется важнее правильно выстроить процессы. Когда дизайнеры и разработка эффективно коммуницируют и дают фидбек друг-другу. Когда собраны и определены ограничения платформы, проекта и дизайнер в это посвящен.
Перед тем как официально устроиться на первую работу дизайнером я прошла курс на html академии по html и css. Я не скажу, что эти знания мне сильно пригодились, хотя курс мне понравился. Куда больше полезной информации я получала от команды разработки на практике задавая вопросы и вникая в их работу.
Брать 36 килорублей за обучение Webflow, в то время как у Webflow есть прекраснейший https://university.webflow.com/ где весь объем информации в превосходной подаче можно получить совершенно бесплатно. Вывод: учите английский.
Курс не про вебфлоу и не про то, как им пользоваться.
Он про обучение с нуля и интеграцию полученных знаний в no code. На примере вебфлоу. Расширить возможности инструмента, сильнее его кастомизировать и так далее.
Да, английский сэкономит не только ваши деньги, но и поможет в получении знаний в том виде, в котором они изначально задумывались, а не через мнение очередного эксперта. Пусть даже с большим опытом.
А ведь знания задумал тоже какой-то чувак с большим кхм опытом. Пусть и англоговорящий
Во 1вых, не увидел спич на тему того, как разработчик читает Нормана, проходит курс по UX или смотрит видос от Яндекс практикум.
Во 2торых, я так понял дизайнер должен быть дохера подкованным и это все игра на одной стороне, тк требований к базовым принципам UX для разработчиков я не нашёл.
PS
Нашёл внизу в двух словах.
Курс не про вебфлоу, в том виде в котором его дают в его академии. Курс про то, как научится использовать технологии так, чтобы расширять возможности таких платформ и использовать его как инструмент. При этом он позволяет исключить кучу инструментария, который вообще не нужен.
Бро, только ты в праве устанавливать себе лимиты и минимальные системные требования. Профессиональная ориентация — это не решает 👀
И вообще, какие лимиты. Давайте быть БЕЗГРАНИЧНЫМИ? :-)
Сережа 🤦
Серёженька 🤦♂️
Серёня 🤦
Сержик :))
Комментарий удален модератором
Комментарий удален модератором
Рекомендую учить разработку только в том случае, если вы будите это применять на практике. Знания, которые не используешь — забываются. Проверено на себе.