Майк Монтейро - Дизайн – это работа

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

Мой любимый метод работы с информационным дизайнером – расположиться перед большой доской и схематично изобразить то, над чем мы вместе работаем. Чем раньше вы начнете совместно разрабатывать решения, тем удачнее будет проект. А доски позволяют легко и быстро вносить изменения. Мы делаем много фотографий. Рано или поздно вам придется вернуться назад и документировать весь этот материал для клиента. Но чем больше вы советуетесь друг с другом и обсуждаете все в процессе, тем вероятнее, что вы придете к хорошему решению, с которым оба будете согласны.

Каждый день по всему миру, возможно и сейчас, когда вы читаете эти строки, некий дизайнер делает презентацию схем связей (страниц), или прототипов, клиенту. Схема страниц – это страшно запутанная вещь для того, кто не обучен в этом разбираться. Запутанная даже для тех, кто управляет сайтом. (Видели когда-нибудь схему электропроводки холодильника? Тем не менее вы суете в холодильник руку много раз в день.)

И словно показ очень запутанного документа уже сам по себе не достаточное наказание, мы добавляем самую большую ложь, которую только можно сказать клиенту: «Это не подра-зумевает реальное расположение блоков».

Чтоб мне провалиться! Как его можно не подразумевать?

Это обычно делается, чтобы оставить достаточно свободы действий дизайнеру визуальной части, который появится позже и будет иметь возможность все передвинуть и организовать пространство, чтобы приступить к своей работе. Что, кстати говоря, мы просто обожаем. Однажды я работал с информационным дизайнером, который орал на меня за то, что я «все передвигаю»! (Его уже нет с нами. Я имею в виду в нашей отрасли. Состава преступления не было обнаружено.) Мы по эстафете передаем эту проблему клиентам. Но клиента нельзя просить игнорировать самое очевидное, что предстает перед его глазами, – организованное пространство! Подумайте о том, сколько времени мы сэкономим на собраниях, если перестанем постоянно повторять эту глупую фразу.

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

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

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

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

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

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

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

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

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

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

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