То же самое относится к безобразной практике обнародования своей версии дизайна, который только что был запущен. Безусловно, вы можете его критиковать. Пишите о том, что работает и что не работает, но имейте в виду, что другой дизайнер работал в условиях ограничений и корпоративной политики, о которых вы можете не знать. Так что изложите свои мысли как пользователь или даже как пользователь, который также является дизайнером.
Но найти время, чтобы переделать их работу и публично обнародовать ее, самодовольно и мелочно. (Да, это случилось со мной. Да, я до сих пор злюсь на себя.)
Будьте едины. Или мне придется на вас наорать.
Но погодите, одних дизайнеров не хватит, чтоб сделать дело, верно? Давайте познакомимся кое с кем из остальных.
Эти остальные люди в офисе
Работать с другими людьми просто: выясните, чего они хотят, и убедитесь, что они понимают, чего хотите вы. Все остальное – небольшие погрешности.
Несколько лет назад, когда моя компания была в младенческом возрасте, я натурально подсел на одну телепередачу на канале «Дискавери» (канал, по которому показывают обезьян с молотками) под названием «Дом-монстр». Суть передачи в двух словах: прораб Стив собирает группу подрядчиков, каждый из которых имеет определенную специальность, и вместе они должны за неделю полностью переделать часть чьего-то дома. В течение недели подрядчики препираются. Но каким-то образом в конце им всегда удавалось завершить работу, и владельцы дома приходят либо в восторг, либо в ярость от того, что в гостиной у них теперь огнедышащий фонтан, а на месте газона теперь ров.
Но больше всего в этой передаче мне нравилось (по крайней мере, имея в виду нашу с вами сегодняшнюю беседу) самое начало. Прораб Стив собирал всю свою команду, и они начинали обсуждать, что можно сделать. На этом этапе все работали сообща. Плотник предлагал разводной мост на заднем дворе, генеральный исполнитель заводил речь о том, как это осуществить, разрушив при этом 75 % несущих стен дома, а электрик прикидывал, сколько электроэнергии придется украсть у соседей, чтобы это заработало.
Тогда я сказал Эрике, моему партнеру: «Вот как надо работать! Мы должны привлечь к проекту всех с самого начала».
И именно так мы и работаем. В начале каждого проекта все члены команды собираются вместе и подают идеи. В помещении накапливается фантастическое количество энергии, когда мы одновременно обсуждаем, как организовать, спроектировать и построить что-нибудь. Затем мы смотрим, заставит ли нас чья-то идея выйти за рамки бюджета или не уложиться в срок, тогда как наш ведущий исследователь подсказывает нам, что никто не захочет иметь сайт с огнедышащим фонтаном.
Таким образом, когда мы все отправляемся заниматься каждый своей работой, мы помним о том, что вместе собирались строить.
Я работал во многих компаниях, где мне на стол бросали уже полностью готовые схемы страниц и в качестве свершившегося факта отправляли разработчикам макеты, которые те зачастую видели впервые, и я могу сказать вам, что это не работает!
Если вам повезло работать в кабинете, где сидят дизайнеры всех специальностей, необходимо использовать их в полной мере. Работайте вместе. С самого начала и регулярно. Разделяйте неудачи и успехи друг с другом. Но я гарантирую, что, если вы найдете людей, с которыми сработаетесь, успех перевесит неудачи.
В зависимости от того, где вы работаете, у вас в офисе может быть множество других людей. Даже если вы работаете в одиночку в своей квартире-студии, вам, несомненно, приходится взаимодействовать с другими людьми (другими мастерами!) в течение дня.
Мы уже подробно обсудили клиентов, равно как и адвокатов и, конечно же, других дизайнеров. Но веб-дизайн – сложная вещь. В нем много компонентов. И все эти компоненты требуют мастеров своего дела.
Если вы работаете в небольшой компании, один и тот же человек может выполнять многие функции. Если вы работаете в крупной компании, каждая из этих функций может быть разбита на скучнейшие «подфункции».
Но так или иначе, все, с кем вы работаете, также отвечают за успех проекта и заслуживают вашего уважения.
Руководители проектов
Вы знаете, что самое классное в руководителях проектов? То, что они руководят проектами. Они следят за тем, чтобы все было вовремя и в рамках бюджета. Они распределяют ресурсы и следят, чтобы вы работали над тем, над чем должны работать. Они делают это, тщательно выстраивая всю структуру проекта. Они тратят уйму времени на сложные расписания, которые обеспечивают завершение проекта в срок, и, когда все сдвигается, они переделывают все заново.
Так же как вы несете ответственность за качество проекта, руководитель проекта несет ответственность за своевременное его выполнение. И с максимальным количеством прибыли. Это не означает, что вы оба не должны заботиться о работе другого. Это означает, что каждый отвечает за свою часть. Это часто приводит к напряженности, так как ваша основная цель – сделать работу хорошо, а основная цель руководителя проекта – сделать работу в срок. В принципе, так и должно быть. Каждая из сторон стремится добиться того, за что отвечает, и, борясь друг с другом, вы имеет шанс представить отличную работу в срок.
Руководитель проекта также служит для вас голосом клиента. Он следит за тем, чтобы требования клиента были учтены, и отвечает за повседневное общение с ним.
Руководитель проекта – не ваша мама. Он может быть мамой проекта, но не вашей. Он не обязан руководить вами за пределами того, что имеет отношение к проекту.
Самый лучший способ работы с руководителем проекта – ясно понимать, за что каждый из вас отвечает, и держать его в курсе работы над проектом. Не тяните бесконечно, чтобы сообщить руководителю проекта о проблеме. При малейшем намеке на срыв сроков поставьте его в известность. Помогите ему помочь вам, дав ему время решить эту проблему с клиентом.
Иной раз вам кажется, что вы и руководитель проекта работаете в противоположных направлениях, но это не так. Вы стремитесь к той же цели, просто у вас разные способы ее достижения.
Вы также можете облегчить ему (и, соответственно, себе) жизнь, сократив «творческий» процесс. Реально оценивайте время, придерживайтесь сроков, понимайте масштабы. Будьте человеком, на которого можно рассчитывать.
Исследователи
Хороший исследователь проследит за тем, чтобы вы не настроили домов с подвалами в зоне наводнения. Исследователи проводят беседы с командой клиента и с потенциальными пользователями. Они рассматривают аналитические показатели клиента. Их работа заключается не в том, чтобы сказать вам, что́ проектировать (в конце концов, ни один исследователь не мог сказать Генри Форду, что люди хотели ездить на автомобилях). Но хороший исследователь мог бы сказать ему, что людям нравится передвигаться с большей скоростью.
Подобно тому как руководитель проекта служит голосом клиента, исследователь служит голосом пользователя. Хороший исследователь будет непосредственно общаться с теми людьми, для которых предназначена ваша работа, и выяснит, каковы их привычки и склонности. Хорошее исследование бесценно для выбора верного пути.
Следует завести привычку как можно чаще присутствовать на таких интервью с потребителями. Это даст вам гораздо лучшее представление о тех, для кого предназначен ваш дизайн.
Успех любого проекта зависит от того, какой отклик он найдет у своей целевой аудитории. И ваш исследователь – это ваша способность понимать эту аудиторию. Обращайтесь с ним хорошо.
Информационные дизайнеры
Информационный дизайнер или информационный «архитектор» – одна из дизайнерских специальностей. Возможно, вы как раз им и являетесь! (Реплика в сторону: я ненавижу термин «информационный архитектор», это позорное словосочетание вроде «роман-комикс». Дизайнер – это дизайнер.) Он определяет структуру: как все устроено, как добраться из точки А в точку Б, систематику, принципы организации, категории и другое. В целом он определяет, где что находится и как до этого добраться.
Информационные дизайнеры конкретизируют структуру и основополагающие принципы сайта, то есть чертежи (отсюда и слово «архитектор»). Они, как правило, поддерживаются каркасами, также называемыми схемами страниц.
Клиент должен утвердить основную структуру сайта в виде голого каркаса до презентации. Таким образом мы получаем согласие клиента на различных этапах пути, и разногласия могут возникнуть только в пределах последнего полученного согласия. Это как завязывание узлов на канате.
Это не означает, что дизайнер, разрабатывающий визуальную часть, прохлаждается до тех пор, пока информационный дизайнер не получит добро. Лучше всего, когда обе стороны как можно теснее сотрудничают, придумывая варианты, а затем принимаются каждая за свое. Решаем вместе, исполняем порознь.
За годы своей карьеры я работал в разных местах, где веб-дизайнеры творили, не снимая наушников и не позволяя никому себя беспокоить, а затем бросали на мой стол около сотни прототипов сайтов. Выглядеть они могли по-разному: от карандашных набросков до полноценных макетов. Затем дизайнер с головой окунался в следующий проект. Процесс этот известен как «каскадное проектирование». Потому-то вам и хочется засунуть такого человека в бочку и бросить в настоящий водный каскад.
Мой любимый метод работы с информационным дизайнером – расположиться перед большой доской и схематично изобразить то, над чем мы вместе работаем. Чем раньше вы начнете совместно разрабатывать решения, тем удачнее будет проект. А доски позволяют легко и быстро вносить изменения. Мы делаем много фотографий. Рано или поздно вам придется вернуться назад и документировать весь этот материал для клиента. Но чем больше вы советуетесь друг с другом и обсуждаете все в процессе, тем вероятнее, что вы придете к хорошему решению, с которым оба будете согласны.
Кто отвечает за макет? Решим эту проблему раз и навсегда
Каждый день по всему миру, возможно и сейчас, когда вы читаете эти строки, некий дизайнер делает презентацию схем связей (страниц), или прототипов, клиенту. Схема страниц – это страшно запутанная вещь для того, кто не обучен в этом разбираться. Запутанная даже для тех, кто управляет сайтом. (Видели когда-нибудь схему электропроводки холодильника? Тем не менее вы суете в холодильник руку много раз в день.)
И словно показ очень запутанного документа уже сам по себе не достаточное наказание, мы добавляем самую большую ложь, которую только можно сказать клиенту: «Это не подра-зумевает реальное расположение блоков».
Чтоб мне провалиться! Как его можно не подразумевать?
Это обычно делается, чтобы оставить достаточно свободы действий дизайнеру визуальной части, который появится позже и будет иметь возможность все передвинуть и организовать пространство, чтобы приступить к своей работе. Что, кстати говоря, мы просто обожаем. Однажды я работал с информационным дизайнером, который орал на меня за то, что я «все передвигаю»! (Его уже нет с нами. Я имею в виду в нашей отрасли. Состава преступления не было обнаружено.) Мы по эстафете передаем эту проблему клиентам. Но клиента нельзя просить игнорировать самое очевидное, что предстает перед его глазами, – организованное пространство! Подумайте о том, сколько времени мы сэкономим на собраниях, если перестанем постоянно повторять эту глупую фразу.
В течение многих лет мы пытаемся придумать способ заставить реку течь в гору, и что получается в результате, вы и сами поняли из моей метафоры. Так позвольте макету быть макетом. Пусть дизайнер визуальной части и информационный дизайнер работают вместе с самого начала. Пусть они придут к согласию по поводу основной сетки, потенциального макета, размещения основных функций и прочего. И пусть каждый развивает и то, и другое, и третье по мере продвижения проекта так, чтобы все понимали, что происходит.
Поэтому, когда вы кладете перед клиентом нечто, вы можете сказать примерно так: «Вот примерный набросок макета, который мы вместе продолжим разрабатывать».
Так кто же отвечает за макет? Вы все. Можно теперь перестать спорить по этому поводу? Это утомительно.
Разработчики
Если вы веб-дизайнер, то должны знать, как писать программы. Однако если, как и я, вы можете позволить себе роскошь работать с отличнейшими разработчиками, то можете обнаружить, что ваши практические навыки немного заржавели, даже если вы следили за всеми невероятными и удивительными новинками в нашей области в течение последних нескольких лет.
Из всех моих сотрудников в офисе теснее всего я сотрудничаю с разработчиками, потому что до тех пор, пока мы не начинаем писать программы, мы просто рисуем картинку сайта. Мы работаем в довольно быстром темпе в унисон. Я не передаю им куски на разработку, мы вместе работаем над теми частями, которые требуют совместных усилий. Чем быстрее мы доберемся до кодов, тем скорее мы сможем начать их пересматривать.
Например, вам нравится интерактивный дизайн, верно? Как раз на этой неделе я начал работать над наброском расширенной версии сайта для настольного компьютера, и, как только мы пришли к соглашению по основному прототипу, мой программист Джим Рэй начал работать над интерактивными компонентами. Но каждые пятнадцать минут или около того одному из нас приходилось корректировать свою работу, потому что другой либо обнаруживал проблему, либо находил лучший способ что-то сделать. Мы принимали решения быстрее, и сами решения были лучше, потому что дизайн и программирование шли рука об руку. Если бы я попытался сделать макет всех этих интерактивных компонентов, а затем передать их Джиму, чтобы тот написал программу, эти ошибки оказались бы внутри и у нас ушло бы несколько дней на то, чтобы выявить их. Не говоря уже о том, что мы, скорее всего, попросили бы клиента утвердить окончательный дизайн, который на самом деле нуждался в поправках.
Мы часто работаем над макетом столько, сколько требуется для полной ясности, и именно поэтому мы не включаем сделанные в Photoshop макеты в нашу заключительную презентацию. Такие макеты отражают беспорядок, часто неоконченный беспорядок, который может иметь очень мало общего с тем, что мы в итоге построили. Не тратьте время на обновление картинки, тогда как клиент платит вам за сайт.
Инженеры
Разработчики создают то, что вы спроектировали. Они бывают на любой вкус и цвет: разработчики приложений, веб-разработчики и разработчики софта. Их часто собирательно называют серверными разработчиками. А иногда – клиентскими разработчиками.
Я говорю о программистах отдельно, потому что они тесно сотрудничают с дизайнерами, и во многих случаях дизайнер сам является программистом, так что я думаю, что это несколько иные отношения. Хотя по мере того, как разработчики движутся в сторону таких языков, как JavaScript, Ruby, PHP, Python, они с большей вероятностью могут начать называть себя программистами (и просить более высокую зарплату).
Вы, наверное, слышали выражение «спроектировано разработчиками»? Так, вероятно, говорят те же люди, которые любят выражения вроде «создано дизайнерами».
Давным-давно, на заре моей карьеры мне поручили пересмотреть дизайн для компании, где я только начал работать. Дизайнерская команда разрабатывала новый процесс регистрации. Я настаивал на том, что третий шаг должен предшествовать второму. (Я не помню, был ли я прав, но давайте предположим, что был.) Все остальные члены команды, работавшие там гораздо дольше меня, утверждали, что шаги нельзя менять местами, поскольку так постановили инженеры. Я терпеть не могу, когда дизайнер возражает не потому, что что-то правильно или неправильно, а потому, что это может повлечь за собой неприятный разговор. Просто ненавижу. Поэтому я сказал:
– Пойдемте поговорим с разработчиками.
– Нельзя!
– Почему?
И тут я понял, что никто из этой команды никогда не обсуждал ни с кем из разработчиков ничего, что касалось бы этого проекта. Команда предоставляла уже готовый продукт, который инженеры собирали вместе, зачастую на ходу пересматривая решения дизайнеров из-за ограничений, о которых мы не знали (или не спрашивали!), и обе вотчины мирно сосуществовали.
На следующий день я пригласил ведущего разработчика на обед, после которого предложил заглянуть ко мне, так как хотел ему кое-что показать. Я продемонстрировал ему новый процесс регистрации, поставив при этом третий шаг перед вторым.
– Сейчас это делается не так, – сказал он.
Я объяснил, что, по моему мнению, новый процесс приведет к более высокой конверсии, потому что он передвигает получение данных кредитной карты в конец, а вначале загружает все остальные данные пользователя. Это означает, что пользователь оказывается гораздо больше «в игре» и менее склонен отступиться, не доведя процесс до конца.
Он согласился, что это хорошая идея. И тогда мы вместе представили ее главе отдела разработки товара.
С тех пор мы регулярно обсуждали свою работу с разработчиками. Теперь они с меньшей вероятностью могли вносить изменения в дизайн, потому что мы выявляли и решали проблемы вместе.
Опытные разработчики не склонны поддаваться модным веяниям и имеют большой опыт по части прагматических решений. Они мастера своего дела так же, как и вы своего. И вы увидите, что, если вы обоснуете свои дизайнерские решения – что вы и должны делать для своих коллег, – разработчики могут быть отличным ресурсом. Но пока вы оба стоите по разным углам зала, думая, что «тот второй» какой-то странный, танцы так и не начнутся.
Дизайнеры обычно считают, что то, чем они занимаются, «тяжело», потому что очень субъективно, а то, чем занимаются разработчики, «легко», так как существует «правильный» ответ. Но я могу заверить вас: в том, как разработчик решает проблему, столько же (если не больше) творчества, чем в занятиях дизайнера.