Мой друг Уэйн Гринвуд (Wayne Greenwood) спросил моё мнение по поводу поста в своём блоге, где он утверждает, что дизайнеры не должны писать код. Цитирую: «Время — это игра, где всегда есть победитель и проигравший. Чем глубже вы погружаетесь в код, тем меньше времени остаётся для совершенствования пользовательского опыта и стратегии продукта». Другой мой друг, @miniver, втянул меня в дискуссию на эту тему в Twitter — в итоге я решил поделиться своими соображениями, выйдя за рамки 140 символов.

Главный аргумент

Говоря, что дизайнеры не должны писать код, Уэйн приводит очень убедительный аргумент: если вы станете думать о том, как создаётся система, это знание неизбежно повлияет на ваш дизайн. И если вы не предпримите ничего, чтобы противостоять этому влиянию, дизайн ПО будет происходить по схеме, которую Алан Купер называет «моделью реализации». Купер утверждает, что «правильные» дизайнеры разрабатывают программное обеспечение с учетом «ментальной модели» пользователей.

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

Аргумент убедителен, но вывод неверен

Я считаю, что суть проблемы описана очень верно — но какие из этого следуют выводы? Уэйн утверждает (справедливости ради стоит заметить, что то же утверждал и Купер, и @miniver и многие другие, включая меня самого в незапамятные времена), что дизайнеру не надо программировать. Сейчас я считаю, что это странная и довольно ограниченная точка зрения.

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

Во-вторых, код — настолько широкое понятие, что едва ли можно определить его смысл. Что мы имеем в виду, говоря «программирование»? Мы говорим о работе бэк-энд программистов, которые пишут API на C#? Или о разработчиках полного цикла, создающих веб-приложения на Rails? Или о фронт-энд девелоперах, использующих HTML, CSS и Javascript?

HTML+CSS+Javascript в работе дизайнера

Я знаю немало дизайнеров, работающих с HTML, CSS и Javascript. (Множество разработчиков не считают это «настоящим» программированием, но в моей статье я буду называть это так — большинство людей, утверждающих, что дизайнеры не должны писать код, подразумевают именно использование HTML, CSS и Javascript.) Их рабочий процесс строится следующим образом: наброски на бумаге — графический редактор — инструмент — дуэт текстового редактора и браузера — и так по кругу.

Я не вижу в таком порядке работы ничего плохого. Мне кажется, это логичное продолжение истории — точно так же 15 лет назад дизайнеры осваивали PhotoShop. Код — инструмент для гиков, просто технология, но некоторым удается добиться больших успехов в работе с ней. По моему опыту, такая организация рабочего процесса не влияет на количество удачных или неудачных идей. При «правильном» подходе, когда роли и полномочия разделены, процент хороших идей тот же.

Замысел дизайнера

Главное преимущество, которое я вижу в программировании для дизайнеров — это качество готового продукта. Опыт показывает, что если дизайнер лучше контролирует реализацию идеи, реализация будет точнее соответствовать его замыслу. Думаю, большинство дизайнеров это оценят.

Угроза дизайну как профессии

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

С этим нельзя поспорить, разве что заметить, что сегодня не так часто встретишь безработного UX-дизайнера. Наш труд никогда не пользовался большим спросом, чем сейчас. Война окончена. Дизайнер стал полноценным членом команды. Мы можем сложить оружие и перестать страдать фигней в текстовых редакторах. Если вам всё ещё приходится бороться с пережитками прошлого в своей компании — увольняйтесь и переезжайте в Сан-Франциско или Нью-Йорк. Будущее рождается здесь, и нам нужны рабочие руки.

Дополнения

Дополнение 1: многие комментаторы отметили, что я обошел вниманием главную мысль Уэйна: что дизайнеры могут и должны развивать свою карьеру, изучив стратегическое управление разработкой. Я полностью поддерживаю эту мысль. Мой коллега Джифф Констебл (Giff Constable) посвятил этому вопросу замечательный пост: http://giffconstable.com/2011/12/strategic-ux-vs-tactical-ux/

Дополнение 2: некоторые комментаторы заключили из моих слов, будто, по-моему, дизайнеры должны программировать. Я так вовсе не думаю. Мир цифрового дизайна огромен и разнообразен. (Невероятно, но многие из нас работают за рамками веба!) Любой проект требует настолько разнообразных навыков, что они уже не могут уживаться в одном теле. Итак... специалисты широкого профиля? Да. Обязан ли дизайнер заниматься программированием? Нет. (Более детально этот вопрос рассмотрен в статье Дэвида Касали (Davide Casali): http://intenseminimalism.com/2011/designers-shouldnt-code-the-digital-duo/).

Оригинал: http://joshuaseiden.com/blog/2013/08/designers-shouldnt-code-is-the-wrong-answer-to-the-right-question/

Никита Обухов
CEO / креативный директор в Tilda Publishing / FunkyPunky

Начнем с того за что я люблю веб-дизайн: он очень логичен. Это не творчество, а проектирование. Программирование — очень здорово развивает логику. Во-вторых — веб очень связан с технологиями, по-этому знание как верстается твой дизайн помогает намного лучше спроектировать решения которые хорошо адаптируются под различные устройства, не тормазят в браузерах и т.д. Я вообще за мультидисциплинарность. На мой взгяляд хороший специалист должен знать все. Я сам умею отлично программировать как front-side так и back-side. Другое дело, что в вебе — технологии очень быстро меняеются, по-этому специализироваться надо все же на дизайне, ну и дружить конечно же с технологами. Само программирование может быть очень творческим и доставлять очень приятные эмоции. Самое важное — это желание сделать что-то новое и интересное. Когда у тебя появляется новый скил — это всегда дает больше возможностей.

Сергей Попков
Owner/Partner в AIC

В статье есть интересное уточнение. А что такое знать «код»?

Уже несколько лет мы оперируем такими понятиями как front-end и back-end. По моему мнению, именно front-end (в простонародье верстка) для ux-дизайнера является очень важным знанием и полем для понимания и творчества. Я не говорю, что он должен «кодить» это сам. Нет. Просто необходимо понимать принцип работы скриптов, html5/css3 и т. д.

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

Начинающие дизайнеры, ввиду трендов и обилия интересных референсов часто пренебрегают знаниями front-end технологий.

Чем это грозит?

Не всегда и везде готовые и уже работающие интерактивные ux-сценарии оказываются жизнеспособными для конкретной задачи. Мы часто сталкиваемся с вводными ограничениями относительно версионности браузеров, адаптивности и средней загрузки процессора. Из-за чего уже на старте следует понимать, на каких конкретных скриптах и в каких браузерах должна работать твоя ux-стратегия. А будет ли оно действительно так круто работать у всех пользователей, как на твоем новеньком iMac, в последней версии Chrome?

В идеальном сюжете дизайнер должен очень внимательно проработать свои идеи с учетом front-end технологий. Поэтому есть такие термины как низко- и высоко-уровневые прототипы. На низких мы прогоняем голый UX. На высоких тестируем косметику и эффекты на разных платформах вместе с front-end разработчиками.

Именно поэтому, опытный дизайнер с адекватным восприятием front-end не будет настаивать на анимационном размытии фона, если в требованиях стоит какой-нибудь IE. Хотя очень бы хотелось :)).