Составляющие информационной архитектуры
Часть 2. Как дизайнеру использовать это в работе
При разработке продуктов любой величины важно делать их не только красивыми, но и понятными: логика их поведения должна быть угадываемой, сценарии продуманными, навигация предсказуемой и понятной. Все это мы обобщаем, называя информационной архитектурой, и в следующих двух частях я расскажу, как я понимаю, что это такое, и как можно применять эти знания в дизайне.
Первая часть: «Для чего нам нужна информационная архитектура и что же она такое».
Если вернуться к составляющим, из которых складывается архитектура
В фокусе оказываются:
- Схемы данных (какие есть в системе объекты, информация, ее типы):
2. Классификация этих данных:
Что нужно помнить про схемы классификации — по какому бы принципу вы ни организовывали информацию своего сервиса, этот способ должен помогать пользователям сервиса находить нужное быстрее, или же быстрее выполнять задачу, которую они пришли выполнить.
3. Структура этих данных:
Не буду подробно останавливаться на структурах, скажу лишь, что для дизайнеров эта часть надолго остается в простых и проблематично перекладываемых на практику определениях типа «линейная структура, «иерархическая структура», «матричная структура» и т.п. Ну структура. Ну иерархическая. А дальше-то что? А дальше никто никак не пытается применить это на практике. Если вам будет интересно углубиться в матчасть, есть прекрасная серия статей Павла Шерера «Дизайн данных», которая, на мой взгляд, передает как раз то, зачем нам может пригодиться осознание того, какую же структуру мы применили в своем сервисе.
4. Сценарии, схемы процессов, пути, по которым проходит пользователь:
5. Навигация по приложению или сайту:
6. Система поиска (поддерживаете ли вы все режимы поиска или какой-то один, и как).
Переход от набора данных исследования и идей к конкретному функционалу
Попробую продемонстрировать все это на реальном примере. Почему «попробую» — потому что на самом деле это все равно окажется присущий конкретно мне процесс мысли над одной специфической задачей. У вас процесс может выстраиваться в другом порядке или другими способами, и задача может требовать несколько других артефактов или схем, или действий.
Тут нет (к сожалению или к счастью) заданного протокола шагов разработки или прописанных для всех обязательных артефактов с обязательными атрибутами. Есть только методики, шаблоны в этих методиках и разные способы задокументировать мысль — равнозначно хорошие и подходящие каждый к своей ситуации.
Дополнительные материалы о способах задокументировать мысль:
Однако же, вне зависимости от подхода, образа мысли и ее скорости, неизменным в любой ситуации остается процесс:
Перечислить;
Сгруппировать;
Связать группы воедино;
Пересмотреть тексты и названия.
Посмотрим, что у нас есть перед началом фазы прототипирования или во время нее.
А на этот момент у нас есть набор интервью с пользователями, анализ этих интервью в виде оформленных персонажей, карт эмпатий или иных шаблонов, по которым вы раскидывали ваши находки:
И также оформленные карты путешествия пользователя. Для каждой группы пользователей или общая для всех групп:
На каждом проекте задачи очень разные: где-то более обширные, где-то весьма узкие. И разные аудитории — где-то, опять же, пользователи даже внутри одной группы крайне разношерстные (например, пользователи правительственных сервисов gov.uk — вся Великобритания), а у кого-то они вписываются в конкретные узкие роли и потому более сфокусированы (например, в рамках gov.uk есть сервис для юристов).
Оттого и карты путешествий у разных сервисов и их пользователей обладают разной степенью абстрактности: у кого-то возможно оказалось достаточно верхнего уровня «до / во время / после», у кого-то наоборот все имеет настолько четкий фокус, что в карте оказались фактически конкретные шаги взаимодействия с будущим приложением, а в идеях уже почти список функционала.
Для какого-то проекта имело смысл и нашлось время сделать как карту текущего опыта (то, как пользователи решают свои проблемы сейчас) так и карту идеального опыта (как они будут их решать с использованием будущего сервиса), а у кого-то это требовало столько вариаций этой карты, что команда ограничилась только текущим путешествием пользователей.
Мы можем продолжить наращивать информационную архитектуру сразу с карт путешествий пользователя — потому что по сути своей они есть какой-то верхнеуровневый сценарий, текущая ментальная модель пользователя (хотя на самом деле не всегда, зависит от степени абстрактности конкретно вашей карты опыта). В этом случае мы будем смотреть, какие более точечные сценарии могут образоваться внутри каждого шага (если этого не было уже сделано в процессе работы над путешествием пользователя). И уже потом наращивать на них необходимые для выполнения каких-то действий атрибуты.
Или же мы можем вернуться к записям пользовательских интервью и откопать в них все рассказанные истории, в которых присутствуют какие-то шаги (хотя часто это уже сделано в процессе работы над картой путешествия).
Для примера я возьму одну очень маленькую историю из интервью с жительницей Минска, относящейся к группе пользователей сервиса для внесения предложений по благоустройству и обсуждения этих предложений:
В этой истории на первый взгляд нет очевидного процесса, из которого мог бы получиться сценарий. Однако даже в таком небольшом тексте у нас есть главное — задача, относящаяся к теме сервиса, которая была как-то начата и как-то завершена — значит, ее все же можно разложить на шаги, которые можно вывести в виде последовательности и проанализировать каждый. Такой мини User Journey Map. Или ментальная модель — тут уж кому что ближе.
Под шагами можно выписывать возникшие мысли или идеи, или проблемы, которые мы видим, или какие-то условия, необходимые для осуществления данного шага. Примерно также как мы делаем в большом User Journey.
К этому моменту я уже хорошо себе представляю характеристики основных групп пользователей системы и могу предположить с достаточной долей вероятности, как та же история протекала бы для другого персонажа:
После этого я могу начать фантазировать о том, как эта же задача для обоих персонажей решалась бы с помощью будущего сервиса. И каким образом персонаж Олег мог бы прийти к такому же счастливому исходу, как и Марина. При этом, получающаяся у меня схема — не конечный user flow, а скорее еще одна форма прототипирования, только пока без рисования экранов, одним текстом и последовательностью действий:
С помощью подобных схем (и держа перед глазами свои user journey maps со списками идей и проблем) можно начать думать над структурой, логикой и скелетом, на котором будет прорастать будущий сервис. И можно начать собирать действия и атрибуты, необходимые для каждого шага — то есть, конкретные функции, объекты и их свойства. И отсюда же уже легче увидеть, какие примерно экраны нам понадобятся, какие связи будут между экранами, какие связи будут между отдельными объектами.
Чем больше историй получается рассмотреть на таком уровне, пытаясь предусмотреть максимум возможных «а что, если», тем меньше шансов, что приступив к рисованию экранов (или уже на этапе их тестирования с пользователями) вы зайдете в тупик.
В итоге у вас получится какая-то глобальная карта сценариев сервиса, или подробный user flow с дополнительными атрибутами. И по нему уже можно будет проверить:
- Все ли озвученные в User Journey Map проблемы можно решить с помощью данного flow? И если нет — чего для этого не хватает.
- Все ли основные задачи могут быть достигнуты?
- Если приложить к этим итоговым flow/ screen map/ scenario map / наброскам экранов (смотря в какой форме и к чему вы пришли) все рассказанные респондентами истории — смогли бы они завершиться с меньшими усилиями и более успешно?
Конечно, никто не запрещает сразу же начать рисовать экраны — все мы мыслим разными категориями и кому-то легче продумывать истории в более графичном формате. Однако эти экраны будут служить примерно той же цели — просмотреть последовательность действий, необходимые для какого-то шага данные, открытые вопросы. И, как правило, при рисовании экранов у нас больше шансов запутаться в ненужных пока деталях типа «где будет эта кнопка» или «как бы посимпатичнее отобразить карту» и упустить что-то нужное в основополагающей логике или наборе данных.
И еще раз повторюсь, что это только один из способов начать думать. И один из способов этот процесс задокументировать. С тем же успехом вы можете использовать майнд мэпы, флоу чарты, модели данных, сториборды — все, что вам покажется наиболее подходящим способом перечисления, группирования и продумывания взаимосвязей.
После того, как у вас сформировались основные сценарии, карты экранов, вы начали отрисовывать какие-то идеи, элементы и целые страницы, наступит момент, когда станет нужным задуматься над тем, как будет представлена навигация по всем этим страницам, элементам и взаимосвязям на экранах вашего сервиса.
Система навигации
Я говорю именно «система», а не просто «навигация», потому что под навигацией чаще всего имеют в виду меню сайта или приложения, в то время как при разработке нужно думать не только про меню, но и про ссылки, теги, кнопки, фильтры, сортировку, визуальную иерархию страниц — всё это оказывает непосредственное влияние на то, насколько сложно будет человеку понять, где он находится в данный момент и попасть из одного места в другое.
Так что для проектирования навигации недостаточно просто разместить меню в какой-то части экрана. Необходимо также предоставить пользователям варианты действий в нужном месте и в нужное время, чтобы они могли перемещаться по интерфейсу быстро и не задумываясь, и легко находить то, что им нужно.
Итак, какими способами может осуществляться навигация по сайту или приложению?
Первый тип навигации, который люди чаще всего используют и ищут глазами в первую очередь, — это глобальное меню. Оно показывает нам крупные разделы сайта или наиболее часто совершаемые действия приложения, и помогает охватить взглядом всю его структуру.
Глобальное меню может быть простым:
Или содержать дополнительные опции, например выпадающие меню с дополнительными вариантами навигации в каждом разделе:
По пространственному расположению меню может быть горизонтальным, как в предыдущих примерах, или вертикальным:
Помимо главного меню, в приложении могут присутствовать меню локальные — то есть подменю, которые мы можем увидеть, когда открываем какой-то раздел. Глобальное меню все еще присутствует, но локальное меню отображает, как структурирована информация в рамках одного раздела.
Пространственно локальное меню также может быть горизонтальным:
Или вертикальным:
Помимо глобального и локального меню к системе навигации мы относим также и хлебные крошки. Это путь из ссылок, которые показывают уровень, на котором мы находимся в структуре веб-сайта, чтобы мы не терялись.
Кроме того, мы можем помочь пользователю найти аналогичный контент и удержать его на сайте, показывая блоки с родственным контентом или связанными ссылками, которые обычно собираются автоматически на основе того, что сейчас просматривает пользователь: различные you also might be interested in, customers also viewed, related documents и т.п.
Или показывая действия, зависящие от контекста:
Также в самом тексте страницы могут быть контекстные ссылки, которые появляются, если читателю нужна дополнительная информация по теме:
Такие контекстные элементы и ссылки помогают пользователю понять, какую информацию можно найти на сайте, какие действия ему доступны, и куда двигаться дальше. Подобные элементы и меню можно показывать именно тогда, когда это нужно пользователю и там, где ему это больше всего нужно, и нет необходимости забивать глобальное меню навигации большим количеством дополнительных ссылок.
Также для размещения подробностей, которые не обязательно принадлежат главному меню, либо обширной карты меню, нередко используют футер сайта:
Одним из самых больших преимуществ использования разветвленных навигационных систем является то, что вы можете направлять пользователей по определенным путям, которые вы сами спроектировали. Так как не смотря на то, что ближе всего к сердцу мы принимаем цели пользователя, цели бизнеса не менее важны, и необходимо всегда иметь их в виду.
Поэтому, если нам важно, чтобы люди, скажем, регистрировались на сайте или покупали что-то определенное, то важно вовремя и в нужном месте обеспечить доступ к этим важным функциям. Вместо того, чтобы похоронить их в глубине структурных хитросплетений приложения или сайта, мы сделаем их видной частью своей навигационной системы.
Система поиска
К системе поиска мы также относим не только собственно строку поиска, но и категории, их понятность и структуру, фильтры и возможности сортировки, удобство навигации и то, как мы называем страницы. Насколько легко понять, где мы находимся в каждый конкретный момент, насколько быстро можно просканировать каждую страницу, насколько быстро можно понять, какие действия можно совершить на каждом экране.
Если говорить про собственно строку поиска
Можно выделить поиск глобальный и локальный.
Глобальный поиск позволяет нам искать примерно любую информацию по всему сервису, локальный же ограничен текущим разделом или страницей, на которой в данный момент находится пользователь.
Поиск может быть простым:
Или с дополнительными параметрами, позволяющим ввести любой свободный текст с тем, чтобы автоматически подстроиться под то, что пользователь имел в виду:
Или же поиск может быть расширенным и иметь целый набор дополнительных полей, позволяющих сузить масштаб поиска:
А иногда расширенный поиск может включать в себя целую систему поискового синтаксиса для продвинутых пользователей, который позволяет с клавиатуры в единственную строку поиска вводить сложные запросы:
Нахождение пути, схема поведения при поиске информации
Пользователи чаще всего демонстрируют поведение, способствующее поиску информации в одном из четырех режимов:
- Прицельный поиск;
- Исследование;
- Блуждание (найти то, не знаю что);
- Повторный поиск.
Прицельный поиск
Когда пользователь точно знает, что ищет, но нуждается в подсказке, где искать. Как правило, существует один правильный ответ на вопрос.
Несколько примеров запросов при прицельном поиске информации:
- Кто был режиссером фильма «Звездные войны»?
- Где лежит презентация для заказчика N, которую мы готовили к декабрьской конференции?
- Где находится «Террапицца»?
Заметьте, мы не говорим тут о поисковой строке, но в целом о запросе, который привел человека в наш сервис.
Этому режиму поиска содействуют элементы навигации, организация информации, разбивка на категории и страницы, алфавитные списки, фильтры, теги, сама строка поиска.
Исследование
Когда сам процесс поиска так же важен, как и его конечная цель, место назначения.
При этом типе запросы гораздо более открытые, чем при прицельном поиске. Когда люди сталкиваются с новой информацией, их информационный запрос эволюционирует, что превращает поиск в итеративный непрерывный процесс.
Этот процесс подобен собиранию ягод, когда мы переходим из одного источника в другой, собирая нагромождения информации по пути. По такому принципу построена, например, википедия.
Несколько примеров запросов при исследовательском типе поиска информации :
- Какую машину я должен купить?
- Куда мне отправиться в отпуск?
- Какой фильм я мог бы посмотреть сегодня вечером?
- В какой цветовой гамме я хочу видеть посуду, скатерти, технику, баночки и приборы на своей кухне?
Пользователь примерно знает, что искать, но не представляет, как.
Такому режиму поиска способствуют контекстные ссылки, подсказки терминов, позволяющие сузить круг поиска, модули с аналогичным контентом, возможность предпросмотра, тематические подборки.
Блуждание
Категория поиска, которая не начинается с конкретного запроса.
Люди не всегда ищут что-то определенное, не всегда знают, что искать или могут искать не то, что им на самом деле нужно. У них могут быть другие мотивы, такие как развлечься или убить время.
Примером такой схемы поведения могут служить проверка электронной почты или социальных сетей в ожидании прибытия автобуса.
Этому режиму поиска также способствуют подсказки, подборки похожего контента (привет, pinterest), возможность посмотреть детали, не уходя на другую страницу.
Повторный поиск
Пользователь ищет что-то, что уже когда-то находил или случайно проходил мимо, но не обязательно помнит, где это было и в какой ситуации.
Для адаптации к таким запросам приложения и сайты создают разделы с избранным, историей поиска, закладки или, например, сортировку элементов по дате создания и последнего открытия.
На самом деле, темы, входящие в понятие информационной архитектуры, не заканчиваются никогда, так как охватывают почти весь процесс разработки. Недаром про это написано много хороших книг. Тут я старалась привести основные понятия, представление о которых хорошо иметь дизайнеру. Дальше все зависит от вашего любопытства и желания выстроить свою собственную картину того, что значит информационная архитектура и с какой стороны к ней подступиться.
Исследуйте, чертите схемы, рисуйте — пытайтесь объяснить сложное простыми методами и навести порядок в каждом стогу сена, в котором потеряли иголку ваши проекты.
Peace, love and rock-n-roll (hug).
Большое спасибо моим коллегам Nikita Potapenko, Nastassia Shpakava, Alina Kravets, Nikita Zenchenko, которые помогли мне привести мысли к какому-то подобию порядка.
