Некоторые ошибки при создании дашбордов в BI-системах и как их избежать с помощью UX

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

Однако, при создании дашборда очень легко допустить ошибку. Наша гипотеза: при проектировании дашбордов вы в любом случае занимаетесь проектированием пользовательского опыта (дизайном User Experience, UX), даже если не осознаете этого и не декларируете. Но без методологической основы, не используя апробированных практик, действуете интуитивно, что может оказаться довольно рискованно.
Цель этой статьи — описать основные ошибки, допускаемые при создании дашбордов и предложить способы, как их избежать за счет внедрения UX-методик. Цена ошибки в проектировании пользовательского опыта, зачастую, не просто создание не вполне удобного рабочего инструмента, а риск того, что систему перестанут развивать, так как не используют — пользователи не смотрят дашборды, так как те не способны помочь быстро и эффективно решить бизнес-задачи.
Вещи, связанные непосредственно с бизнес- и системным анализом, обеспечивающими создание дашбордов, в этой статье не рассматриваются, хотя, несомненно, являются крайне значимыми.

Базовая ошибка, определяющая все остальные…

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

Как избежать:

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

Структурная ошибка, когда у вас нет информационной архитектуры

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

Однако уже на этой стадии (а тем более, когда дашбордов становится действительно много) возникает вопрос: а каким образом строить систему навигации? Если отбросить методы «интуитивно» и «по аналогии с примером», останется корректный путь, которым многие идут неосознанно – создание информационной архитектуры.

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

Как избежать:

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

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

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

Способ построения – это тот вид схемы, который вы используете – классическое дерево, последовательности, матрица и т.д. Примеры иерархий: по организационной структуре, по направлениям деятельности, по бизнес-процессам, по KPI.

Ошибки при формировании бизнес-требований

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

Итак, ошибки:

• Дашборд не имеет цели (вроде бы, представленные данные нужны бизнесу – но для чего именно пользователь будет смотреть этот дашборд и как будет использовать полученную информацию, осталось «за кадром»);

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

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

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

Кстати, о том, как именно мы рекомендуем проектировать — можно почитать тут.

Ошибки в стадии, которую все проходят, но зачастую сами об этом не знают

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

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

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

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

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

• Недостаток контекста и связанности (как внешне, например, отсутствие визуализации места текущего дашборда в общей иерархии, так и внутренне, например, отсутствие группировки связанных показателей);

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

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

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

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

Ошибки на стадии проектирования визуального решения

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

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

• Недостаточно пустоты («воздуха») или, напротив, изобилие той же пустоты

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

• Плохой контраст (низкая читаемость) (не стоит оставлять это свойство дашборда в зависимости от субъективного взгляда; существуют вполне работающие методики измерения контраста – например, на основе Web Content Accessibility Guidelines 2.0, а также инструменты, автоматизирующие процесс такой оценки);

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

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

Если всё сделано правильно — мы получаем следующий пример; он демонстрирует ситуацию, когда вы прекрасно знаете, каким должен быть результат на самом деле. Однако, если представить, что дашборд проектируется с нуля – приведенные выше в тексте иллюстрации вполне могут отражать видение проектировщиков. А заказчик вполне может их согласовать и принять в эксплуатацию (почему — можно почитать тут: https://habr.com/ru/articles/830916/).

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