Проектируем информационную архитектуру для e-commerce

Пришла пора подумать о роли информации в проектировании взаимодействия и ее архитектуре, особенностях и о том, как над ней работать.
Большую часть времени мы проектируем интерфейсы и исследуем их восприятие пользователями. Но при этом приходится учитывать, что большинство интерфейсов – не самоцель, а всего лишь посредники во взаимодействии между человеком и информацией. Поэтому самой информации, ее архитектуре, и восприятии человеком информации справедливо уделять существенное внимание. Сегодня мы поговорим об информационной архитектуре (далее — ИА).

Для нетерпеливых или тех, у кого мало времени: итоги вкратце и интересные ссылки в конце текста.

Начнем с очевидностей.
Очевидность #1: Информация нужна людям, чтобы принимать решения.
Очевидность #2: Информация может быть:

• Неполной – ее не хватает для удовлетворения информационных запросов пользователя;
• Некорректной – она не соответствует действительности;
• Избыточной – ее слишком много и/или она слишком сложна для восприятия пользователем;
• Нерелевантной – ее хватает, она корректна, достаточно проста для восприятия, но… бесполезна. В силу многих причин.

Очевидность #3: В любом из вышеперечисленных случаев вся работа над красотой, элегантностью и функциональностью интерфейсов представления информации теряют смысл. К примеру, при ложной информации идеальный интерфейс позволит пользователю быстро принять ложное решение.
Очевидность #4: Информация организована в некую структуру, которая имеет архитектуру.
Очевидность #5, итоговая: Если пользователь не находит нужную информацию или не воспринимает ее, заказчик или компания теряют прибыль.
В ходе работы UX-дизайнером в сфере ecommerce, я столкнулся с многообразием представлений об информационной архитектуре. Большей частью, ее воспринимают как один из несущественных аспектов проектирования взаимодействия. Как следствие, работе над информационной архитектурой не выделяется ни ресурсов, ни времени. В конечном итоге страдают пользователи, а компании теряют значительную долю доходов.

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

• Что такое информационная архитектура как явление, ее место в общем процессе проектирования взаимодействия;
• Какова специфика работы над информационной архитектурой для ecommerce;
• Как мы принимаем решения. Немного психологии;
• Как спроектировать информационную архитектуру на практике.

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

Что ж, приступим.

Зачем работать над информационной архитектурой?

Все совпадения с реальными персонажами, сервисами
и продуктами – случайны.

Что случилось с Иваном Владимировичем

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

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

Его выбор остановился на магазине «Eliteboose.com», о котором он слышал, что самый лучший выбор спиртного. С первого взгляда Ивана Владимировича впечатлил стильный и аккуратный дизайн сайта.

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

Он минут с 15 полистал предлагаемые продукты. К его разочарованию, рома в списке товаров не было. А предлагаемые подарки были далеки и от его нужд и от финансовых возможностей.

Уже сильно хотелось спать, но Иван Владимирович предпринял еще одну попытку, перейдя в другой пункт меню – «Для друзей». Среди многочисленного пива, водки и ликеров он наконец заметил и одинокий ром, притаившийся в конце списка. Бутыль Demo Anejo возможно была и неплохим выбором, но его смущало отсутствие выбора. Да и врял ли его шеф – руководитель департамента одного из ведущих банков страны — оценит подарок ценою всего лишь 13 долларов США.

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

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

А теперь в цифрах

В вышеуказанной истории налицо проблема с ИА, пусть и утрированная. У Eliteboose.com мы видим нечетко очерченные и наименованные категории, неочевидную классификацию товаров по категориям.

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

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

Адаптируем подход Джареда Спула (Jared Spool), который он использовал для расчета стоимости фрустрациипассажиров от проблем с юзабилити для транспортной компании Amtrak:

1. Вычисляем идеальный потенциальный доход – Iideal=a*b, где а и b – средний чек и кол-во потенциальных покупателей (лидов) в день
2. Получаем совокупный недополученный доход – Iforgone= Iideal -( Iideal *x/100), где x – доля отказов от покупки в целом
3. Узнаем стоимость ошибки в ИА – IAcost= Iforgone *y/100, $3500*20/100, где y – доля отказов по вине ИА.

Пример
Дано:

1. Средний чек заказа – $100;
2. кол-во потенциальных покупателей (лидов) в день – 50;
3. доля отказов от покупки – 70%;
4. из них, по вине ИА – 20%.

Считаем:

• Идеальный доход – $100*50=$5000 в день
• Совокупный недополученный доход –$5000-($5000*70/100)=$3500 в день
• Стоимость ошибки в ИА – $3500*20/100 = $700 в день

Делаем вывод:
Стоимость погрешностей в ИА — $700 в день, $21.000 в месяц или $252.000 дохода в год.

В случае с корпоративным ПО, потери в потраченном времени сотрудников будут ничуть не менее существенными.

Но прежде чем переходить к решению проблемы, резонно возникает следующий вопрос:
«А что мы понимаем под информационной архитектурой?»

Что такое информационная архитектура?

Возьмем среднестатистического сотрудника IT-предприятия и зададим вопрос: что такое информационная архитектура, и зачем она нужна? Среди ответов, которые мы получим, с вариациями могут быть следующие:

• «Это то, как организована информация? Где и что находится?»;
• «Что-то из юзабилити, для удобства пользования сайтом?»;
• «Точно, карта сайта! Да, конечно это полезно… Я, правда, ею не пользуюсь»;
• «Навигация, вроде… Ну, как по сайту перемещаться»;

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

Ричард Сол Вурмен

Отец информационной архитектуры, Ричард Сол Вурмен (Richard Saul Wurman), дает следующие определения информационной архитектуре:

• «Нахождение и организация паттернов, присущих данным. Для того, чтобы делать сложное – простым»;
• «Создание структуры или карты информации, чтобы позволить пользователям найти свой личный путь к знаниям»;
• «Возникающая в XXIом веке профессия, фокусирующаяся на ясности, понимании человека и науке организации информации».

Питер Морвиль и Луи Розенфельд в классической работе по ИА «Информационная архитектура в интернете» приводят целых четыре определения:

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

К Морвилю и Розенфельду присоединяется и Донна Спенсер, которая опирается на их определения в своей работе «Practical Guide to Information Architecture».

Несмотря на очень широкое понимание термина, было бы неплохо сформулировать определение и понимание ИА с точки зрения практика в проектировании взаимодействия.

Предлагаю следующее (которое не противоречило бы вышеуказанным подходам к пониманию ИА):
«ИА – это схема организации информации сайта»

Лаконично и весьма абстрактно. Измеряемые показатели качества ИА должны быть вполне конкретными:

1. Скорость нахождения информации (KPI: кол-во шагов для нахождения информации или затраченное время);
2. Качество найденной информации (KPI: качественный показатель соответствия информации ожиданиям пользователя, от 1 до 10).

Следует отметить, что ИА присутствует всегда, в любом приложении. Вопрос только в ее соответствии пониманию и потребностям пользователя.

Отсюда вопрос номер два:
Если она так важна, каким образом интегрировать работу над ИА в общий процесс проектирования взаимодействия?

Как работать над информационной архитектурой?

Мне близка точка зрения Дэна Саффера (Dan Saffer), который в своей работе «Designing for Interaction» рассматривает четыре практических подхода к проектированию взаимодействия, которые я привожу ниже. Как целесообразно работать над ИА в рамках каждого из подходов?

A. Ориентированный на пользователя (User-centered)

Идея: Пользователю виднее

Фокус: Цели и нужды пользователя

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

Где используется: крупные продуктовые компании, стартапы и digital-агентства.

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

Место ИА: Ввиду специфики подхода — основного акцента на исследованиях — можно спокойно пустить в ход львиную долю инструментов ИА (детальнее про инструментарий напишу отдельно) без потери времени и бюджета. Самая затратная часть – набор исследуемых пользователей – оплачивается в любом случае т.к. они уже и так принимают участие в UX-исследованиях и тестированиях. Проектирование ИА будет идти по классической схеме сверху вниз.

Подпроцесс создания ИА

Заметка: метод исследования «Карточная сортировка» — далеко не единственный. Отличный сравнительный обзор методов исследования ИА описан Джимом Россом тут.

B. Ориентированный на деятельность (Activity-centered)

Идея: Отталкиваемся от задач пользователя.

Фокус: Деятельность пользователя.

Суть подхода: Деятельность состоит из действий и решений. Дизайнер исследует действия, которые пользователь делает и решения, которые ему нужно принять. Базируется на исследовании, но в меньшей степени, чем предыдущий подход. После этого формирует список задач, стоящих перед пользователем, и, основываясь на них, предлагает решение.

Где используется: Как стартапы, так и аутсорсинговые компании.

Особенности: Ввиду фокуса на тактических задачах пользователя (Зарегистрироваться, ввести пароль, уточнить параметры поиска) есть риск, что дизайнер не увидит за деревьями леса (купить продукт).

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

Подпроцесс создания ИА

C. Дизайн системы (Systems design)

Идея: Пользователь – часть окружающей его системы.

Фокус: Окружение пользователя.

Суть подхода: преимущественно аналитический подход. Дизайнер должен уделять основное внимание контексту использования сайта. Определяются и видоизменяются состояния системы, окружение, цели деятельности системы относительно окружения и отклики системы на внешние возмущения.

Где используется: Digital-агентства, крупные продуктовые компании.

Особенности: Целесообразно использовать только в тех случаях, когда создается сложный продукт или система продуктов. Как правило, подход требует работы целой группы проектировщиков и дизайнеров.

Место ИА: непосредственное исследование и проектирование ИА здесь заменяется работой над архитектурой системы, с иным инструментарием и подходами.

D. «Гениальный» дизайн (Genius design)

Идея: Дизайнер – всему голова.

Фокус: Собственное понимание дизайна, эвристики дизайна (примеры можно посмотреть у Nielsen Norman Group).

Суть подхода: Дизайнер самостоятельно проектирует взаимодействие, базируясь на своем опыте и понимании вопроса и сверяясь с заданными эвристиками.

Где используется: аутсорсинговые компании и стартапы.

Особенности: Весь процесс проектирования и его итоги зависят от дизайнера на 100%.

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

Подпроцесс создания ИА

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

Подведем промежуточные итоги.

Итоги или вкратце для тех, кому лень

Что такое
Информационная архитектура (ИА) – это схема организации информации.

Как измеряется

1. Скорость нахождения информации;
2. Качество найденной информации.

Кто придумал
Ричард Сол Вурмен.

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

Что дальше
В следующей главе мы рассмотрим построения информационной архитектуры для электронной коммерции, и подводные камни этого процесса.

Что почитать
Если тема вас заинтересовала, рекомендую почитать следующие статьи:

• Краткая история ИА (англ.);
• Кейсы, предоставленные институтом информационной архитектуры (англ.);
• Являюсь ли я информационным архитектором? (PDF., англ.);
• Топ-10 ошибок в информационной архитектуре (англ.);
• Немного о методе карточной сортировки (англ.);
• Разница между ИА и навигацией (англ.).

Или, если сильно заинтересовала, предлагаю вашему вниманию следующие книги:

1. Информационная архитектура в Интернете (П.Морвиль и Л.Розенфельд, рус.) – одна из базовых книг по ИА, причем из тех немногих, которые были переведены на русский;
2. A Practical Guide to Information Architecture (D. Spencer, англ.) – тоже базовая, но я нашел только в англоязычном варианте;
3. Pervasive Information Architecture: Designing Cross-Channel User Experiences (A.Resmini, L.Rosati, англ.) – на мой взгляд, отличная книга для «продвинутого» изучения ИА.

 

Продолжим наше изучение информационной архитектуры и ее значение для электронной коммерции. В первой главемы вкратце ознакомились с понятием информационной архитектуры (далее — ИА), значением и подходами к работе над ней в рамках проектирования взаимодействия.
Теперь от вопроса «Зачем проектировать информационную архитектуру» перейдем к вопросу «Какие есть особенности ее проектирования?»

Итак: особенности работы с ИА в e-commerce и три аспекта ее проектирования:

• Принципы построения качественной ИА. Их применение в e-commerce;
• Шаблонные схемы ИА. Какие шаблоны лучше использовать;
• Процесс исследований ИА в e-commerce и их рентабельность.

Как водится, краткие итоги главы в конце поста.

Уверен, некоторые читатели задаются вопросом:
«Зачем писать про ИА в e-commerce отдельной статьей? В конце концов, сильно ли сфера e-commerce отличается от других?»
Будет честным с моей стороны ответить на этот вопрос прежде, чем переходить к шаблонам, принципам и исследованиям. Предлагаю вашему вниманию вторую порцию очевидностей.

В чем же заключается специфика e-commerce?

Как правило, в e-commerce пользователь в той или иной степени вовлечен в следующие процессы:

1. Ищет, где могут быть все товары, приблизительно ему подходящие (Поиск);
2. Ищет и читает информацию о товарах. На ее основании отбирает подходящие (Сортировка);
3. Сравнивает отобранные товары и делает окончательный выбор (Выбор);
4. Покупает товар (Покупка).

Пункты 1 и 2 могут встречаться в любых сферах интернет-деятельности: поиск свежих новостей, чтение ленты социальный сетей и т.д. Делать окончательный выбор от человека не требуется.

Пункты от 1 до 3 включительно, к примеру, могут встречаться при выборе человеком фотографии для публикации в соц.сетях (а какая лучше?) и написании статьи (а какой словесный оборот лучше выбрать?). Приходится делать выбор, что влечет за собой ментальное напряжение.

Но весь процесс от 1 до 4 пункта свойственен только e-commerce-проектам. В ходе этого процесса от пользователя требуется совершить несколько очевидных действий, которые могут иметь неочевидные последствия. Итак:

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

Наша задача: предоставить пользователю удобные инструменты для поиска, минимизируя его временные затраты.

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

Очевидность №2. Пользователю нужна информация
Сколько стоит? Когда и как доставят? А качественный ли товар? Как он выглядит? А если посмотреть сбоку? дают ли на него гарантию? А какую гарантию дают? А нет ли на него какой-то скидки, а что люди говорят… — лишь небольшая часть вопросов, которыми задается среднестатистический покупатель в процессе покупки. Существующий ответ на каждый из вопросов может быть жизненно важным и критичным для решения пользователя. Как следствие, отсутствие ответа с высокой долей вероятности приведет к уходу пользователя.

Наша задача: снабдить пользователя всей необходимой и качественной информацией в удобном виде и своевременно.

Наконец, когда пользователь нашел несколько подходящих продуктов, получил по ним всю интересующую его информацию, наступает критический момент:

Очевидность №3. Пользователю нужно совершить выбор
Порой выбор пользователя иррационален. Или настолько усложнен избытком опций, что пользователь откладывает процесс выбора до лучших времен (часто — уже не в этом магазине).

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

Наконец, решение принято. Наш пользователь уже в статусе покупателя должен решить финальную задачу – совершить покупку.

Очевидность №4. Пользователю нужно купить продукт
Просто заплатить деньги и купить. На данном этапе пользователь больше не хочет принимать решений и тратить время. Еще меньше он жаждет предоставлять свои данные и заполнять кучу форм.

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

В следующих двух частях этой главы мы рассмотрим как схемы построения информационной архитектуры, так и принципы ее построения.

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

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

По каким схемам мы можем снабжать пользователя информацией?

Шаблонные схемы информационной архитектуры, используемые в e-commerce

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

Линейная информационная архитектура

Обычный линейный процесс. Без вариантов и выборов.
Характерен при продаже одного продукта или услуги.

Пример: Google AdSense

Особенности:

1. Акцент на одном продукте;
2. Возможность выложить большой объем специализированной или маркетинговой информации;
3. «По дефолту» очевидный процесс покупки продукта, который может быть спроектирован исходя из специфики продукта;

 

Иерархия + База данных

Наиболее распространенный и легко кастомизируемый шаблон. Для каждой категории товаров и информации может быть своя схема предоставления информации (заголовок, изображение и цена – для товаров, заголовок и описание – для статьи, и т.д.).

Пример: Amazon

Особенности:

1. Стандартизированное описание категорий и продуктов;
2. Можно использовать разные схемы представления информации для разных категорий товаров (книги и цифровая музыка, к примеру);
3. Можно использовать большое количество не-продуктовых страниц (Новости, Статьи, промо-материалы, Видео).

 

Каталог

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

Классическая иерархия: Домашняя страница, страница категории, список продуктов, детали продукта.
Как правило, используется до трех уровней иерархии.

Пример: Google Play

Особенности:

1. Наивысшая структурированность подхода к выводу категорий и продуктов
2. Продукты должны быть однородными (только приложения, только мебель, только автомобили).

 

Тэги

Иерархия отсутствует, все товары организованы по тэгам.

Пример: Steam

Особенности:

1. Гибкость в организации и реорганизации схемы информационной архитектуры по мере расширения ассортимента продуктов.

 

Принципы ИА, и их применение для e-commerce

Я хотел бы обратить ваше внимание на замечательное изложение принципов построения информационной архитектуры, приведенной Д.Брауном. По большому счету, их можно использовать как чеклист при проверке любой существующей или проектирующейся ИА. Рассмотрим эти принципы в контексте e-commerce.

Принцип объективизации

Контент или продукт (в e-commerce) воспринимаем как объект, со своим жизненным циклом, свойствами и взаимодействием с пользователем.

Предположим, мы продаем книгу «Как построить дом за 80 дней. Инновационные технологии» (книга вымышленная).

Каков ее жизненный цикл? При одних и тех же внешних факторах (наши маркетинговые усилия, объективная востребованность) она не будет пользоваться особым спросом зимой, интерес к ней повысится весной, будет держаться летом, спадет к осени-зиме. По прошествии нескольких лет появятся новые технологии, и книга начнет терять свою актуальность.

Свойства книги: 255 страниц, с красивыми цветными иллюстрациями и схемами, в мягком переплете, она написана простым языком.

И наконец, ее поведение/взаимодействие. Она определенным образом взаимодействует с потенциальным покупателем. Создает образы, вызывает ассоциации и идеи, формирует некое представление о теме.

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

Принцип оптимального выбора

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

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

Для e-commerce логичным выводом из этого парадокса является следующий: было бы неплохо предоставлять пользователю на каждом шаге ограниченное количество опций (схожих продуктов или услуг). В идеале – не больше7.

Принцип раскрытия

На каждом этапе (шаге) даем пользователю представление о том, какую информацию он может найти, если будет «копать» дальше в этом направлении.

В большинстве случаев, мы не можем предоставить всей информации по всем продуктам пользователю на первом же шаге (в случае e-commerce – главной странице магазина). Но мы должны учесть, какая информация является критичной для нашего пользователя. И позволить пользователю понять, соответствует ли продукт его нуждам или нет.

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

Принцип наглядности

Описываем содержимое категорий путем демонстрации примера контента.

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

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

Поэтому, согласно данному принципу, помимо наименования или даже изображения категории, желательно там же указать несколько примеров продукции данной категории.

Принцип парадных дверей

Предполагаем, что, как минимум, половина посетителей будет заходить на сайт через страницы, отличные от главной.

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

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

Принцип множественной классификации

Предлагаем пользователям несколько различных схем классификации контента на сайте.

Схема классификации – наименования категорий продукции.

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

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

А теперь, как полагаете, выбрали ли остальные читатели ту же самую категорию, что и вы?

Принцип сфокусированной навигации

Не мешаем наименование и назначение навигационных элементов в процессе построения навигационных схем.

Каждый механизм навигации должен фокусироваться на своей цели. Глобальное меню – демонстрирует категории и подкатегории, фильтры позволяют отсортировать продукты в категории по нужным свойствам, верхнее менюпредоставляет доступ к персональным опциям покупателя (кабинет, отслеживание заказа, общение со службой поддержки) и так далее.

Принцип роста

Учитываем, что существующий на сегодня контент является лишь малой толикой контента будущего.

Проектируемая нами информационная архитектура должна иметь существенный запас прочности и масштабируемости. Если сегодня мы продаем только бумажные книги, далеко не факт, что завтра нам не придется продавать аудиокниги или электронные форматы. А послезавтра – устройства для чтения. Доказано Amazon.

Желательно предусмотреть рост содержимого в трех направлениях:

• Новые продукты в существующих категориях;
• Новые подкатегории и виды продуктов в существующих категориях;
• Новые категории.

 

Исследования при проектировании информационной архитектуры e-commerce

На сегодняшний день уже меньше приходится убеждать заинтересованные стороны (руководителя, заказчика, коллег) в необходимости проведения исследований при проектировании взаимодействия. И это плюс. Посему сначала я расскажу о подходе, потом — об аргументе для остальных в пользу проведения исследований (Годом раньше я бы рассказывал первым делом об аргументации исследований).

Часть исследований касается непосредственно проектирования информационной архитектуры. Глобальный обзор методов был сделан Джимом Россом (статья UXMatters), мы же рассмотрим один из исследовательских сценариев, который, на мой взгляд, является в большинстве случаев оптимальным (соотношение затраченного времени – полученной информации) при работе над e-commerce проектами.

Представляем себе, что мы работаем над сайтом мебельного магазина…

Исследование пользователей

На первом этапе исследования собираем информацию о целевой аудитории:

1. Этнографические детали (Google Analytics);
2. Поведение (Google Analytics for e-commerce);
3. Предпочтения (Опросы).

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

Пользователь. Представьте себе огромное полотно разнообразной информации о продукте: название, цена, рейтинг, условия доставки, изображения, видео, отзывы, рекомендации… Два вопроса: Какая информация для вас как для пользователя имеет максимальное значение при выборе продукта? И что будет, если вы ее не найдете или не заметите?

Проектировщик. Как получить информацию о приоритетах пользователя? Капитан Очевидность спешит на помощь – спросить у пользователей. Предлагаем ему список из информационных блоков и просим указать от одного до трех пунктов важной, по его мнению, информации. Достаточно опросить пользователей 20-30 для понимания общей картины.

После этапа сбора информации наступает этап генерации вводных данных для дальнейшей работы.

Как это может выглядеть на практике?
1. Создаем персоны по мотивам полученной информации о целевой аудитории (до трех персон);

Пример:

Ипполит Матвеевич.
52 года.
Регистратор ЗАГСа.
Коллекционер мебели производства мастера Гамбса.
Характер — необщительный.
Не женат.

2. Расписываем сценарии их поведения на сайте;
Пример:

3. По итогам опросов, формализуем предпочтения нашей целевой аудитории, представленной персоной Ипполита Матвеевича.
Пример (в порядке приоритетности):

1. Категория мебели (стулья);
2. Мастерская производства;
3. Цена.

Остальная информация нашу персону интересует мало.

После того, как мы, таким образом, получили все вводные данные о нашей целевой аудитории, переходим к следующему исследованию.

Открытая карточная сортировка

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

Пример:

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

Таким образом, тестируем как минимум 10 человек. Для начала этого количества вполне хватит. (Позже, при наличии свободных средств и времени, можно повысить точность исследования, увеличив количество опрашиваемых).

Сводим статистику, обобщаем и на выходе получаем следующий вариант:

На данном этапе нас это вполне устраивает, можем переходить к тестированию.

Tree testing

Наши пользователи в ходе предыдущего исследования уже сгенерировали некие категории. Теперь мы можем попросить следующую группу пользователей протестировать уже сложившуюся информационную архитектуру высокого уровня.

Делаем это с помощью задач и свернутой схемы информационной архитектуры.

Пример: Найдите, пожалуйста, на текущей схеме, где могут быть бриллианты мадам Петуховой.

Выберите сначала верную на ваш взгляд категорию, затем – подкатегорию.

На выходе также получаем статистику, которую с чистой совестью можно считать итогом данного раунда исследований.

Итоги исследований

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

Задачи у нас варьируются по критичности/приоритетности. Если многие пользователи не могут с третьего раза найти наиболее важный для них продукт или информацию – «что-то в консерватории надо подправить» (с).

Пример:
Задача 1. Найти стулья мастера Гамбса на сайте магазина.
Приоритетность – максимальная.
78% пользователей успешно выполнили;

Задача 2. Найти условия доставки стульев.
Приоритетность – средняя.
60% пользователей успешно выполнили;

Задача 3. Найти биографию мастера Гамбса.
Приоритетность – низкая.
40% пользователей успешно выполнили.

Возникают следующие вопросы: 78% в первом случае — это хорошо или плохо? А 40% — в третьем?
Чтобы ответить на эти вопросы хотя бы в первом приближении, попробуем оценить удовлетворительность результатов.

Подсчет рентабельности исследований

Предположим, гарнитур мастера Гамбса из 10 стульев стоит, скажем, $750.00.
Объем целевой аудитории, которая посетила сайт магазина в тот день, составляет 100 человек.
По данным tree testing исследования, только около 78% из желающих смогут его найти и, как следствие, купить.

Таким образом, недополученный потенциальный доход равен

(100*750)-(0,78*100*750)=$16.500/день

Ясное дело, что на практике довести показатель успешности нахождения продукта до 100% маловероятно, но минимизировать потери можно.

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

Следовательно, идем на второй раунд исследования и тестирования информационной архитектуры, только на сей раз с большим количеством участников и большим «арсеналом» методов исследования.

Замечание: сложности пользователей с решением задач ИА всегда нужно соотносить с затратами на проведение нового раунда исследований. Если 10% пользователей не могут найти статью 2011 года о биографии бабушки мастера Гамбса, это не повод проводить масштабную перестройку информационной архитектуры. Даже если это позволило бы дополнительно продать десяток гарнитур в год.

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

 

Что дальше?

В следующей главе мы рассмотрим, как пользователи себя ведут (шаблоны поведения), как они ищут информацию, делают выбор и принимают решение о покупке.

Что почитать?

Восемь принципов информационной архитектуры, Д.Браун (англ., PDF)
Сравнивая методы исследования информационной архитектуры, Д. Росс (англ.)
Эффективно упрощая навигацию, А. Карафиллис (англ.)
Exploring ecommerce information architecture (англ., курс обучения Lynda.com)