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

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

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

Для того, чтобы избежать ситуации, когда статистика по внедренному 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-системы
Простой шаблон схемы сценария работы пользователя с дашбордом BI-системы

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

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

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

Комментарии (0)