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

Как же минимизировать эти риски? Для этого существуют определенные методы и средства; рассмотрим их — и определим путь создания действительно полезного обзорного дашборда для BI-системы.

Главный вопрос: «Чтобы что?»

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

Займемся реверс-инжинирингом приведенных выше примеров:

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

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

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

• Может быть, обзорный экран будет использоваться на устройствах с тач-скрином и небольшой диагональю?

• Или, напротив, будет задействован проектор и экран на стене?

• Предполагается ли активное взаимодействие пользователя с дашбордом – или это будет фон, находящийся за спиной докладчика? Все эти вопросы необходимо разрешить в ходе исследования объекта автоматизации и проектирования процессов использования системы «to be» — и зафиксировать ответы на них.

Что будем показывать?

• содержимое и

• элементы управления им.

• определить нужные разрезы,

• выбрать подходящие способы визуализации,

• скомпоновать всё получившееся в верном порядке и с правильными соотношениями занимаемой площади.

Информационная архитектура: как и зачем

• композиции содержимого,

• методов навигации,

• управления

• и всего, что составляет пользовательские интерфейс и опыт.

Компоновка

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

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

3. Кажется, что для обзорного экрана заголовок и место в навигации не так уж важны — это же обзор, вероятно, точка начала работы, пользователь прекрасно знает, где находится и что видит. Однако, обзорных экранов может быть несколько (например, в каждом разделе BI‑системы, либо для нескольких разных ролей пользователей); кроме того, даже на стартовом экране пользователь должен чётко понимать, на что он смотрит. Поэтому формулируем наименование обзорного экрана тщательно — и дополняем его необходимыми атрибутами (например, указанием момента, на который представлены данные на визуализации). Место же в навигационной иерархии обзорного экрана может дополнительно указать на то, что именно представлено на нём — и что находится под ним (экранные формы или подразделы). Здесь мы затрагиваем еще и тему управляющих элементов, как предназначенных для управления отображением (фильтрация, сортировка, возможно даже детализация), так и для переходов к другим экранам системы — ведь заголовок и соседние с ним элементы могут быть интерактивными.

4. Управление обзорным экраном BI‑системы крайне зависит от контекста применения этого экрана. В одном случае никаких взаимодействий с пользователем может не предусматриваться вовсе — если, например, обзорный экран демонстрируется на видеостене и используется исключительно «как есть». В других случаях, напротив, предполагается, что пользователь активно нажимает на элементы, привлекающие его внимание, получая необходимые детализации и разрезы. Очевидно, один из наиболее простых примеров управления — это переключение периода, когда пользователь по умолчанию видит значения и состояния показателей по итогам месяца, но при желании может переключить всю форму на отображение данных нарастающего итога по суткам с начала недели. Всё это следует предусмотреть на этапе формулировки цели, как мы помним, а здесь — проектировать экран с её, цели, учетом.

   Детали

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

   • «как сделать идентификацию бизнес‑термина очевидной, если его наименование — это три строки текста?»,

   • «как показать доли от общего в небольшой визуализации, если структура данных содержит 68 элементов?»,

   • «как сделать управление элементом дашборда, если по этому показателю доступно 23 различных разреза и заказчик не хочет их ранжировать по степени значимости?». Детали — это те атрибуты, визуальные компоненты и их расположение, которые исключают неверную трактовку данных, делают пользовательский путь к цели проще, быстрее и логичнее. Для каждого элемента обзорного дашборда, а также для их групп и общей композиции, необходимо всё это тщательно спроектировать.

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

   Эстетика и оформление

   В проектировании обзорного дашборда должен участвовать UI-дизайнер (именно участвовать, ибо все описанные выше работы он выполнить не сможет, а если сможет – то, видимо, наименование и содержание его роли в команде должно быть радикально пересмотрено).
   
   Его задача – обеспечить эстетический аспект решения:
   
   

   • дашборд должен быть визуально привлекательным,

   • данные должны легко считываться,

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

   Некоторые важные моменты:
   
   

   • Если у нас есть набор цветов, зафиксированный брендбуком — его надо соблюдать; в противном случае — использовать правила колористики, цветовое колесо и прочие инструменты.

   • Не забываем поддерживать в новом дашборде принятые для других дашбордов в системе (или в смежных системах) привязки цветов (например, красный цвет — негативный). Обязательно проверяем читаемость текста относительно фона про правилам W3C (например, с помощью http://www.snook.ca/technical/colour_contrast/colour.html — либо других схожих инструментов).

   • Многие дашборды страдают от недостатка пустого пространства на экране; хороший дизайнер это и так знает, однако, другие члены команды могут придерживаться противоположного мнения. Мы стараемся всё‑таки не превращать создание дашборда в соревнование «насколько много контента можно сюда запихнуть». Не всегда это возможно, однако, следует ориентироваться на диапазон в 10–12 самостоятельных блоков в пределах одного экрана. Большее количество усложняет восприятие информации в целом.

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

   А что дальше?

   Обзорный экран во многих случаях становится лишь точкой начала работы пользователя.
   

   Так, индикатор негативного состояния показателя должен вести дальше, к причинам, последствиям, деталям этого состояния.

   Да и без триггеров, обзорный экран на то и обзорный, что занимает особое место в навигации.

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

   И вот тут зачастую возникают проблемы: куда именно следует направить пользователя, кликнувшего на этот блок?

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

   Либо — тщательнейшая проработка бизнес‑сценариев для составления матрицы зависимостей желаемых переходов в зависимости от роли пользователя и конкретного состояния показателей или индикаторов данного блока.

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

   Заключение

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

   Многое зависит от конкретики. Тем и отличается сложность проектирования BI‑систем: начиная с требований на создание, скажем, дюжины дашбордов, можно с равной примерно вероятностью закончить как с той же дюжиной, так и с одним. Или двадцатью. И это почти не шутка.

   Необходимо тщательно изучать бизнес — и стараться максимально верно определить бизнес‑цели и задачи будущих пользователей. Только это в максимальной степени позволит вам создать полезное и востребованное решение.

   Источник: habr.com

   Остались вопросы? Пишите на data@korusconsulting.ru
   И подписывайтесь на наш телеграм-канал про аналитику и данные Analytics Now