Почему «качественный» дашборд не подходит бизнесу? Добавляем UX в BI-проекты

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

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

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

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

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

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

Однако BI-системы более сложны с точки зрения представлений проектировщика о том, как будущие пользователи будут работать с системой. Хотя сами данные, процессы их сбора и обработки ничем не отличаются.

Вспомните все неудачные, неинформативные и нечитаемые презентации, которые вам приходилось видеть. А ведь слайды – это, по сути, те же дашборды, когда на экран в том или ином виде транслируются данные. Нюансы (источники данных и алгоритмы их обработки) скрыты «под капотом». Напротив, вспомним примеры удачных визуализаций данных – хотя бы презентации продуктов компании Apple, которые проводил Стив Джобс. Один показатель и одно значение на гигантском экране – вроде бы не очень похоже на хороший дашборд? Однако, это нужная цифра, в нужный момент представленная нужным способом в чётко спроектированном контексте. А как бы выглядели его презентации, если бы их наполнили всеми имеющимися (и, очевидно, формально значимыми) показателями, значениями, визуализациями? Как такая разница повлияла бы на принятие решения зрителем?

Как же сделать эффективный дашборд? Использовать UX-дизайн.

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

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

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

Сам процесс проектирования можно разделить на несколько этапов.

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

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

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

Бизнес-цель крайне желательно согласовать с топ-менеджером (главным пользователем создаваемой или развиваемой BI-системы). Это будет базисом для дальнейшего проектирования.

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

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

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

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

1. Проектирование пользовательского опыта (UX) важно и нужно для B2B-проектов. Такие работы в плане проекта – не дань моде и не пустая трата ресурсов.
2. Исчерпывающий набор показателей и их атрибутов и ролевая модель доступа к этим данным – недостаточный исходный набор для создания полезного BI-решения.
3. В роли заказчика и основного потребителя результата работ по созданию или развитию информационно-аналитической системы постарайтесь сконцентрироваться на фиксации бизнес-целей и проверке их реализации, а не на требованиях к более полному набору данных для дашбордов. Если ваши сценарии работы достаточно сложны, попросите подготовить прототип с реалистичными данными. Это позволит заблаговременно оценить потенциальную пользу разрабатываемого решения и гарантировать удачный пользовательский опыт.
4. Если проектировать интерфейс, исходя из функций, а не из сценариев работы для конечных пользователей, то это может привести к снижению эффективности решения, автоматизации процессов сбора и обработки отчетных данных, а также неполному достижению бизнес-целей пользователями, постоянным потерям времени и другим проблемам.