B2B UX: Информационная архитектура и проектирование обзорного экрана в BI-системе

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

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

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

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

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

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

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

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

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

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

   А как сформулировать бизнес-цель обзорного дашборда? Например, так:

   «Получить общее представление о состоянии процессов, характеризуемых данным набором показателей».

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

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

Не следует забывать еще и о контексте использования (не самая значимая, но всё же составляющая цели).

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

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

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

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

Итак, мы определились с целью дашборда. Следующий этап — это вы брать или скорее даже сконструировать соответствующие ей:

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

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

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

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

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

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

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

С помощью таких инструментов пользователь сможет получать информацию примерно следующего содержания:

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

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

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

Любое наше решение должно быть обосновано и аргументировано — и, конечно, не эстетическими соображениями, а результатами бизнес-анализа материалов.

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

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

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

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

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

Однако, и в пределах одной экранной формы (нашего обзорного дашборда) информационная архитектура является базисом построения:

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

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

• управления

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

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

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

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

Обратите внимание, что базовыми узлами схемы информационной архитектуры могут служить не только показатели.

На примерах тех же веб‑сайтов или корпоративных веб‑порталов мы можем увидеть самые разные подходы. Так, базовыми могут стать элементы оргструктуры, бизнес‑процессы, географические объекты и т. д. Подход диктуется спецификой объекта автоматизации и структурой данных и бизнес‑терминологии.

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

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

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

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

Компоновка

Есть некоторые методики построения композиции, используемые в изобразительных искусствах (правило «двух третей», правило «золотого сечения» и т. д.), применять которые можно и нужно, но с оговоркой: всё‑таки наш дашборд — это не арт‑объект.
Действительно, исследования подтверждают, что плохую композицию, лишенную гармонии, человек считывает подсознательно.

Однако, наша цель — это максимально эффективное предоставление информации и средств управления ею. Поэтому, как ни обидно будет художникам, сохраним приоритет за бизнес‑ценностью.

При этом следует обратить внимание на следующие аспекты компоновки:

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

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

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

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

Детали

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

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

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

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

  Универсальных практических советов тут, очевидно, быть не может; что же касается подходов, то важнее всего соблюдать системность. И — некоторые общие моменты:

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

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

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

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

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

Его задача – обеспечить эстетический аспект решения:

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

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

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

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

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

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

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

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

А что дальше?

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

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

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

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

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

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

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

Заключение

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

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

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