Рано или поздно каждый продуктовый дизайнер сталкивается с вопросом: нужно ли ему уметь программировать? Если вы уже сталкивались, то вот вам краткий ответ: дизайнеру не обязательно уметь программировать. На этом месте я мог бы закончить свой рассказ, но давайте копнём глубже.

Первым делом давайте договоримся, что мы не говорим о том, что дизайнеры должны уметь программировать, чтобы брать на себя задачи программистов на работе. Программирование для дизайнера рассматривается только как полезное дополнение к его основным навыкам.

Под продуктовым дизайнером в статье имеется в виду дизайнер цифровых продуктов, UI/UX-дизайнер, и остальные подходящие названия к этой профессии.

Дизайн и логика

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

Пример логическорй схемы из простых фигур и описаний. Источник фото: Kelly Sikkema on Unsplash
Пример логическорй схемы из простых фигур и описаний.
Источник фото: Kelly Sikkema on Unsplash

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

Как только вы начнёте включать логические схемы в ваши макеты, которые объясняют, какие действия в системе происходят под капотом у ваших дизайнов, то вы никогда не будете прежним, и вы выйдете на новый уровень профессионализма. Дополнительно к этому прекрасному чувству, вы станете сильно ближе к разработчикам, которые, на самом деле, должны быть вашими близкими друзьями на работе, потому что именно они воплощают в жизнь всё то, что вы создали в Фигме или Скетче. 

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

Пример совмещения логических схем и дизайна интерфейсов. Источник фото: IntroOne user flow from Michal Kulesza
Пример совмещения логических схем и дизайна интерфейсов.
Источник фото: IntroOne user flow from Michal Kulesza

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

Во-вторых, количество вопросов от разработчиков, когда они будут анализировать ваш дизайн, будет сильно меньше. Часть вопросов от них, как раз, и будет про возможные исходы на каждом шаге ваших сценариев, а вы — такие молодцы, уже об этом подумали и всё показали в макетах.

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

Как бонус ко всем пунктам выше, это сэкономит вам кучу времени, потому что эти схемы очень легко обсуждать с продуктовой командой и вносить в них изменения. Никто не будет обсуждать вашу визуализацию, ваши кнопки и формы, композицию на странице. Этого всего не будет существовать на том этапе, и вы не будете сваливаться в ненужные разговоры и отвлекаться от логики продукта. Тут только простые геометрические фигуры и никакого визуала. Хотя я понимаю, что иногда руки чешутся сразу сесть и начать рисовать макеты без всяких вайрфреймов и почти на чистовую. Мы всё-таки говорим о более сложных продуктах, где есть разные условия поведения и ветвления сценариев.

Стоит сказать, что если интерфейс очень простой и линейный без каких-либо ветвлений условий, или состоит из трех страничек, то конечно можно и почти сразу на чистовую. Всё зависит от задачи.

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

Я считаю, что это базовый минимум, который нужно понимать продуктовому дизайнеру, UX-дизайнеру или дизайнеру интерфейсов. Кстати, если вы не захотите в этом разбираться самостоятельно сразу, то с опытом вы всё равно будете постоянно ходить по этим граблям и рано или поздно начнете в этом разбираться. Но вы потратите больше нервов и ресурсов. Вам не избежать этого, если вы начнете делать более-менее сложный продукт. И чем сложнее продукты, тем чаще это будет всплывать.

Про HTML и CSS

Начну с того, что HTML и CSS не являются языками программирования, это языки разметки и оформления в вебе. Но вообще это выглядит и работает именно как программирование, если упростить объяснение.

Так выглядит HTML.Источник фото: Pankaj Patel on Unsplash
Так выглядит HTML.
Источник фото: Pankaj Patel on Unsplash
Так выглядит CSS.Источник фото: Nick Karvounis on Unsplash
Так выглядит CSS.
Источник фото: Nick Karvounis on Unsplash

Сам процесс работы с HTML и CSS похож на программирование: вы создаёте инструкции для компьютера, а он по ним проходит и выполняет. 

А можно ли прожить ничего не зная про HTML и CSS? Можно. Но будьте готовы, что вы не будете понимать сколько занимает сделать кнопочку более круглой и более красной. Займет ли это 10 минут разработчика или два часа. Также будет сложнее делать адаптивные версии интерфейсов, потому что вы не будете понимать, по каким законам работает веб и как трансформируются все блоки. Я не говорю слово «невозможно», я делаю акцент на том, что будет сложнее, чуть больше граблей в работе, чуть больше времени на обсуждения с разработкой и чуть больше времени на макеты.

Вы можете взять любой курс типа «HTML/CSS Основы», и этого будет достаточно для начала. После этого, помимо понимания основ работы веба, вы, например, сможете открыть любую страничку в браузере, залезть в код, прямо там что-то изменить и тут же посмотреть, как это будет выглядеть. Вы даже сможете спроектировать страничку, поменяв тексты и картинки прямо на живом сайте, и вам даже не придется открывать Фигму.

Показываю как в браузере можно менять любой сайт
Показываю как в браузере можно менять любой сайт

Еще один плюс — вы сможете говорить с разработчиками на одном языке. Скажете не «увеличьте пожалуйста отступ у этого элемента вполовину, давайте его подвинем на 20px влево и перекрасим текст в розовый цвет», а придете к разработчику с куском CSS-кода, и он вас поймет. У него не будет шанса вас не понять с первого раза. Как результат — меньше обсуждений, меньше вопросов и переделок, все счастливы.

Ну так что в итоге?

Подводя итог после того, что я сказал выше. Всё, что вам надо уметь и знать из области программирования, чтобы быть более продвинутым дизайнером, это:

  1. Рисовать прямоугольнички, стрелочки и объяснять логические последовательности (логика). Это база программирования и большой ваш помощник как дизайнера, если вы занимаетесь цифровыми продуктами.

  2. Знать основы HTML/CSS

  3. Всё, больше ничего

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

Бесплатных курсов на эти темы навалом в интернете: Coursera, Udemy, <любой_другой_провайдер>. Про эти основы почти невозможно сделать плохой курс, чтобы вы ничего не поняли или поняли что-то не то.

Так что смело пробуйте учиться, если вам это интересно и вы хотите выйти на новый уровень работы в дизайне продуктов.

Комментарии (1)


  1. Batalmv
    21.08.2023 10:35

    Я думаю, более рабочей выглядит связка дизайнера и бизнес-аналитика со знанием домена, который не стесняются спросить мнение лида/архитекта

    И единорогов на рынке искать не надо

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