Корпоративная навигация: методологии проектирования для сотрудничества с заинтересованными сторонами

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

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

«Едя слона, ешьте по одному кусочку за раз». - Крейтон Уильямс Абрамс мл.

О системах проектирования корпоративной навигации

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

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

Навигация — это просто «навигация»

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

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

Методология совместной работы над дизайном навигации

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

1. Стартовая встреча с заинтересованными сторонами

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

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

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

2. Мозговой штурм «Голубое небо»

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

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

Чтобы начать этот процесс мозгового штурма, начните с нескольких вопросов:

1. Если бы вам нужно было прыгнуть вперед на 5 или 10 лет вперед без каких-либо ограничений или препятствий, что бы вы хотели увидеть в дизайне будущего?
2. Были ли у вас какие-нибудь идеи — неважно, простые они или сложные, — но не было возможности воплотить их в жизнь?
3. Если бы вы были генеральным директором этой компании, как бы вы поступили в этой ситуации?
4. Видите ли вы какие-либо потребности рынка, которые могло бы удовлетворить это приложение?

Может показаться, что такой подход откроет «банку с червями», но пока все понимают сценарий «голубого неба», великие дела могут произойти. Попробуйте!

3. Болевые точки и выявление проблем

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

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

Эти вопросы помогут сдвинуть дело с мертвой точки и выявить болевые точки и проблемы:

1. На что больше всего жалуются пользователи?
2. Используете ли вы какие-либо службы (такие как аналитика веб-трафика или отслеживание кликов), отслеживающие поведение пользователей в системе?
3. Есть ли области корпоративной системы, которые редко используются, и вы не можете объяснить, почему?
4. Если бы вы могли что-то изменить в этом приложении, что бы это было?

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

4. Диаграммы сходства

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

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

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

На сеансах построения диаграмм близости заинтересованных сторон задавайте такие вопросы:

1. Какие функции или контент кажутся связанными друг с другом?
2. Пытаются ли пользователи выполнить определенные действия, которые было бы проще выполнять последовательно?
3. Существуют ли какие-либо избыточные возможности, которые можно было бы легко объединить или упростить?
4. Есть ли возможность сопоставить идеи голубого неба с существующими болевыми точками или проблемами?

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

5. Логическая реорганизация

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

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

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

1. Теперь, когда пользователь «здесь», что еще он может сделать?
2. Каково следующее логическое действие пользователя в этом сценарии?
3. Упускаем ли мы какие-либо возможности решить проблему пользователя с этой точки зрения?
4. Существуют ли в другом месте функции или контент, которые могут быть полезны в этом сценарии?

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

6. Иерархия

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

Предупреждение!

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

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

Используйте методологию, представленную до сих пор, и отбросьте этот опасный подход. Эти вопросы могут помочь облегчить беседу с заинтересованными сторонами:

1. Как связаны эти аффинити-группы и почему они связаны?
2. Есть ли какие-либо зависимости между аффинити-группами, которые нам необходимо признать?
3. Смогут ли пользователи выполнить задачу, не переходя в другую область системы?
4. Существуют ли традиционные иерархии, знакомые пользователям из других отраслей или моделей обслуживания, которые можно использовать в качестве эталона?

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

7. Номенклатура и параметры

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

Номенклатура, или маркировка, является важным элементом дизайна навигации по трем основным причинам: (а) номенклатура напрямую связана с SEO (поисковая оптимизация), поскольку поисковые системы в первую очередь ищут контент по ключевым словам; (b) использование надлежащей терминологии в качестве механизма поиска поможет пользователям найти то, что они ищут, выступая в качестве цифрового «ориентира»; и (c) смарт-метки могут привести пользователей к области системы, которая может быть недоступна с основной целевой страницы или домашней страницы. Возможность поиска определяется механизмами поиска пути, такими как метки. Если ярлык вводит в заблуждение или не интуитивно понятен, пользователь может вообще не щелкнуть по нему.

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

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

1. Что пользователи чаще всего ищут при посещении?
2. Трудно ли найти какой-либо контент или функции? Почему их трудно найти?
3. Существуют ли отраслевые термины или жаргон, которые могут быть незнакомы некоторым пользователям, что затрудняет им поиск того, что они ищут?
4. Как мы можем выбрать лейблы, которые являются традиционными или мейнстримными?

Как упоминалось выше, существует множество различных методов, которые можно использовать для проверки номенклатуры, таких как сортировка карточек, A/B-тестирование и объектно-ориентированный UX (OOUX). При работе с высокотехнологичной корпоративной системой с большим количеством отраслевого жаргона рассмотрите возможность создания контролируемого словаря или внутрисистемного глоссария для справки пользователей.

8. Интеграция с процессом проектирования взаимодействия с пользователем

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

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

«Если вы построите его, [они] придут». - Поле мечты, 1989.

Суть

Разработка корпоративной навигационной системы — непростая задача. Однако использование знаний заинтересованных сторон сделает эти усилия управляемыми.

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