Зачем и как проектировать пользовательский опыт в B2B BI-проектах
В ходе внедрения проектов по аналитической отчетности одним из важных элементов является создание дашбордов, то есть информационных панелей, на которых будут выводится важные для компании данных.
К сожалению, далеко не всегда тот, кто заказывает дашборд, является его пользователем. Включение пользователей в процесс для проведения интервью при обследовании объекта автоматизации, конечно, помогает –, но отнюдь не гарантирует подлинно качественного результата. Качество — это соответствие требованиям, но многие вещи выносятся за скобки и подразумеваются. Например, предполагается, что курсор мыши при работе с дашбордом будет менять форму при наведении на интерактивный объект.
При этом такая важнейшая вещь как бизнес-ценность создаваемого решения может оказаться забыта. Кажется, что если многие квалифицированные и опытные люди с обеих сторон были задействованы для выбора данных и постановки задачи по их визуализации, то результат в виде дашборда просто не может быть плохим. Однако на самом деле риск создать невостребованный дашборд достаточно велик.
Для того, чтобы избежать ситуации, когда статистика по внедренному BI-решению демонстрирует, что пользователи не заходят на вроде бы такую важную и нужную экранную форму, необходимо учесть их цели, задачи и особенности — т.е. использовать UX-дизайн.
Проектирование UX (User Experience, пользовательского опыта) — не самая распространенная экспертиза в проектных командах, создающих или развивающих BI-системы. Такие специалисты на порядки чаще встречаются в продуктовых командах, работающих на широкую аудиторию. Это логично, так как на B2C рынке решения конкурируют между собой, пользователи не квалифицированы, их эмоции и действия крайне важны для метрик системы, по которым оценивается успешность или неуспешность работы (покупки, заказы, использование функций).
А вот в B2B бизнес-пользователь не может не использовать ПО, с которым он должен работать согласно должностным обязанностям, а низкая эффективность решения рабочих задач скорее станет основанием для его (пользователя) депремирования, чем для пересмотра подходов к пользовательскому интерфейсу и паттернам взаимодействия с системой. Поэтому ресурсные затраты в проектной команде на UX-дизайн выглядят избыточными — и такие работы не планируются (и, соответственно, не проводятся).
Часто компетенции UX и UI сливаются воедино — и воспринимаются как «красивое, но необязательное», особенно если визуальная кастомизация системы не предполагается.
Однако именно применение практик проектирования пользовательского опыта (UX) во многом позволяет гарантировать пользу создаваемого решения — за счет создания экранных форм от и для пользователей, а не от набора показателей. В свою очередь, преимущественно эстетическая и эргономическая составляющие (UI) могут применяться отдельно — или не применяться вовсе — решение может создаваться на базе платформы, включающей готовые визуальные решения для всех элементов дашбордов и их композиций.
При этом вовсе необязательно включать в команду особого специалиста; применение изложенной ниже методики вполне доступно бизнес-аналитику (просто попробуйте!). Для сложных, больших проектов, впрочем, не помешает хотя бы частично занятый UX-лид (в свою очередь, сориентированный на специфику проектной работы с B2B и BI). Его главной задачей будет разработка информационной архитектуры — комплексной конструкции, сводящей воедино цели, задачи, сценарии, роли — для создания удобной и лаконичной системы навигации, позволяющей пользователю легко перемещаться по разным, контекстно связанным дашбордам, последовательно решая задачи в рамках общей сложной бизнес-цели.
Итак, параллельно с обычной и понятной работой по обеспечению визуализации данных по формализованным требованиям, мы можем провести три шага проектирования пользовательского опыта работы с будущим дашбордом. Эта деятельность не является отдельной, ее результаты, включая промежуточные, могут оказать сильнейшее влияние, например, на уточнение состава показателей.
Шаг 1: определение бизнес-целей
Важнейший и определяющий шаг: исходя из объективных обстоятельств выполнения должностных обязанностей сотрудниками, выявить и зафиксировать бизнес-потребности и их атрибуты. Описание бизнес-целей может производиться следующим образом (здесь и далее ссылки на другие документы и конкретные пункты или разделы приводятся для иллюстрации — в публикации они никак не цитируются, однако, существуют в реальных процессах):
Составляющая | Описание | Пример | |
Роль | Role | Пользователь дашборда, включая его значимые для проектирования атрибуты (могут быть описаны отдельно) | Руководитель подразделения Наименование подразделения (см п. 3.1 Ролевой модели) |
Ситуация | Affair | Обстоятельства, в которых происходит работа с дашбордом, включая триггер, инициирующий эту работу | Еженедельно, понедельник, 9–00, оперативное совещание. Анализ начинается в случае, если общий индикатор KPI на сводном дашборде индицирует наличие проблем |
Потребность | Need | Общее описание необходимой пользователю информации (с отсылкой на документы, содержащие детализацию) | Выполнение плана подчиненными подразделениями (состав данных — см. п. 4.6 ФТ): проблемные элементы оргструктуры, периоды и структуры данных — для принятия управленческих решений |
Контекст | Context | Сопутствующие обстоятельства, значимые для аналитической визуализации (оборудование для работы, хронометраж, связанные цели и т.д.) | Дашборд демонстрируется на видео-стене (характеристики — см. п. 8.1 ФТ), управление показом осуществляется опосредованно, через ассистента, которому докладчик даёт голосовые указания. Замещаемая презентация — см. в папке Данные от ФЗ |
Помощь | Help | Возможные средства помочь пользователю достичь цели максимально быстро и просто | Визуальная индикация показателей и элементов структуры данных, где план не выполнен; ранжирование, последовательные переходы и контекстная детализация; отображение данных в динамике |
Англоязычная аббревиатура позволит легче запомнить эти составляющие (ranch / ранчо — объект, несомненно, полезный, по крайней мере для сельского хозяйства).
Одна или несколько бизнес-целей (в зависимости от конкретного дашборда) должны определяться в тесном взаимодействии с заказчиком и будущими пользователями. Ключевая особенность этого шага: максимально возможный уровень абстракции, обеспечение анализа и обсуждения без привязки к создаваемой или развиваемой BI-системе. Формат фиксации результата — приведенная выше таблица или простой текст.
Как мы видим, здесь уже можно заметить несомненные функциональные и нефункциональные требования, которые в ином случае могли быть не выявлены.
Шаг 2: определение бизнес-задач
Задачи — это основные вехи пути, который проходит пользователь от возникновения потребности в данных до достижения цели, сформулированной нами ранее. Каждая из задач имеет смысл, ее решение само по себе представляет определенную бизнес-ценность, но наиболее важно то, что именно в совокупности и последовательности приводят пользователя к его цели.
Путь от начала работы к цели через несколько задач может и даже должен иметь определенные ветвления и условия –, но об этом мы поговорим чуть ниже.
Задачи могут быть самыми разнообразными — и исчерпывающе описать все возможные для информационно-аналитических систем вряд ли возможно, однако предлагаем посмотреть на примеры, разбитые по основным типам:
Оперативные задачи | Аналитические задачи | Прогностические задачи |
Узнать значение показателя | Получить список связанных с выбранным показателей и приоритеты анализа | Узнать возможные последствия данного состояния показателя |
Узнать характер сопоставления с другой версией данных | Узнать тенденции по показателю (динамика) | Получить список показателей, на которые может быть оказано выбранным, приоритеты и величины для анализа |
Узнать величину разницы при сопоставлении | Сопоставить значения, отклонения разных показателей, периодов или элементов структуры данных | Определить индикаторы для отслеживания ситуации по выбранному показателю |
Получить рейтинг (сортировка выбранных элементов структуры по убыванию или возрастанию значения) | Узнать состояния показателей, объединенных общим процессом, принадлежностью | Оценить качество ранее сделанных прогнозов по выбранному показателю |
Узнать, на какие показатели или элементы структуры данных следует обратить внимание | Проанализировать дополнительные данные (ответственность, комментарии и т.д.) | Определить степень влияния выбранного показателя на выбранные показатели (цели) |
и т.д.
Задача конкретизируется показателем (или набором показателей), который (е) могут быть как жёстко заданными, так и выбираемыми, в том числе — автоматически и/или с определенными условиями (например — только имеющие негативное состояние отклонения к плану выбранного периода).
Задачи могут уточняться с помощью заданных атрибутов показателя, имеющих определенные нужные значения (например, можно уточнить период или один из элементов структуры данных, в т.ч. с условиями такой фильтрации данных).
При проектировании задач следует продолжать воспринимать систему как некий волшебный «черный ящик», стараясь максимально абстрагироваться от конкретных визуальных решений. Последние должны быть подчинены задачам, а не наоборот, как, к сожалению, иногда происходит (например, выбранная красивая и эффектная, но неподходящая для решаемых задач диаграмма).
Описывать задачи можно с помощью, например, такого шаблона:
Составляющая | Описание | Пример |
Роль | Наследуется от сформулированной цели | Руководитель подразделения Наименование подразделения (см п. 3.1 Ролевой модели) |
Условия | Если переход к решению задачи зависит от каких-либо событий или действий пользователя — это необходимо указать | Пользователь инициировал переход к дашборду со стартовой страницы системы, увидев негативное состояние индикатора KPI |
Результат | Завершение решения задачи и критерий успешности ее решения, он же — основная формулировка Задачи | Узнать, на какие показатели или элементы структуры данных следует обратить внимание |
Помощь | Возможные средства помочь пользователю решить задачу максимально быстро и просто | Визуальная индикация показателей и элементов структуры данных, где план не выполнен |
Вполне логичным представляется фиксация здесь же последствий решения задачи — однако, эти последствия для следующей задачи будут Условиями её реализации, так что дублирования информации можно избежать.
Эта связь наглядно показывает, что формулировка задач, по сути, промежуточный этап — между первым и третьим шагом.
Шаг 3: проектирование сценария работы с дашбордом
Сценарий — это итог проектирования пользовательского опыта работы с дашбордом, соединяющий цели и задачи в одну общую систему.
Если целей и задач немного, можно обойтись табличной или текстовой формой; однако, в большинстве случаев гораздо удобнее будет работать с визуальной конструкцией, используя любой удобный инструмент (лист бумаги и ручку, специальное ПО для построения схем и диаграмм, ПО для создания досок и соединения на них размещенных элементов).
Строить сценарии можно сверху вниз или слева направо — в зависимости от набора элементов или ваших предпочтений. Однако начинать стоит сразу и от начала (точка старта, например — вход пользователя в систему или переход на определенный ее экран) и от финала, расположив там все бизнес-цели, описанные нами на первом шаге процесса; здесь можно применить ранжирование, расставив цели в порядке убывания их значимости для пользователей или по какому-либо иному критерию.
Далее, в полученную схему необходимо встроить все сформулированные нами задачи, соединив их стрелками в той последовательности и с теми ветвлениями, как мы описали на шаге 2. Так мы получаем первую базовую схему сценария, которую можно проанализировать — и внести необходимые правки, если это понадобится.
Для детализации сценария мы используем новые элементы — действия пользователя: что он может или должен предпринять в каждый момент своего движения от начала к цели. Например, это может быть выбор периода для отображения, запрос детализации, фильтрация данных и т.д. Действия встраиваются между задачами, связываются с ними и между собой стрелками, дополняются узлами ветвления сценария, т.е. условиями — вопросами, при ответе на которых определяется дальнейший путь.
Итоговая схема может выглядеть, например, так:
Простой шаблон схемы сценария работы пользователя с дашбордом BI-системы
При соблюдении определенных условий (например, при индикации невыполнения плана по показателю), пользователь совершает дополнительное действие — и решается дополнительная задача.
Сценарий готов. Теперь у нас есть инструмент, позволяющий и построить действительно полезный и удобный дашборд (передаем сотруднику, ответственному за макет) — и проверить, не складываются ли ситуации, когда пользователь заходит в тупик, не имея возможности двигаться дальше к своей цели.
Расставленные приоритеты по целям могут быть использованы еще и для определения порядка размещения и долей площади экранного пространства дашборда. Действия говорят о том, какие управляющие элементы должны быть на экране в каждый данный момент сеанса работы с системой, а соединенные потоками сценария задачи гарантируют нам достижение целей в любом случае.
