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