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

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

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

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

Проектирование UX (User Experience, пользовательского опыта) – не самая распространенная экспертиза в проектных командах, создающих или развивающих BI-системы. Такие специалисты на порядки чаще встречаются в продуктовых командах, работающих на широкую аудиторию. Это логично, так как на B2C рынке решения конкурируют между собой, пользователи не квалифицированы, их эмоции и действия крайне важны для метрик системы, по которым оценивается успешность или неуспешность работы (покупки, заказы, использование функций).

А вот в B2B бизнес-пользователь не может не использовать ПО, с которым он должен работать согласно должностным обязанностям, а низкая эффективность решения рабочих задач скорее станет основанием для его (пользователя) депремирования, чем для пересмотра подходов к пользовательскому интерфейсу и паттернам взаимодействия с системой. Поэтому ресурсные затраты в проектной команде на UX-дизайн выглядят избыточными – и такие работы не планируются (и, соответственно, не проводятся).

Часто компетенции UX и UI сливаются воедино – и воспринимаются как «красивое, но необязательное», особенно если визуальная кастомизация системы не предполагается.

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

При этом вовсе необязательно включать в команду особого специалиста; применение изложенной ниже методики вполне доступно бизнес-аналитику (просто попробуйте!). Для сложных, больших проектов, впрочем, не помешает хотя бы частично занятый UX-лид (в свою очередь, сориентированный на специфику проектной работы с B2B и BI). Его главной задачей будет разработка информационной архитектуры – комплексной конструкции, сводящей воедино цели, задачи, сценарии, роли – для создания удобной и лаконичной системы навигации, позволяющей пользователю легко перемещаться по разным, контекстно связанным дашбордам, последовательно решая задачи в рамках общей сложной бизнес-цели.

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

Шаг 1: определение бизнес-целей

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

Англоязычная аббревиатура позволит легче запомнить эти составляющие (ranch / ранчо – объект, несомненно, полезный, по крайней мере для сельского хозяйства).

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

Как мы видим, здесь уже можно заметить несомненные функциональные и нефункциональные требования, которые в ином случае могли быть не выявлены.

Шаг 2: определение бизнес-задач

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

Путь от начала работы к цели через несколько задач может и даже должен иметь определенные ветвления и условия – но об этом мы поговорим чуть ниже.

Задачи могут быть самыми разнообразными – и исчерпывающе описать все возможные для информационно-аналитических систем вряд ли возможно, однако предлагаем посмотреть на примеры, разбитые по основным типам:

и т.д.

Задача конкретизируется показателем (или набором показателей), который(е) могут быть как жёстко заданными, так и выбираемыми, в том числе – автоматически и/или с определенными условиями (например – только имеющие негативное состояние отклонения к плану выбранного периода).

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

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

Описывать задачи можно с помощью, например, такого шаблона:

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

Эта связь наглядно показывает, что формулировка задач, по сути, промежуточный этап – между первым и третьим шагом.

Шаг 3: проектирование сценария работы с дашбордом

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

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

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

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

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

Итоговая схема может выглядеть, например, так:

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

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

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