После сбора и ранжирования требований мы имеем четкую картину того, что именно будет содержать конечный продукт. Однако требования не описывают, каким образом эти части формируют единое целое. Разработка концептуальной структуры сайта – задача следующего уровня.
Определение структуры
Уровень структуры – третий из пяти уровней, и, соответственно, в этом месте наши интересы смещаются от абстрактных вопросов стратегии в сторону конкретных факторов, определяющих, что в конечном счете будет испытывать пользователь. Однако граница между абстракцией и конкретикой подчас бывает размыта. Хотя многие решения, принимаемые на этом этапе, окажут ощутимое влияние на разработанный сайт, сами по себе они опираются на концептуальные понятия.
В традиционном подходе к разработке программного обеспечения создание структурированного опыта взаимодействия называется проектированием взаимодействия. Раньше все это помещали под вывеску «дизайн интерфейса», но в последнее время (отчасти из-за распространения веб приложений, а отчасти благодаря настойчивым голосам тех, кто профессионально занимается этой темой) проектирование взаимодействия оформилось в самостоятельную дисциплину.
В сфере создания контента структурирование опыта взаимо действия – это вопрос информационной архитектуры. Эта область охватывает ряд дисциплин, традиционно имеющих отношение к организации, классификации, потреблению и представлению информации. Сюда входят библиотечное дело, журналистика, коммуникационный дизайн и др.
Как информационная архитектура, так и проектирование взаимодействия влияют на определение паттернов взаимодействия с пользователем и их последовательность. Проектирование взаимодействия имеет отношение к реализации возможностей, позволяющих пользователю решать задачи, а информационная архитектура – к реализации воз можностей, связанных с предоставлением пользователю информации.
Проектирование взаимодействия и информационная архитектура кажутся высокотехнологичными областями, доступными лишь посвященным, однако на самом деле не имеют никакого отношения к технологиям. Они связаны с пониманием людей, знанием того, что люди думают и как работают. Встроив это понимание в структуру нашего продукта, мы обеспечим позитивный опыт взаимодействия тем, кто будет иметь с ним дело.
Проектирование взаимодействия
Проектирование взаимодействия — это описание возможного поведения пользователя и определение того, как система будет реагировать на его поведение и приспосабливаться к нему. Каждый раз, когда человек работает на компьютере, происходит некое подобие танца: пользователь делает движение, система на него реагирует, пользователь двигается в ответ — и танец продолжается. Однако типичный подход к разработке программного обеспечения не признает существования этого танца. Считается, что поскольку все равно каждое приложение «танцует» в собственной манере, то пользователь как-нибудь приспособится. Система просто должна выполнять свою часть работы, а если кто-то кому-то наступил на ногу — что ж, это часть процесса обучения пользователя. Однако любой танцор скажет вам, что танец удается лишь тогда, когда каждый партнер отвечает на движения другого.
По традиции программисты уделяют основное внимание двум аспектам программного обеспечения: что оно делает и как оно это делает. Такому положению вещей есть объяснение: тщательное внимание к этим деталям делает программистов хорошими профессионалами. Однако в результате программисты могут зайти слишком далеко и построить систему, исключительно эффективную с технической точки зрения, но игнорирующую интересы пользователей. В прежние времена, когда вычислительные мощности были существенно ограниченными, наилучшим считался такой подход, который обеспечивал выполнение задания несмотря на ограничения, накладываемые системой.
Однако подход, наиболее удачный с точки зрения компьютера, почти никогда не является оптимальным для человека, с ним работающего. Так программное обеспечение приобрело репутацию, неотступно преследовавшую его на всем протяжении его существования: программы сложны, непонятны, и ими трудно пользоваться. Еще каких-нибудь десять лет назад обучение «компьютерной грамотности», то есть принципам внутреннего устройства и функционирования компьютеров, считалось единственным способом помочь пользователям ужиться с программным обеспечением.
Потребовалось немало времени, но по мере того как компьютеры становились все более мощными, а разработчики все лучше понимали, как люди пользуются ими, мы в конце концов пришли к мысли, что можно перейти от разработки программного обеспечения, хорошо работающего с точки зрения машины, к созданию программ, хорошо работающих с точки зрения человека, — и это позволит отказаться от отправки клерков на курсы повышения компьютерной грамотности. Новая дисциплина, призванная помочь разработчикам программного обеспечения в этом деле, называется проектированием взаимодействия.
Концептуальные модели
Собственное представление пользователей о поведении созданных нами интерактивных компонентов называется концептуальной моделью. Возьмем, например, элемент контента: что это — место, которое посещает пользователь, или объект, который пользователь получает? На разных сайтах применяются различные подходы. Знание концептуальной модели позволит вам принимать последовательные проектные решения. Неважно, будет ли элемент контента местом или объектом, — важно, чтобы сайт вел себя последовательно, а не представлял элемент местом и объектом попеременно.
Например, концептуальной моделью компонента «корзина с покупками» типичного коммерческого сайта является контейнер. Эта метафора влияет как на дизайн компонента, так и на используемый в интерфейсе язык. Контейнер содержит объекты, и поэтому мы «кладем покупки» в «корзину» или «вынимаем» их оттуда, а система должна предоставить функции, позволяющие это сделать.
Предположим, концептуальной моделью для этого компонента был бы другой аналог из реального мира — например, форма заказа по каталогу. Тогда система обеспечивала бы функцию «редактировать», которая заменила бы функции «положить» и «вынуть», типичные для традиционной корзины, а метафоре «оформить покупку» пришла бы на смену метафора «отправить заказ».
Как модель универсама, так и модель каталога прекрасно подходят для размещения заказов в Сети. Какую выбрать? Модель универсама широко распространена, то есть имеет статус соглашения. Если ваши пользователи делают много покупок на других веб-сайтах, вы, скорее всего, решите придерживаться этого соглашения. Пользователям легче адаптироваться к незнакомому сайту, если там используются привычные для них концептуальные модели. Конечно, нет ничего ужасного в нарушении соглашения, но только в том случае, если у вас есть на то веские причины, а также имеется альтернативная концептуальная модель, отвечающая потребностям пользователей.
Концептуальная модель может относиться к какому-то одному компоненту системы, а может охватывать всю систему в целом. Когда был запущен сайт Slate с новостями и комментариями, концептуальной моделью для него был обычный журнал. Сайт имел «обложку», а на каждой странице располагался ее номер и элементы интерфейса, позволявшие «переворачивать страницы». Время показало, что концептуальная модель реального журнала плохо переносится в онлайновую среду, и сайт Slate в конце концов отказался от этой концепции.
Вовсе не обязательно предъявлять наши концептуальные модели пользователям в явном виде. На практике это иногда не только не помогает пользователям, но запутывает их. Гораздо важнее, чтобы мы сами постоянно придерживались концептуальной модели на протяжении всего процесса проектирования взаимодействия. Понимание моделей, с которыми пользователи приходят на сайт (считают ли они его универсамом или каталогом), помогает нам выбрать концептуальную модель, которая будет работать наиболее эффективно. В идеальном случае нет необходимости сообщать пользователям, какой концептуальной модели мы следуем; они все поймут интуитивно по мере общения с сайтом, потому что его поведение будет соответствовать их ожиданиям.
Строить концептуальные модели на основе метафор, включающих в себя аналоги функций системы, взятые из реального мира, — очень удачный подход, но при этом важно не принимать метафоры слишком буквально. Раньше главная страница сайта авиакомпании Southwest Airlines содержала только изображение стойки для обслуживания клиентов со стопкой брошюр на одной стороне, телефоном на другой и т. п. В течение нескольких лет сайт служил наглядным примером концептуальной модели, зашедшей слишком далеко. Процедура бронирования билетов может быть аналогом телефонного звонка, но отсюда не следует, что система бронирования билетов должна быть представлена телефоном. По-видимому, авиакомпании надоело быть отрицательным примером, и сейчас ее сайт менее метафори¬чен и значительно более функционален.
Обработка ошибок
Значительная часть любого проекта, связанного с проектированием взаимодействия, включает в себя обработку «ошибок пользователя». Что должна делать система, когда люди совершают ошибки, и, прежде всего, что она может предпринять для предотвращения этих ошибок?
Первая и самая лучшая защита от ошибок — это разработка такой системы, в которой ошибки пользователей просто невозможны. Хороший пример такого типа защиты мы видим в любом автомобиле с автоматической коробкой передач. Попытка запустить мотор при включенной трансмиссии может повредить чувствительный и сложный механизм; более того, машина никуда не поедет, а лишь резко дернется вперед. Это плохо для машины, для водителя и для невинного пешехода, случайно оказавшегося рядом с дернувшейся машиной.
Чтобы этого не случилось, любой автомобиль с автоматической трансмиссией оборудован стартером, который не сработает, если рычаг выбора режима не находится в положении «парковка». Поскольку запустить двигатель при включенной трансмиссии невозможно, ошибка никогда не будет совершена. К сожалению, большинство пользовательских ошибок не столь легко предупредить.
Следующий способ исключить ошибки — сделать их затруднительными. Однако в этом случае даже при самых серьезных мерах предосторожности некоторые ошибки обязательно произойдут. Тогда система должна сделать все возможное, чтобы помочь пользователю осознать ошибку и устранить ее. В некоторых ситуациях система может даже устранить ошибку за пользователя, но будьте осторожны: ничто так не раздражает в поведении программного продукта, как чрезмерное рвение в устранении ошибок пользователя. (Если вы работали с редактором Microsoft Word, вы меня поймете: в Word встроены бесчисленные функции, призванные исправлять некоторые распространенные ошибки, но я всегда отключаю эти функции, чтобы иметь возможность нормально работать, не занимаясь исправлением исправлений.)
Каждый уровень обработки ошибок, задействованный при проектировании взаимодействия, повышает процент пользователей, получивших позитивный опыт.
Информативные сообщения об ошибках и хорошо продуманные интерфейсы во многих случаях помогут пользователям обнаружить совершенные ошибки. Однако некоторые действия пользователя могут вначале казаться корректными, а потом будет слишком поздно, чтобы система могла их обработать. В таких случаях система должна предоставить пользователю способ восстановления после ошибки. Самым известным примером такой функции является «отмена действия», однако восстановление после ошибки может принимать разные формы. Если восстановление невозможно, то единственным доступным системе способом удержать пользователя от ошибки является большое количество предупреждений. Разумеется, предупреждения эффективны, только если пользователи действительно обращают на них внимание, и поэтому последовательность диалоговых окон «Вы уверены?..» больше раздражает, чем помогает.
Информационная архитектура
Информационная архитектура связана с созданием организационных и навигационных схем, обеспечивающих экономичное и эффективное перемещение по сайту. Информационная архитектура имеет прямое отношение к вопросам информационного поиска – проектированию систем, позволяющих пользователям легко находить нужную информацию. Однако архитектура веб-сайтов часто призвана решать более широкие задачи, чем просто помощь в поиске информации: во многих случаях сайтам приходится обучать, информировать и убеждать пользователей.
Обычно решение задач информационной архитектуры требует создания классификационных схем, соответствующих целям сайта, потребностям пользователей и контенту сайта. Есть два подхода к разработке такой классификации: нисходящий («сверху вниз») и восходящий («снизу вверх»).
Нисходящий подход к созданию информационной архитектуры заключается в ее построении непосредственно на основе целей сайта и потребностей пользователей. Начиная с самых общих категорий будущего контента и функциональных возможностей, необходимых для достижения этих стратегических целей, мы проводим логическое разбиение категорий на подкатегории. Получившаяся иерархическая структура служит пустой оболочкой для контента и функциональности.
Восходящий подход к построению информационной архитектуры также состоит в выделении категорий и подкатегорий, но при этом в основу ложится анализ контента и функциональных требований. Начиная с имеющегося исходного материала (или того, который будет в наличии к моменту запуска сайта), мы группируем элементы в категории низшего уровня, а эти категории – в более крупные, чтобы выстроить структуру, отражающую цели сайта и потребности пользователей.
Ни один из этих подходов не лучше другого. При нисходящей разработке архитектуры можно иногда упустить из виду важные детали, касающиеся контента. С другой стороны, восходящий подход иногда приводит к архитектуре, настолько точно подогнанной под имеющийся контент, что ее гибкости не хватает для учета последующих изменений и дополнений. Единственный способ обойти эти ловушки на пути к конечному продукту – достичь баланса между нисходящим и восходящим подходами.
Одним из признаков эффективной структуры является ее способность приспосабливаться к изменению и развитию сайта. Однако накопление нового содержимого в конце концов может привести к пересмотру принципов организации сайта. Например, архитектура, позволяющая пользователям листать пресс-релизы в режиме «день за днем», вполне годится, когда речь идет о нескольких месяцах, однако через пару лет более удобной и практичной может стать организация пресс-релизов по темам.
Нет необходимости придерживаться какого-то конкретного количества категорий на каком-либо из уровней или в каком-нибудь из разделов архитектуры. Достаточно, чтобы категории подходили вашим пользователям и удовлетворяли их потребности. Некоторым разработчикам нравится подсчитывать количество шагов, необходимых для решения задачи, или количество щелчков, выполняемых пользователем для перехода в нужное место сайта, и затем оценивать качество структуры сайта с помощью этих цифр. Однако самый важный признак качества не количество шагов в процедуре, а то, является ли каждый следующий шаг осмысленным с точки зрения пользователя и вытекает ли он естественным образом из предыдущих шагов. Пользователи, безусловно, предпочтут четкую и ясную процедуру из семи шагов непонятной процедуре, усеченной до трех шагов.
Структура сайта, как и весь опыт взаимодействия в целом, опирается на понимание целей сайта и потребностей пользователей. Если изменились цели, которых компания собиралась достичь с помощью сайта, или потребности пользователей, которые она стремились удовлетворить, нужно быть готовым к соответствующей переработке структуры сайта.
Архитектурные решения
Элементарной единицей информационных структур является узел. Узел может соответствовать фрагменту информации любого объема. Он может быть всего лишь числом (как, например, цена товара), а может представлять собой целую библиотеку. Работая с узлами вместо страниц, документов или компонентов, мы можем пользоваться единым языком и единым набором структурных концепций для решения широкого круга разнообразных задач.
Абстрактное понятие узла, кроме прочего, позволяет задать уровень детализации, с которым мы имеем дело. Большинство проектов по созданию архитектуры веб-сайтов ограничиваются лишь упорядочением страниц. Идентифицируя страницу как базовый узел, мы объявляем, что не будем заниматься информационными элементами меньшего объема. Если же страница является слишком мелкой единицей для текущего проекта, можно считать узлом целый раздел сайта.
Узлы могут быть организованы самыми разными способами, но все эти многочисленные структуры в действительности подпадают в один из нескольких классов.
В иерархической структуре, иногда называемой деревом, или системой узел–спица, узлы имеют отношения типа «родитель–потомок». Узлы потомки представляют более узкие понятия в пределах широкой категории, представленной узлом родителем. Не каждый узел имеет детей, но у каждого (кроме самого верхнего) есть родитель. Поскольку концепция иерархических отношений хорошо понятна пользователям, а компьютеры все равно работают с иерархиями, это самый распространенный тип структур.
Матричная структура позволяет пользователю перемещаться от узла к узлу в двух и более «измерениях». Матричные структуры бывают уместны, когда нужно обеспечить навигацию по одному и тому же контенту пользователям с разными потребностями, поскольку каждая пользовательская потребность может быть ассоциирована с некоторой «осью координат» в матрице. Например, если одни ваши пользователи предпочитают искать товар по цвету, а другие – по размеру, то матрица поможет обслужить обе группы. Матрица с числом измерений более трех превратится в источник проблем, если вы рассчитываете, что пользователи станут применять ее в качестве основного инструмента навигации: человеческий мозг слабо приспособлен к визуализации перемещений в четырех и более измерениях.
Органические структуры не пытаются следовать какому-либо регулярному шаблону. Узлы соединяются произвольным образом, четкое понятие «разделов» в архитектуре отсутствует. Органические структуры подходят для работы с набором элементов, связи между которыми неясны или подвержены изменениям. Однако такие структуры не позволяют пользователю понять, в какой точке архитектуры он находится. Если вы хотите, чтобы пользователь почувствовал себя свободным исследователем (например, в развлекательных или просветительских целях), то органическая структура будет подходящим решением. В то же время она может вызвать трудности у пользователя, который захочет быстро вернуться к уже рассмотренному элементу контента.
Последовательные структуры знакомы всем по традиционным источникам информации. Последовательный языковой поток является основным среди имеющихся видов информационной архитектуры, и мы обладаем врожденными способностями к его обработке. Книги, статьи, звуко- и видеозаписи созданы специально для последовательного восприятия. Во Всемирной паутине последовательное представление используется для мелкомасштабных структур, таких как отдельные статьи или разделы. Более крупные структуры с последовательной организацией обычно применяются в приложениях, в которых порядок представления содержимого является существенным для удовлетворения пользовательских потребностей, например, в инструкциях.
Последовательная структура
Организационные принципы
Узлы в информационной структуре расположены в соответствии с организационными принципами. В основе своей организационные принципы являются критерием, по которому мы определяем, какие узлы должны быть объединены в группу, а какие останутся сами по себе. В различных областях и на различных уровнях сайта будут действовать разные организационные принципы.
Например, в корпоративном информационном сайте в верхней части дерева могут быть расположены такие категории, как «клиенты», «бизнес» и «инвесторы». На этом уровне организационным принципом является аудитория, на которую рассчитан контент. На другом сайте категориями верхнего уровня будут, например, «Северная Америка», «Европа» и «Африка». Географический организационный принцип является одним из возможных подходов для удовлетворения потребностей глобальной пользовательской аудитории.
Вообще говоря, организационные принципы, которым вы следуете на верхних уровнях сайта, тесно связаны с целями сайта и потребностями пользователей. На более низких уровнях архитектуры применяемые вами организационные принципы в большей степени подвержены влиянию специфики контента и функциональности.
Например, сайты с новостным контентом обычно используют хронологический порядок в качестве основного организационного принципа. Своевременность является самым важным фактором для пользователя (который, в конце концов, посещает сайт с новостями ради текущих событий, а не для исторических изысканий), равно как и для создателей сайта (которые должны следить за своевременностью информационного наполнения, чтобы сохранять конкурентоспособность).
На следующем архитектурном уровне на первый план выходят факторы, более тесно связанные с контентом. Например, если сайт представляет новости спорта, его контент может быть разбит на такие категории, как «бейсбол», «теннис» и «хоккей», а сайт без узкой специализации будет иметь категории «международные новости», «национальные новости» и «местные новости».
Любой подборке информации — состоит ли она из двух, двухсот или двух тысяч элементов — присуща некоторая концептуальная структура, причем в действительности обычно даже не одна. В этом часть той проблемы, которую нам предстоит решить: создать структуру нетрудно — трудно создать подходящую структуру, соответствующую нашим целям и потребностям пользователей.
Предположим, наш сайт служит хранилищем информации об автомобилях. Одним из возможных организационных принципов является расположение информации в соответствии с весом автомобиля. Первое, что увидит пользователь на таком сайте, — это сведения о самом тяжелом автомобиле в нашей базе данных, затем идет второй по весу — и так далее до самого легкого.
Для сайта, ориентированного на покупателя, это, скорее всего, неверный способ организации информации. Большинство людей в повседневной жизни не интересуются весом автомобиля. Организация информации по производителю, модели или типу автомобиля будет более подходящей для такой аудитории. Зато если наши пользователи — профессионалы, занимающиеся транспортировкой машин через океан, то вес для них будет очень важным показателем. А вот тип двигателя и расход топлива с их точки зрения — куда менее важные характеристики автомобиля (если вообще стоящие внимания).
На языке библиотечного дела такие атрибуты называются фаcетами. Они способны предоставить простой и гибкий набор организационных принципов практически для любого контента. Однако, как демонстрирует предыдущий пример, применение неподходящих фасетов может приводить к худшим результатам, чем их полное отсутствие. Распространенное решение этой проблемы — позиционировать каждый мыслимый фасет как организационный принцип и предоставить пользователям возможность самим выбирать тот, который им важен.
К сожалению, за исключением тех случаев, когда вы имеете дело с примитивной информацией, имеющей лишь несколько фасетов, такой подход быстро превращает архитектуру в нечто громоздкое и неупорядоченное. Критериев сортировки так много, что пользователи уже ничего не могут найти. Не следует перекладывать на пользователя бремя сортировки по всем атрибутам и выбора самого важного. Если стратегия помогла нам понять, что именно нужно пользователю, а набор возможностей определил, какая информация удовлетворит эти потребности, то при создании структуры мы идентифицируем те конкретные аспекты этой информации, которые будут важнейшими с точки зрения пользователей. Успешным станет такой опыт взаимодействия, в котором ожидания пользователей предвидятся заранее.
Язык и метаданные
Даже если структура безупречно отражает то, как пользователи представляют себе тематику вашего сайта, они не смогут ориентироваться в архитектуре, если не будут понимать вашу классификационную номенклатуру — описания, заголовки и прочую терминологию, используемую на сайте. Вот почему необходимо говорить на языке пользователей, причем употреблять его правильно. Средство, используемое для этой цели, называется словарем нормативной лексики.
Нормализованный лексикон — это всего лишь набор стандартных терминов, используемых на сайте. Это еще одна область, где важно проводить исследование пользовательской аудитории. Самый эффективный путь разработки номенклатуры, которую пользователи сочтут естественной, — побеседовать с пользователями, чтобы понять, как они общаются. Создание (и применение) словаря нормативной лексики, который отражает язык ваших пользователей, является лучшим способом не допустить внутренний жаргон вашей фирмы на страницы сайта, где он лишь будет сбивать пользователей с толку.
Словари нормативной лексики помогут вам добиться непротиворечивости в организации контента. Независимо от того, сидят ли люди, ответственные за контент сайта, за соседними рабочими столами или находятся в офисах на разных континентах, словарь нормативной лексики послужит регламентирующим ресурсом, который гарантирует, что все они говорят на языке пользователей.
Более сложным подходом к нормализации лексикона является создание тезауруса. В отличие от простого списка одобренных терминов, тезаурус документирует также и альтернативные термины, имеющие широкое употребление, но не применяемые на сайте. Имея тезаурус, вы можете описать соответствие между одобренными терминами с одной стороны и профессиональным жаргоном, сокращениями, сленговыми терминами и аббревиатурами — с другой. Тезаурус может содержать и другие взаимосвязи между терминами, указывая более широкие, узкие или близкие термины. Документирование этих взаимосвязей дает вам полную картину всего спектра понятий, задействованных в контенте сайта, а это, в свою очередь, может подсказать вам новые подходы к построению архитектуры.
Наличие словаря нормативной лексики или тезауруса будет особенно кстати, если вы решите построить систему, включающую в себя метаданные. Термин «метаданные» просто означает «информация об информации» и касается структурированного подхода к описанию элементов контента.
Предположим, мы имеем дело со статьей о том, как последняя модель вашего продукта используется в пожарных частях. Метаданные об этой статье могут быть такими:
- Фамилия автора
- Дата размещения статьи
- Тип текста (например, статья или практическое исследование)
- Название продукта
- Тип продукта
- Сфера деятельности клиента (например, пожарная часть)
- Прочая информация (например, муниципальная организация или служба спасения)
Имея эту информацию, мы сможем рассмотреть целый спектр архитектурных подходов, что было бы затруднительно (а то и вовсе невозможно) в противном случае. Короче говоря, чем более подробной информацией о контенте сайта вы располагаете, тем большая гибкость предоставлена вам в плане структурирования этого контента. Если вдруг окажется, что служба спасения является прибыльным сектором рынка, в который могла бы устремиться ваша компания, наличие метаданных позволит вам на основе уже имеющегося контента быстро создать новый раздел сайта для удовлетворения потребностей этих пользователей.
Впрочем, создание технических систем для сбора и отслеживания этих метаданных будет бесполезным, если сами данные слабо согласованы. Вот здесь и приходит на помощь словарь нормативной лексики. Используя строго один термин для каждого самостоятельного понятия в составе контента, вы можете положиться на автоматические инструменты при определении взаимосвязей между элементами контента. Ваш сайт сможет динамически объединять страницы по конкретной теме, и все, что для этого необходимо, — просто быть последовательным в применении терминов в метаданных.
Кроме того, хорошие метаданные могут предоставить пользователю более быстрый и надежный способ поиска информации, чем тот, который обеспечивается элементарным полнотекстовым поиском. Поисковые машины могут быть весьма мощными, но при этом они, вообще говоря, очень и очень глупые: вы даете им строку символов — и они всего лишь ищут в точности такую же строку. Они не понимают ее смысла.
Можно сделать поисковую машину умнее, связав ее с тезаурусом и снабдив контент метаданными. При поиске непринятого на сайте термина она с помощью тезауруса сможет поставить в соответствие этому термину одобренный вариант; затем она проверит метаданные на наличие в них одобренного термина. Вместо сообщения о том, что строка не найдена, пользователь получит релевантные, хорошо сфокусированные результаты и, возможно, рекомендации по потенциально интересным смежным темам.
Роли в команде и процесс разработки
Состав документов, необходимых для описания структуры сайта — от конкретных деталей номенклатуры и метаданных до общей картины информационной архитектуры и конкретной организации взаимодействия, — может значительно варьироваться в зависимости от сложности проекта.
В проектах с большим объемом иерархически организованного контента эффективным способом документирования архитектуры могут оказаться простые многоуровневые списки. В некоторых случаях для отражения нюансов сложной архитектуры потребуются электронные таблицы и базы данных.
Однако самым главным инструментом документирования информационной архитектуры и проектирования взаимодействия является схема. Визуальное представление структуры — наиболее эффективный способ разобраться в ответвлениях, группах и взаимосвязях компонентов сайта. Структура веб-сайта по сути своей достаточно сложна, и ее словесное описание, вероятнее всего, просто никто не станет читать.
На заре существования Сети такие схемы назывались «картами сайта», однако это словосочетание используется также для обозначения конкретного средства навигации по сайту (которое подробно описывается в главе 6), поэтому, говоря об инструменте описания структуры сайта, сейчас лучше использовать термин архитектурная схема.
Эта схема вовсе не обязана документировать каждую ссылку на каждой странице сайта. На практике подобный уровень детализации в большинстве случаев только сбивает читателя с толку и заслоняет информацию, действительно необходимую команде разработчиков. Гораздо важнее документировать концептуальные связи: какие категории сгруппированы, а какие остаются сами по себе, как согласуются шаги в данной процедуре взаимодействия и т. п.
Техника, которую я создал для отражения структуры сайтов в схемах, называется Visual Vocabulary. С тех пор как в 2000 году я разместил ее в Сети, ее приняли в качестве рабочего инструмента информационные архитекторы и проектировщики взаимодействия во всем мире. Вы можете больше узнать о Visual Vocabulary, загрузив образцы схем и средства для их создания с моего веб-сайта Www.Jjg.Net/ia/visvocab/.
Visual Vocabulary — это техника для построения схемы любой архитектуры, от простейшей (вверху) до очень сложной (внизу).
Поскольку проектирование взаимодействия и информационная архитектура лишь недавно появились в сфере опыта взаимодействия, в командах веб-разработчиков по-прежнему, как правило, никто не отвечает за эти области явным образом. В свете этого неудивительно, что так мало вебсайтов могут похвастать продуманностью своей структуры.
Ответственность за структуру часто ложится на чьи-то плечи по умолчанию, а не в результате обдуманного решения. Выбор ответственного нередко совершается в зависимости от культуры организации или от природы проекта. На ранних этапах развития Сети создание и поддержка сайта обычно становились еще одной задачей имеющегося технического персонала. В организациях, где изменения происходят медленно (или ресурсы ограничены), такая ситуация, похоже, сохранилась и доныне. При разработке нагруженных контентом сайтов, а также в организациях, где присутствие в Сети изначально мыслилось как маркетинговая деятельность, ответственность за определение структуры сайта передавалась группе подготовки контента, издательской группе или отделу маркетинга. В организациях с развитой внутренней технической культурой или с руководством, получившим техническое образование, ответственность за структуру сайта обычно возлагалась на менеджера проекта по созданию веб-сайта.
Любой проект выиграет от наличия выделенного специалиста, отвечающего за вопросы структуры и работающего на полной ставке. Иногда такая должность называется «проектировщик взаимодействия», но чаще — «информационный архитектор». Пусть названия не вводят вас в заблуждение: хотя некоторые информационные архитекторы действительно специализируются на создании организационных схем и навигационных структур для контента сайтов, в большинстве случаев информационный архитектор имеет определенный опыт и в проектировании взаимодействия. На практике некоторые сотрудники на должностях информационных архитекторов в большей степени являются специалистами в области проектирования взаимодействия.
Возможно, в вашей компании не найдется достаточно работы для штатного информационного архитектора на полный рабочий день. Если ваши задачи по сопровождению веб-сайта по большей части сводятся к поддержке имеющегося контента в актуальном состоянии, если помимо полной переработки сайта раз в несколько лет никакая
Другая разработка не ведется, содержание информационного архитектора в штате вряд ли является разумной тратой денег. Однако если вы имеете дело с непрерывным потоком нового контента и должны постоянно расширять функциональные возможности сайта, то наличие в штате информационного архитектора позволит вам управлять этим процессом эффективно, то есть так, что будут удовлетворены потребности пользователей с одной стороны и достигнуты ваши стратегические цели с другой.
Не так важно, есть ли у вас отдельный специалист по вопросам структуры сайта, — важнее, чтобы решение этих вопросов было кому-то поручено. Ваш сайт будет иметь какую-то структуру независимо от того, целенаправленно вы ее спланировали или нет. Сайты, построенные по явным образом определенному структурному плану, как правило, реже требуют «капитального ремонта», позволяют своим владельцам добиться конкретных результатов и лучше удовлетворяют потребности пользователей.
электронное учебное пособие 
Для отправки комментария необходимо войти на сайт.