![](https://habrastorage.org/getpro/habr/upload_files/831/38d/506/83138d5068684e88a273a0eb81c45377.png)
Дашборды – очень удобный инструмент для бизнеса. Информационная панель, позволяющая быстро получить данные о состоянии показателей, является незаменимым инструментом оперативного управления. Дашборды позволяют принимать решения, понимать, куда следует обратить внимание.
Однако, при создании дашборда очень легко допустить ошибку. Наша гипотеза: при проектировании дашбордов вы в любом случае занимаетесь проектированием пользовательского опыта (дизайном User Experience, UX), даже если не осознаете этого и не декларируете. Но без методологической основы, не используя апробированных практик, действуете интуитивно, что может оказаться довольно рискованно.
Цель этой статьи - описать основные ошибки, допускаемые при создании дашбордов и предложить способы, как их избежать за счет внедрения UX-методик. Цена ошибки в проектировании пользовательского опыта, зачастую, не просто создание не вполне удобного рабочего инструмента, а риск того, что систему перестанут развивать, так как не используют - пользователи не смотрят дашборды, так как те не способны помочь быстро и эффективно решить бизнес-задачи.
Вещи, связанные непосредственно с бизнес- и системным анализом, обеспечивающими создание дашбордов, в этой статье не рассматриваются, хотя, несомненно, являются крайне значимыми.
Базовая ошибка, определяющая все остальные…
… это: не читать эту и другие публикации, посвященные построению пользовательского опыта при создании и развитии BI-систем. Соответственно – не планировать и не производить работ по UX-дизайну, не развивать компетенции сотрудников и не ожидать таких работ, если вы – заказчик проекта.
Как избежать:
Статью вы уже читаете. И - мы рекомендуем следующее: в зависимости от масштаба системы (проекта) в команде должны быть люди, имеющие соответствующий уровень компетенций в области UX-дизайна. Эти компетенции могут дополнять квалификацию бизнес-аналитика или UI-дизайнера – или кого-либо еще, не обязательно наличие отдельных людей. Однако, чем больше дашбордов и решаемых системой задач, тем выше требуется уровень специалистов.
Структурная ошибка, когда у вас нет информационной архитектуры
Начнем с ошибки настолько же глобальной, насколько и опциональной (да, звучит парадоксально). Итак, что происходит, когда в вашей системе разработаны второй, третий и последующие дашборды? Появляется необходимость построения некоторой системы навигации, учитывающей роли пользователей (вряд ли ваша информация должна быть равным образом доступна всем?). В самом простом виде – это список из гиперссылок, каждая из которых позволяет открыть нужную экранную форму. Пока дашбордов немного, можно использовать что-то вроде набора закладок в верхней или боковой части экрана, с их помощью можно будет переключаться между дашбордами, не уходя со страницы.
Однако уже на этой стадии (а тем более, когда дашбордов становится действительно много) возникает вопрос: а каким образом строить систему навигации? Если отбросить методы «интуитивно» и «по аналогии с примером», останется корректный путь, которым многие идут неосознанно – создание информационной архитектуры.
Информационная архитектура – это система организации информации, позволяющая построить целостный пользовательский интерфейс для использования всех возможностей решения, включая и систему навигации, и управление отображаемым контентом; это модель связей сущностей, атрибутов, объектов, функций – в привязке к бизнес-ролям пользователей. Кстати, может оказаться полезной и в разработке – при проектировании логических моделей.
Как избежать:
если у вас более пяти дашбордов и есть некоторый план развития системы, рекомендуется заняться информационной архитектурой. Если у вас более десяти дашбордов, сделайте это обязательно.
Информационная архитектура может быть построена на самых разных принципах, главное – чтобы структура была понятна и привычна пользователям и при этом целостна, атомарна и способна к развитию в тех масштабах, что вы предполагаете в будущем.
Для построения информационной архитектуры необходимо выбрать способ и основную иерархию (можно и зачастую даже нужно использовать несколько одновременно).
Способ построения – это тот вид схемы, который вы используете – классическое дерево, последовательности, матрица и т.д. Примеры иерархий: по организационной структуре, по направлениям деятельности, по бизнес-процессам, по KPI.
Ошибки при формировании бизнес-требований
Основная работа по пректированию начинается с определения бизнес-целей (т.е. того, для чего дашборд существует) и бизнес-задач, которые дашборд (или дашборды) должны помочь решить пользователям. Если начинается, конечно. Сложившаяся практика и ограниченные ресурсы, к сожалению, зачастую влекут за собою простое решение – буквальное воплощение в дизайне дашборда функциональных требований, полученных от заказчика. В этом нет ничего плохого, разумеется; более того, это надежный путь успешно пройти приемочные испытания. Однако, за кадром остаются бизнес-ценность и удобство, эффективность, обеспечить которые может получиться разве что случайно.
Итак, ошибки:
Дашборд не имеет цели (вроде бы, представленные данные нужны бизнесу – но для чего именно пользователь будет смотреть этот дашборд и как будет использовать полученную информацию, осталось «за кадром»);
Дашборд создан не для пользователей (очень похожая на предыдущую ошибка, но возникающая вследствие недостаточного вовлечения пользователей в процесс сбора требований – или, если/когда пользователи недоступны по любым причинам, недостаточного изучения процессов, в которые должен имплементироваться ваш дашборд. Частным случаем может оказаться, например, отсутствие различий в отображении данных и управлении ими для разных ролей пользователей – или визуализация, не учитывающая устройства отображения);
Использованы неверные допущения о знаниях и навыках пользователя (следствие предыдущей ошибки, однако, может реализоваться и вполне самостоятельно, если, например, проектировщик просто не использует человеко-центрированных подходов – и судит о других по себе, используя в дашборде неочевидные заголовки, непривычные для большинства будущих пользователей элементы управления и паттерны взаимодействия с системой);
Фиксация на незначительных на данной стадии вопросах (крайне важный момент и очень частая ошибка: до фиксации целей, задач, проработки пользовательских сценариев, обсуждать с заказчиком и выбирать типы диаграмм, цвета оформления, вид кнопок и т.п. Это радикально увеличивает риски создания очень подходящего визуально решения, которое, тем не менее, полезным и востребованным не станет).
![Дашборд, при создании которого были допущены ошибки в области бизнес-требований Дашборд, при создании которого были допущены ошибки в области бизнес-требований](https://habrastorage.org/getpro/habr/upload_files/224/e93/a60/224e93a6015725f40d9719a1015443a9.png)
Кстати, о том, как именно мы рекомендуем проектировать - можно почитать тут.
Ошибки в стадии, которую все проходят, но зачастую сами об этом не знают
Первой и основной ошибкой является недостаточная обособленность этой стадии. Кажется, что всё проектирование в низкой степени визуальной точности можно сделать «в уме», походя, не тратя время на «бесполезные работы», не порождая дополнительных артефактов. Но совершенно не зря этой стадии уделяется максимум времени в учебных программах UX-дизайнеров, она определенно важна и значима. Именно здесь мы определяем, что именно должно отображаться на дашборде, как должно быть упорядочено и организовано, как должно управляться и т.д. Эти задачи должны решаться в точке схождения результатов бизнес-анализа и компетенций проектирования пользовательского опыта, с учетом специфики требований пользователей и контекста; если же они не решаются должным образом, то вполне возможно следующее:
Не проектируются сценарии использования (подробнее об этом можно почитать в публикации по ссылке выше; вкратце отметим, что отсутствие сценариев исключает гарантию достижения нужных целей пользователями при работе с дашбордом, зато делает вполне вероятными тупиковые ситуации, когда процесс работы пользователя останавливается где-то в середине пути, и что ему, пользователю, делать дальше для получения нужных сведений – решительно непонятно);
Не реализуются low fidelity этапы проектирования (эти этапы заключаются в проектировании дашборда с помощью условных областей экрана, когда проектировщик концентрируется на делении пространства и размещении необходимых элементов, а не на конечном визуальном решении. При этом сокращаются ресурсные затраты на итеративные изменения, а проработанность пользовательского опыта, напротив, заметно возрастает);
Нет фокуса внимания (на необходимой информации – с должным ранжированием и в нужном порядке, зависимом от контекста, включая и роль пользователя, и его действия по управлению дашбордом);
Попытка вместить слишком многое (когда дашборд превращается из информационной панели, решающей конкретные бизнес-задачи, в комплексное табло, для работы с которым необходимо тщательно концентрироваться на определенных областях экрана. Такие дашборды вполне имеют право на существование, но должны создаваться только для тех случаев, когда такой дизайн действительно оправдан);
Недостаток контекста и связанности (как внешне, например, отсутствие визуализации места текущего дашборда в общей иерархии, так и внутренне, например, отсутствие группировки связанных показателей);
Случайное расположение элементов (на самом деле, разумеется, в дашборде не должно быть ровным счетом ничего случайного – даже для показателей, имеющих равную значимость, можно найти способы упорядочивания и/или ранжирования – а то и не один);
Неоптимальная визуализация (когда избраны не подходящие для задач виды и свойства визуализаций, т.е. тип диаграммы, её настройки, текстовые атрибуты и т.д.; классический пример – отображение небольшого количества долей в целом не с помощью круговой/кольцевой диаграммы, а, скажем, соответствующего количества столбцов на оси Х).
![Дашборд с ошибками, допущенными в стадиях проектирования и низко детализированного макетирования (работа с пользовательскими требованиями) Дашборд с ошибками, допущенными в стадиях проектирования и низко детализированного макетирования (работа с пользовательскими требованиями)](https://habrastorage.org/getpro/habr/upload_files/51a/5d7/3db/51a5d73db6967ff222f2bada32493cdd.png)
Ошибка, которую можно допустить (или избежать) и на предыдущей, и на следующей стадиях
Плохая композиция (существует множество методик для расположения элементов в нужной области, как связанных с иерархией информации, так и базирующихся на гармонии и эстетике. Пренебрежение этими методиками, конечно, не фатально, но качество композиции определенно влияет на восприятие пользователем, следовательно, и на эффективность его работы).
Ошибки на стадии проектирования визуального решения
Эти ошибки совершаются скорее в сфере эстетики, но решение в духе «я – художник, я так вижу» для бизнес-решений не подходит. Поэтому за визуальным дизайнером должен «присматривать» UX-дизайнер (если эти роли не совещены в одном лице) для того, чтобы не допустить следующие ошибки:
Лишние декоративные элементы (да, иногда цветовые блоки и композиции, пиктограммы, элементы инфографики или даже фотоизображения оказываются нужны и востребованы, но только для решения задач пользователя, а не для эстетической привлекательности);
Недостаточно пустоты («воздуха») или, напротив, изобилие той же пустоты
Неверная цветовая схема (избыточное или недостаточное количество цветов, неверные цветовые ассоциации, когда, например, корпоративный красный цвет и негативный акцент на состоянии показателя вступают в некоторый конфликт);
Плохой контраст (низкая читаемость) (не стоит оставлять это свойство дашборда в зависимости от субъективного взгляда; существуют вполне работающие методики измерения контраста – например, на основе Web Content Accessibility Guidelines 2.0, а также инструменты, автоматизирующие процесс такой оценки);
Недостаток или избыток метаданных (зачастую бывает крайне сложно сократить методологически закрепленные наименования – и это задача, которую следует решать, но и забывать указать единицы измерения или иные атрибуты, конечно, не стоит).
Рассмотрев основные ошибки, приведем теперь краткое описание сценария работ, при котором их риск минимизируется. Это достигается привлечением к работам по проектированию дашбордов специалистов необходимого уровня (диапазон уровня соответствует диапазону сложности проектируемой системы или отдельного дашборда):
Стадия |
Содержание работ |
Уровень специалиста |
Подготовка (0) |
Включение UX-составляющей в состав работ в необходимой степени |
Осведомленный Руководитель |
Информационная архитектура (опционально) |
Проектирование / развитие информационной архитектуры решения |
UX-дизайнер (Middle – Senior-Architect) |
Бизнес-требования (1) |
Определение бизнес-целей Определение бизнес-задач |
UX-дизайнер (Junior - Middle) + Бизнес-аналитик |
Пользовательские требования (2) |
Разработка пользовательских сценариев Проектирование экранных форм (low fidelity макеты и прототипы) |
UX-дизайнер (Junior - Middle) + Бизнес-аналитик |
Требования к реализации (3) |
Постановка задачи на макетирование |
UX-дизайнер (Junior - Middle) |
Разработка альбома макетов / прототипа системы |
UI-дизайнер (если есть отдельная роль – или тот, кто выполняет эти функции) |
|
Пост-проектный аудит |
Анализ, обобщение итогов реализации, обобщение практики |
UX-дизайнер (Senior-Architect) |
Если всё сделано правильно - мы получаем следующий пример; он демонстрирует ситуацию, когда вы прекрасно знаете, каким должен быть результат на самом деле. Однако, если представить, что дашборд проектируется с нуля – приведенные выше в тексте иллюстрации вполне могут отражать видение проектировщиков. А заказчик вполне может их согласовать и принять в эксплуатацию (почему - можно почитать тут: https://habr.com/ru/articles/830916/).
![Пример корректно спроектированного дашборда Пример корректно спроектированного дашборда](https://habrastorage.org/getpro/habr/upload_files/0bf/901/2de/0bf9012de370b2233a1033360484d8df.png)
Бонус для тех, кто дочитал до конца. Всё вышеизложенное справедливо не только для дашбордов в BI-системах, но и для слайдов презентаций, если они отображают данные и призваны помочь достичь какой-либо бизнес-цели. Таким образом, очевидно, поле повышения эффективности становится еще шире, а поводов задуматься – больше, правда?