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

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

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

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

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

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

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

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

Как можно себе представить, все эти факторы - задержка на линии, неполные или неверные ответы - оказывали крайне отрицательное воздействие на клиентов, нанося их верности брэнду пусть неизмеримый, но реальный ущерб.

Влияние этих трудностей на персонал службы поддержки также обходилось очень дорого. И без того немалая стоимость обучения возросла до $10 000 за каждого работника - поразительно, если учесть, что он зарабатывал всего $10 в час. Более того, текучесть кадров составляла 25% , и это означало, что даже с учетом дорогостоящего обучения люди находили работу в ближайшем ресторане быстрого питания, которая была сравнима по оплате и приносила большее удовлетворение. Все равно, чем заниматься, только бы не иметь дела с этой ужасной интрасетью!

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

После этого они обратились к нам за помощью в разработке новой информационной структуры. Мы помогли им, применив ряд средств:

• Вместе с ними мы сократили объем содержимого, который пользователям приходилось просматривать, а компании управлять, выделив то, что относилось к избыточному, устаревшему и тривиальному содержимому (redundant, outdated, trivial - ROT). Мы разработали образ действия и процедуры, уменьшающие долю ROT в момент первоначального создания содержимого, и помогали выявлять и отсеивать его на протяжении всего жизненного цикла сайта.

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

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

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

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

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


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



Новости за месяц

  • Ноябрь
    2019
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс