Для чего дизайнеру нужна информационная архитектура и что же она такое
Часть 1. Определение и основные понятия
При разработке продуктов любой величины важно делать их не только красивыми, но и понятными: логика их поведения должна быть угадываемой, сценарии продуманными, навигация предсказуемой и понятной. Все это мы обобщаем, называя информационной архитектурой, и в следующих двух частях я расскажу, как я понимаю, что это такое, и как можно применять эти знания в дизайне.
Читайте вторую часть: «Составляющие информационной архитектуры».
В сети можно найти очень много разнообразных определений термина «Информационная архитектура», каждое из них зависит от веяний времени, когда это определение появилось, и от специальности того, кто его вывел. В результате множественности этих определений и точек зрения, с которых можно подойти к объяснению процесса проектирования архитектуры, у многих дизайнеров долгое время держится ложное представление о том, что «Информационная архитектура — это карта сайта», или «Информационная архитектура — это про категории и карточную сортировку».
Я попыталась свести воедино информацию и определения из многих источников в попытке донести то понимание архитектуры, которое за время работы дизайнером сформировалось у меня и которое, я надеюсь, поможет выстроить логическую систему кому-нибудь еще.
Для начала обратимся к миру физических вещей. В каких случаях своей жизни мы сталкиваемся с информационной архитектурой и можем пострадать от ее непродуманности?
Когда обращаемся к алфавитным системам указателей, индексам и глоссарию в словарях и энциклопедиях:
Изучаем табло, указывающее, куда следовать пассажирам, в аэропорту:
Ищем сыр определенного сорта в супермаркете:
Выбираем себе ужин в меню ресторана, пробираясь через разделы и названия блюд:
С очень похожими объектами, задачами и проблемами мы сталкиваемся в мире цифровом.
Когда пытаемся найти нужное действие среди категорий, названий и функций, используемых в разных приложениях:
Или смотрим погоду на карте:
Или когда ищем тот самый свитер в интернет-магазине:
Во всех этих примерах именно от хорошей организации информации, адекватных названий и их представления зависит найдем ли мы то, что нужно, насколько быстро это произойдет и сколько проклятий будет произнесено в процессе.
Что же мы имеем в виду под информационной архитектурой, что она такое?
Я воспользуюсь комбинацией определений и примеров Эбби Коверт и Фиореллы Рицца в попытке донести то понимание архитектуры, которое сформировалось у меня.
Информационная архитектура — это способ, с помощью которого мы стараемся сделать так, чтобы некую информацию можно было легко найти и быстро понять.
Под информацией мы понимаем любые картинки, звуки, ощущения, текст, понятия, предметы, которые мы организуем каким-то образом, чтобы сделать эту информацию более понятной.
Все это происходит через правильное именование:
союзмультфильм)
и взаимосвязь групп информации, а также понимание аудитории, которая данной информацией пользуется, их потребностей и их языка:
Для более формального объяснения информационной архитектуры обычно используют понятия онтология, таксономия и хореография. Они только звучат страшно, а на самом деле значат фактически наименование, структура и взаимосвязь, или, если подробнее:
Онтология — это
Определение конкретных ЗНАЧЕНИЙ наших продуктов, услуг или действий.
Что мы имеем в виду, когда говорим то, что говорим. Иными словами, это терминология: названия, заголовки, лейблы, теги, пояснения.
Например,
я знаю, что у меня в шкафу три свитера и два пуловера. Но чтобы моя младшая сестра смогла принести мне нужный свитер, мне надо более точно обозначить, что же мне нужно (она не знает разницу между свитером и пуловером, и их в шкафу много). Для этого я могу назвать нужный предмет одежды «белый свитер без воротника с вышитым оленем» или просто «белый свитер», если все остальные кофты на этой полке других цветов.
Таким же образом и интернет-магазины могут давать очень конкретные названия товарам (на картинке слева) или более общие (как на картинке справа):
Какую систему названий выбрать, решаете вы, как дизайнер, опираясь на знание бизнеса своего заказчика и аудитории продукта. И эта система названий напрямую будет влиять на то, насколько быстро пользователь найдет нужное и какие впечатления у него останутся от сервиса.
Таксономия — это
Расположение наших (ранее обозначенных) значений в четко сформулированные группы или их СТРУКТУРА, которая помогает нам достичь определенной цели.
Иными словами, это классификация и иерархия объектов и понятий.
Например,
Все в том же шкафу, зная, что им буду пользоваться я и моя младшая сестра, я могу положить и свои и её теплые кофты на одну полку — если мне важно, чтобы мы обе могли быстро найти свитер, а не пробираться сквозь стопки футболок и штанов. Или я могу положить свои свитера на одну полку, а её на другую (чтобы сестра не схватила случайно мой свитер вместо своего), и при этом разбить их на группы по цвету — чтобы можно было быстро объяснить, какой именно свитер мне нужен и где его искать. Или же я могу разбить их на группы по времени года, чтобы на переднем плане оказывались только те, что подходят по погоде.
Если вернуться к примеру онлайн-магазинов, то разные магазины по-разному структурируют одни и те же сущности:
На какие группы разбить имеющуюся информацию также решает дизайнер, опираясь на знание аудитории и ее целей и, предпочтительно, тестируя затем свои решения с помощью КАРТОЧНОЙ СОРТИРОВКИ, про которую рекомендую прочитать в статье “Карточная сортировка. Пересортируй его полностью!” от Svetlana Jeltok.
Хореография — это
То, как значения и структура взаимосвязаны и взаимодействуют друг с другом. Как можно обеспечить четкий и непрерывный ПОТОК, путешествие пользователя по полученной структуре. К хореографии можно отнести систему навигации и поиска по доступной информации.
Например,
в магазинах IKEA есть этаж с товарами, разложенными по понятным покупателям категориям:
А есть этаж с шоурумом, где собраны целые комнаты, подающие товары в совсем ином контексте:
Таким образом IKEA удовлетворяет потребность нескольких режимов поиска: на этаж с подушками покупатель прийдет, точно зная, что ему нужно постельное белье и возможно зная, как оно выглядит, какой размер ему нужен и даже как называется комплект. А на этаж с шоурумом можно попасть совершенно случайно, не имея цели найти плед, но тем не менее влюбиться в комнату и сочетание этого пледа с постельным бельем и купить все сразу. Вот эти разные путешествия по магазину и его ассортименту — и есть хореография информации магазина.
Если из мира физического вернуться к миру цифровому, похожим образом поступает сайт Зара Хоум. Подобно икее, на ZaraHome есть товары, разложенные по категориям (как в сотнях других интернет-магазинов и витрин):
Но при этом зачастую в описании товара фотографии помогают представить товары в контексте так, что хочется сказать «заверните всё»:
И помимо каталога, есть специальные разделы Editorial и Inspiration, в которых можно посмотреть сервировки стола, красиво скомбинированное и заправленное постельное белье или собранные из товаров магазина комнаты:
Процесс работы над ИА
Когда мы начинаем работу над информационной архитектурой?
Элементы информационной архитектуры (точнее, то, что нам пригодится в последующем дизайне нашего приложения, продукта или сервиса), встречаются нам уже во время первой беседы с заказчиком:
Информация об аудитории:
О каких-то процессах, на которых будет строится будущий сервис:
Названия и термины, характерные для тематики этого сервиса:
Набор функций или целей, возможно примерная карта страниц или экранов:
Все это будет приниматься в расчет при разработке архитектуры.
И в течение всего процесса разработки мы продолжаем набирать элементы для будущей архитектуры:
- Когда беседуем с пользователями, мы узнаем: как они описывают понятия и какими словами их называют, какая модель поведения для них привычна — это то, что можно будет либо положить в основу сценария нашего приложения, либо от чего мы будем отталкиваться, пытаясь внести изменения в эту модель. Их цели, проблемы и страхи — это то, чем мы можем воспользоваться, определяя важность функций будущего приложения и вес различной информации в рамках одного экрана.
- Когда составляем карту пользовательского опыта и строим сценарии, мы строим пути, по которым наши пользователи будут двигаться в будущем сервисе, продумываем, какие действия им будут доступны на каждом этапе и какую информацию они смогут видеть в отдельный момент времени.
- Когда продумываем структуру сайта или приложения: какие экраны, в каком порядке, как взаимодействуют друг с другом.
- Когда продумываем взаимосвязи между сущностями сервиса и пользователями: роли, возможность общения, классификация информации, разбивка на категории.
- Когда решаем, какие элементы должны присутствовать на экране, какое действие для каждого экрана основное, а какие — вторичные.
Когда мы можем считать работу над архитектурой завершенной?
Я бы сказала, это зависит от того, в какой роли вы участвуете на проекте. Если вас пригласили на конкретный срок для конкретной задачи — то финиш будет достигнут тогда, когда вы внесли последние правки после последнего пользовательского тестирования. Или когда заказчик посчитал, что больше ему дизайнер на проекте не нужен и разработчики справятся дальше сами.
Если же вы работаете как продуктовый дизайнер, то эта работа не заканчивается никогда — всегда будут какие-то новые находки в результате регулярных тестирований с пользователями: что-то не так удобно, как могло бы быть, что-то люди используют неожиданным образом и вдруг необходимо поменять элементы, перестроить их взаимосвязь или что-то добавить. Когда нужно добавить новую функцию, работа начинается с нуля, но в рамках только одной этой функции.
Всегда ли работа над архитектурой предшествует фазе прототипирования?
Не всегда. Это часто зависит от срочности задачи, ее сложности и опытности дизайнера.
Например, если задача мелкая, скажем, нарисовать небольшую форму, продукт уже существующий и хорошо знакомый (предположим, я работаю над ним второй год), и я уже нарисовала десяток похожих форм за время своей деятельности, и времени у меня на эту задачу — не более двух дней. В такой ситуации никто не станет прорисовывать подробную схему взаимодействия элементов, расписывать типы информации и производить ворох документации, большая часть этого процесса происходит в голове дизайнера или в быстрых набросках на бумаге.
Но при этом, даже если мы работаем над небольшим кусочком экрана и за пол минуты решаем что, куда и как разместить в своей голове или на листочке, в этой работе всегда присутствуют элементы работы над архитектурой: перечислить, назвать, сгруппировать, связать группы воедино. Опыт и простота задачи просто сокращают время и усилия, затрачиваемые на этот путь.
А для начинающих дизайнеров я бы вообще повесила постер с этой фразой:
Перечислить;
Сгруппировать;
Связать группы воедино;
Пересмотреть тексты и названия.
Студенты очень часто не верят и начинают сразу рисовать экраны, не продумав до конца, что должно в них входить и каким образом это что-то может быть взаимосвязано.
Однако, и у опытных дизайнеров случаются моменты, когда нет возможности остановиться и разложить все по полочкам. Или не хватает сил на этом настоять. Как правило, это происходит, когда заказчик просит побыстрее показать какую-то картинку вместо скучных схем, вопросов и текста. Тогда случается, что мы подумали над парой экранов, но упустили глобальную навигацию. Или после нарисованных двадцати экранов в голову приходит мысль, как все совсем иначе структурировать. И в результате приходится много переделывать, порой и на живом продукте. Но, нет в мире идеала, и часто заказчик готов идти на такой шаг назад ради возможности продемонстрировать что-то функционирующее и красивое быстрее. Однако, несомненно, задачей дизайнера является как минимум предупредить о рисках такого подхода.
Есть ли разница в подходе при работе над абсолютно новым продуктом с нуля и работе над уже существующим продуктом?
При работе с нуля с одной стороны, больше контроля над ситуацией — мы собираем все с нуля, определяем, как надо, имеем возможность с самого начала сделать все правильно и продуманно, учесть максимум нюансов. С другой стороны, больше и неопределенности — больше решений, больше путей, по которым можно пойти.
При редизайне же все начинается с анализа текущей ситуации, инспекции существующей структуры, инвентаризации существующих объектов и сущностей. То есть, тут тоже есть две стороны медали — с одной стороны, уже есть более четкое понимание того, кто наша аудитория, какие их проблемы приложение призвано решать, куда бизнес хочет двигаться дальше, уже есть работающее приложение с устоявшимися моделями. С другой стороны, процесс сбора существующих проблем, инспектирования карты приложения, сценариев, существующих сущностей сам по себе может быть отдельным проектом в случае сложных систем, как, например, сайты университетов, крупные новостные сервисы или просто сложные и давно существующие энтерпрайз-приложения.
И чаще всего слова «поработать над архитектурой» всплывают при редизайнах, так как проблемы кроются именно в том, что при создании сервиса какие-то шаги по продумыванию архитектуры — скелета, на котором все прорастает, были пропущены.
Это все, что я хотела сказать про определение понятия архитектуры для дизайнеров. Надеюсь, для кого-то этот текст внесет ясность и поможет сформировать правильную картину мира :)
Какие методы и понятия входят в процесс работы над архитектурой, как ее документируют и как можно перейти от абстрактных результатов исследования к конкретным функциям, читайте следующую часть: «Составляющие информационной архитектуры».
Peace, love and rock-n-roll.
