Дизайн – это работа - [42]

Так кто же отвечает за макет? Вы все. Можно теперь перестать спорить по этому поводу? Это утомительно.

Разработчики

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

Из всех моих сотрудников в офисе теснее всего я сотрудничаю с разработчиками, потому что до тех пор, пока мы не начинаем писать программы, мы просто рисуем картинку сайта. Мы работаем в довольно быстром темпе в унисон. Я не передаю им куски на разработку, мы вместе работаем над теми частями, которые требуют совместных усилий. Чем быстрее мы доберемся до кодов, тем скорее мы сможем начать их пересматривать.

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

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

Инженеры

Разработчики создают то, что вы спроектировали. Они бывают на любой вкус и цвет: разработчики приложений, веб-разработчики и разработчики софта. Их часто собирательно называют серверными разработчиками. А иногда – клиентскими разработчиками.

Я говорю о программистах отдельно, потому что они тесно сотрудничают с дизайнерами, и во многих случаях дизайнер сам является программистом, так что я думаю, что это несколько иные отношения. Хотя по мере того, как разработчики движутся в сторону таких языков, как JavaScript, Ruby, PHP, Python, они с большей вероятностью могут начать называть себя программистами (и просить более высокую зарплату).

Вы, наверное, слышали выражение «спроектировано разработчиками»? Так, вероятно, говорят те же люди, которые любят выражения вроде «создано дизайнерами».

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

– Пойдемте поговорим с разработчиками.

– Нельзя!

– Почему?

И тут я понял, что никто из этой команды никогда не обсуждал ни с кем из разработчиков ничего, что касалось бы этого проекта. Команда предоставляла уже готовый продукт, который инженеры собирали вместе, зачастую на ходу пересматривая решения дизайнеров из-за ограничений, о которых мы не знали (или не спрашивали!), и обе вотчины мирно сосуществовали.

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

– Сейчас это делается не так, – сказал он.

Я объяснил, что, по моему мнению, новый процесс приведет к более высокой конверсии, потому что он передвигает получение данных кредитной карты в конец, а вначале загружает все остальные данные пользователя. Это означает, что пользователь оказывается гораздо больше «в игре» и менее склонен отступиться, не доведя процесс до конца.

Он согласился, что это хорошая идея. И тогда мы вместе представили ее главе отдела разработки товара.

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

Опытные разработчики не склонны поддаваться модным веяниям и имеют большой опыт по части прагматических решений. Они мастера своего дела так же, как и вы своего. И вы увидите, что, если вы обоснуете свои дизайнерские решения – что вы и должны делать для своих коллег, – разработчики могут быть отличным ресурсом. Но пока вы оба стоите по разным углам зала, думая, что «тот второй» какой-то странный, танцы так и не начнутся.