Информационные дизайнеры

Информационный дизайнер или информационный «архитектор» – одна из дизайнерских специальностей. Возможно, вы как раз им и являетесь! (Реплика в сторону: я ненавижу термин «информационный архитектор», это позорное словосочетание вроде «роман-комикс». Дизайнер – это дизайнер.) Он определяет структуру: как все устроено, как добраться из точки А в точку Б, систематику, принципы организации, категории и другое. В целом он определяет, где что находится и как до этого добраться.

Информационные дизайнеры конкретизируют структуру и основополагающие принципы сайта, то есть чертежи (отсюда и слово «архитектор»). Они, как правило, поддерживаются каркасами, также называемыми схемами страниц.

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

Это не означает, что дизайнер, разрабатывающий визуальную часть, прохлаждается до тех пор, пока информационный дизайнер не получит добро. Лучше всего, когда обе стороны как можно теснее сотрудничают, придумывая варианты, а затем принимаются каждая за свое. Решаем вместе, исполняем порознь.

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

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

Кто отвечает за макет? Решим эту проблему раз и навсегда

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

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

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

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

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

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

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

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

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

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

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

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

Инженеры

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

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

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

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

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

– Нельзя!

– Почему?

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

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

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

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

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

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

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

Дизайнеры обычно считают, что то, чем они занимаются, «тяжело», потому что очень субъективно, а то, чем занимаются разработчики, «легко», так как существует «правильный» ответ. Но я могу заверить вас: в том, как разработчик решает проблему, столько же (если не больше) творчества, чем в занятиях дизайнера.

Маркетологи

Я всегда считал, что дизайн – это и есть маркетинг. Хорошо спроектированный стул притягивает к себе вашу задницу, хорошо спроектированный велосипед даже в самом честном из нас вызывает желание украсть его, а хорошо спроектированным сайтом хочется пользоваться. Так почему же понятие «маркетинг» оставляет у дизайнеров такое неприятное послевкусие? Да потому, что чаще всего это плохой маркетинг.

Есть хорошие и плохие маркетологи, точно так же как есть хорошие и плохие дизайнеры. Хороший маркетолог работает на вашу аудиторию. Плохой работает на ваших рекламодателей. Хороший маркетолог будет работать с вами, чтобы вместе создать лучший продукт для ваших клиентов. Его основная задача – сделать так, чтобы сайт продолжал работать и отвечать нуждам пользователей. Самый простой способ узнать, насколько хорош или плох ваш маркетолог, спросить его: «Не могли бы вы объяснить, что это значит?» – после того как он что-то произнес. Если он этого сделать не в состоянии, можете убить его на месте.

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

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

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

Контент-стратегия

Я приберег свой любимый сюжет для финала. В последнее время заметно возрождение контент-стратегии, что в некотором смысле радостно. С одной стороны, я очень рад, что об этом заговорили и начали развивать это направление. С другой стороны, есть тенденция относиться к этому как к новому ремеслу, что напоминает мне времена, когда веб-дизайнеры выпустили Photoshop и вообразили, что изобрели дизайн. Контент-стратегии, безусловно, не уделялось должного внимания, но едва ли это можно назвать новинкой, тем более в мире Интернета.

Поскольку мы уже достаточно далеко продвинулись в этой книге, я могу сообщить вам одну плохую новость. Почти никто не заходит на созданные вами сайты ради великолепного дизайна, а те немногие, кто это делает, хотят что-то украсть. Люди заходят на сайты ради содержания. Дизайн делает это содержание доступным и приятным в использовании, но дизайн – это не содержание. Сайт состоит из контента. Дизайн – это то, что собирает весь этот контент воедино.

Не огорчайтесь, ведь «Золотые ворота»[15] тоже всего лишь позволяют машинам въехать в город, но люди фотографируют именно мост.

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

В любом виде дизайна есть два святых вопроса: «Для кого это делается?» и «Что вы в это собираетесь вложить?». Специалист по контент-стратегии – настоящая находка для ответа на последний вопрос. И этот ответ должен содержать информацию о том, что вы разрабатываете. Вы не сможете запихнуть самца гориллы в кошачью повозку.

Не нашли, что искали? Воспользуйтесь поиском: