У меня есть задача — сделать стандартный формат для графиков типа «План-Факт». Основная загвоздка произошла для графиков, когда нужно показать как значения плана и факта менялись во времени. Я придумал показывать факт линией, а план заливкой (ареа чартом), но это вызвало разночтение у моих коллег. Тогда я решил провести опрос в канале, и выяснилось, как думают читатели.

Опрос в канале

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

Понимание задачи

В компании часто выставляются плановые значения метрик. Их нужно сравнивать с фактическими или прогнозными значениями.

У нас чаще всего следят за значением на определённый момент времени, а не накопительно. То есть важнее всего значение на последнюю дату, а не за сумму всех дат. Однако важно понимать выполнялись ли планы за предыдущие периоды, так как план по-сути являлся прогнозом, который мы сделали раньше и важно понимать насколько точно мы его делаем. Поэтому нужно смотреть и планы, и факт в динамике и отчетливо видеть их динамику. Если будет подсветка в какие даты не выполняется план — хорошо, но не критично. Чаще всего план — это положительное число, факт может быть как положительным, так и отрицательным.

График будет использоваться в разных дашбордах, поэтому чем универсальнее получится решение, тем лучше. Либо нужно сделать набор правил под разные задачи. Нужно разработать набор графиков: большой график во времени план/факт, график отклонения план/факт, спарклайны план/факт во времени, сравнение план/факт по разным разрезам, фактоид план/факт. Нужно, чтобы эти графики были «срифмованы» между собой и с остальными графиками темплейта. Обычные графики фактов, если нет установленного плана — это линии.

Данные для графиков хранятся в формате «дата | значение факта | значение плана». Чем проще и надежнее будет реализация в Табло, тем лучше.

Возможные решения

Не найдя best practice по этому вопросу и не получив каких-то научных обоснований от коллег по цеху, решил подойти к задаче методом перебора решений.

Часть графиков придумал сам, часть посоветовали коллеги и читатели блога. Варианты:
— Линия факт — Ареа план
— Линия факт — Бары план
— Линия факт — Засечки план
— Бары факт — Засечки план
— Ареа факт — Линия план
— Линия факт — Линия план
— Линия факт — Линия план + заливка между линиями
— Линия факт — Ареа план + заливка между линиями

Дисклеймер
В основном делал упор именно на разработку таймсерий. На остальные графики уделял меньше внимания, фактоиды совсем не делал. Цветовое кодирование тоже пока условное и не финальное. Ещё не докручивал подписи для самих графиков — так как важна последняя дата, то на неё ещё можно будет сделать акцент на самих графиках. Эти вещи докручу отдельно.

Линия факт — Ареа план

Мой исходный вариант. Больше всего в нём мне нравится, что линия остается фактом, как и обычные графики, где нет плана.

Плюсы:
— Срифмован с остальными графиками, для которых нет плана. Они просто линии, а тут мы добавляем «фон в виде» плана.
— Физично отображает выражение «факт идёт выше плана». План как гора на фоне, которую мы хотим достичь, факт выше «горы» или «ниже».
— Легко считывается динамика плана и факта по отдельности.
— Легко можно продолжить рисовать прогноз линией другого цвета.
— Легко реализуется и масштабируется в Табло.
— Можно заменять план на другие форматы «фона» — прошлый год, среднее по рынку и т. п.

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

Линия факт — Бары план

Очень похож на предыдущие график, по-сути просто делаем дискретным ареа. Поэтому все те же самые плюсы-минусы, но есть и дополнительные:

Плюсы:
— Можно подсвечивать конкретные даты по выполнению плана.

Минусы:
— «Рябит» малёк, когда много дат.
— Техническая заморочка с шириной баров при изменении скейла (Табло оно иногда такое Таблё).

Линия факт — Засечки план

Плюсы:
— Классно «зарифмован» основной график и график отклонений.
— Может работать с отрицательным планом.

Минусы:
— «Рябит», когда много дат.
— Настройка ширины тиков только ручная и будет плыть для разной ширины экрана.
— Хуже считывается сама линия плана.

Бары факт — Засечки план

Пожалуй, самый привычный формат. По сути, буллет-чарт, поставленный на бок, будет привычен многим пользователям.

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

Минусы:
— «Рябит» малёк, когда много дат или спарклайны.
— Настройка ширины тиков только ручная и будет плыть для разной ширины экрана.

Ареа факт — Линия план

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

Плюсы:
— «Зарифмован» с буллет-чартами, так как тоже заполняется как прогресс-бар.
— Довольно классический и понятный формат.

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

Линия факт — Линия план

На мой вкус самый беззубый вариант из всех. Вроде просто, но контраст между планом и фактом маленький и никаких особо преимуществ нет.

Плюсы:
— Просто.
— Хорошо считывать отдельно динамику плана и факта.

Минусы:
— Сложно отслеживать положение линий относительно друг-друга.

Такой вариант, кстати, предлагает стандарт IBCS, но с отметками в виде заполненных и не заполненных точек. Что-то как-то не айс. Для спарклайнов точно не подойдет.

Линия факт — Линия план + заливка между линиями

Этот вариант предложил один из читателей канала и показал вот такую ссылку на Натана Яу. Вообще вариант прикольный, но мне лично, очень сложно тут считывать само значение плана.

Плюсы:
— Аккуратный, мало чернил. Классно смотрится спраклайном.
— Акцент на «хорошие» и «плохие» даты.

Минусы:
— Сложно отследить линию плана из-за «перекручивания».
— Чтобы сделать «линию» плана, которая очерчивает область заливки, используется неприятный лайфхак в Табло.

Линия факт — Ареа план + заливка между линиями

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

Плюсы:
— Довольно хорошо считывается.
— Акцент на «хорошие» и «плохие» даты.
— «Зарифмован» с графиком отклонений.
— «Зарифмован» с обычными графиками фактов.
— «Зарифмован» с буллет-чартами.

Минусы:
— Нормально считывается динамика линии плана, но не идеально.

Анализ

Я сделал все эти скрины и пошёл советоваться к эксперту по графикам — Саше Богачеву. Он согласился со мной, что важно будет сохранить факт линией, чтобы это сочеталось с остальными графиками, где нет планов. Самым «классическим» ему показался вариант факт — барами, план — засечками, но! чтобы при этом не было графиков факта линиями на соседних графиках.

Составил табличку сравнений вариантов и проставил плюсики.

Итого, решил взять последний вариант «Линия факт — Ареа план + заливка между линиями». Кажется, что это самый сбалансированный вариант из всех. Хотя не могу сказать, что он идеальный. У каждого из вариантов есть куча плюсов и минусов и этот показался мне наиболее робастным: он сохраняет факт линией, а подсветка сразу даёт понимание, что есть план, а что факт. При этом, легко увидеть, в какие периоды было отставание от плана, и такой вариант удобно реализовать в Табло.

П. С. Спасибо большое Саше Богачеву за обсуждения. И ещё многие написали в личку с идеями, тоже большое спасибо: Роман Зубарев, Егор Ларин и Павел.

Читатель блога написал классный вопрос:
«В ходе работы приходится сталкиваться с заказчиком, который приемлет только таблички с множеством фильтров. На все предложения сделать покрасивее — отвечает отказом, говорит, что тогда потеряется функционал. К слову, в книге ~20 разных дэшбордов и все они должны быть в таком стиле: фильтры и таблички.

Подскажи плз, стоит ли бороться, забить или еще какой-то вариант?)»

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

Таблички vs графики. Теория

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

Есть разные исследования, которые оценивают скорость и точность восприятия информации человеком в виде графиков и таблиц. Мне очень нравится вот эта статья Task-Based Effectiveness of Basic Visualizations. В ней подробно рассмотрено как базовые визуализации решают различные типы задач. Пользователей просили выполнить 10 типов задач с помощью разных визуализаций: найти аномалии, найти кластеры, найти экстремумы, узнать конкретное значение, рассчитать значения между двумя точками данных и т. п. Измерялись три метрики: точность решения задачи, скорость решения и ответ пользователя какая визуализация ему понравилась больше всего для решения этой задачи.

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

Есть и другие статьи Cognitive Fit: An Empirical Study of Information Acquisition и Effects of Tables, Bar Charts, and Graphs on Solving Function Tasks, в которых обсуждаются похожие проблемы и сравниваются таблицы и разные виды графиков.

Общие выводы такие
Таблицы хорошо работают для «количественных задач»: узнать конкретное значение, посчитать разницу или сравнить значения между двумя ячейками. Графики хорошо работают для «качественных задач»: найти общие признаки для точек, найти максимальные и минимальные значения, понять отрицательная или положительная динамика, узнать какое значение больше и т. п.

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

Таблички vs графики. Практика

На практике пользователи, которые просят таблицу, на мой взгляд, решают одну из задач:
1) Получить данные для их дальнейшей обработки (скачать в excel, досчитать сравнение с планом и вставить в power point).
2) Узнать конкретные значения для ad-hoс анализа (сколько продали в точке А в январе).
3) Увидеть много метрик сразу для одной сущности (все метрики продаж для одного города и т. п.).
4) Ранжировать и сравнивать сущности по разным показателям, проводить факторный анализ (видеть топ городов по продажам и знать какие там скидки и маркетинговые расходы).
5) Видеть сырые данные для оценки их качества (важно видеть нет ли «битых» данных, неправильно преобразованных дат, не так заполненных полей CRM и т. п.).
6) Видеть точные данные для их обработки (точные показатели технического процесса, значения плана и факта и т. п.) или бланки строгой отчетности.
7) Не хотят ломать привычку (привыкли к Экселю или им «не нравятся графики»).

Вот что я делаю в каждом из кейсов:

1. Получить данные для их дальнейшей обработки
От бизнеса такой запрос звучит чаще всего как: «Нужна таблица за 5 лет со всеми метриками по всем срезам».

Тут всё довольно прозаично, но придется выяснить потребности. Здесь нужно узнать «Что было дальше?», что пользователь делает после того, как скачал или куда-то перенёс данные. Если вариантов, что с ними происходит дальше, очень много, то научите пользователя self-service — дайте доступ к данным и покажите как с помощью вашего BI инструмента из них можно получать выводы. В Табло, например, для таких целей отлично подходит роль Explorer на сервере и сертифицированные датасорсы.

Если после скачивания данных пользователь, например, каждый раз делает графики в экселе, а потом переносит их Power Point, то просто сделайте ему такие графики, чтобы они формировались автоматически. Вы удивитесь как часто происходит именно такой кейс. =)

Классический self-service

2. Узнать конкретные значения для ad-hoс анализа
От бизнеса такой запрос звучит чаще всего как: «Нужна таблица, в ней можно выбрать любую метрику и даты, и должны быть все фильтры по нашим разрезам».

В бизнесе часто надо узнать значение какой-то метрики «здесь и сейчас». И это отличная задачка для таблиц. Здесь также можно использовать self-service, а можно сделать специальный отчет — такой «полу self-service»: форма, где можно выбрать какие-то срезы и метрики и получать одно или несколько визуальных отображений.

Если и правда происходит так, что пользователям изредка нужны конкретные метрики в определённых разрезах, то сделайте такой отчет. У нас в компании, например, это очень популярный тип отчетов — огромный справочник метрик и возможность показать его в каком-то разрезе в виде таблички или графика. Хорошо решает задачи, чтобы на совещании можно было быстро достать метрику и что-то решить. Или если аналитик проверяет свои расчеты и хочет сверить их с общими трендами или более общей метрикой.

Часто такие отчеты превращаются в операционные дашборды: пользователи сохраняют себе какой-то набор метрик и смотрят за ними каждый день. В целом, это не так страшно. Если пользователь знает свои данные вдоль и поперёк, следит за ними каждый день и понимает даже небольшие изменения на цифрах, то он может работать просто с такими отчетами. Это кейс из серии «ночью разбуди, а он ответит хорошо или плохо, что продажи в точке А составили 12 649 рублей». Но такие кейсы, конечно, лучше отслеживать и делать из них хорошие операционные дашборды.

Полу self-service — готовый отчет с выбором метрик и срезов
 

3. Увидеть много метрик сразу для одной сущности
От бизнеса такой запрос звучит чаще всего как: «Нужная широкая таблица со всеми метриками. Менеджер, который отвечает за свою часть, выбирает нужное в фильтре и смотрит как обстоят дела».

Часто бизнесу нужно получить овервью по какой-то сущности: все метрики по какому-то городу, по какой-то кампании и т. п. Это можно заметить, если в отчете пользователь выбирает что-то фильтрами, а потом пользуется только одной или несколькими строчками. В этом случае классно подходят «страницы сущности», такие one-pager’ы, в которых есть вся нужная информация только по одному городу, например. Всегда сравниваю такие странички с профилем на Фейсбуке — в одном месте вся информация: сколько лет, где работал и т. п.

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

Страница сущности для аптечной сети
 

4. Ранжировать и сравнивать сущности по разным показателям, факторный анализ
От бизнеса такой запрос звучит чаще всего как: «Нужная таблица, в которой можно сравнить разные срезы по такому-то набору метрик».

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

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

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

Такая задача часто возникает у аналитиков, когда они готовят данные и нужно видеть, что именно посчитал код. Или, например, менеджерам, которые работают с анализом данных из CRM, нужно понять правильно ли были заполнены поля. Или если кто-то анализирует неструктурированные ответы пользователей на опросы и т. п. То есть это те кейсы, где нам действительно нужно видеть сырые данные и я делаю обычную таблица. Классно дополнять её какой-то сводной информацией по столбцу, как это сделано, например в Data Wrangler от Trifacta или Tableau Prep. И, если есть такая возможность, прокидывать ссылку из таблицы в систему с сырыми данными.

 

6. Видеть точные данные для принятия решений или бланки строгой отчетности
От бизнеса такой запрос звучит чаще всего как: «Вот форма отчетности, сделайте чтобы она обновлялась автоматически».

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

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

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

Аккуратную таблицу можно сделать даже в Табло

7. Не хотят ломать привычку
От бизнеса такой запрос звучит чаще всего как: «Таблички, таблички, таблички!».

Если не удается выявить ни одну из потребностей, перечисленных выше, то, возможно, люди правда «просто привыкли» или «речевики». К сожалению, привычки — самое сложное, что можно менять у пользователя, а иногда это делать и не нужно. А если и делать, то аккуратно и постепенно. Что делаю в таких случаях я:
— Пытаюсь рассказать почему существуют различные типы представления данных и зачем они нужны, ссылаюсь на исследования из первой части статьи.

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

— Добавляю в таблицы графические элементы: фоновые бар-чарты, спарклайны, хитмапы (highlighted table).

— Делаю и графики, и таблицу. И ставлю её под ними или рядом. Только важно не делать это двумя разными дашбордами, а то вторым могут демонстративно не пользоваться. А если на одном, то графики могут примелькаться и вдруг стать полезными.

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

Надеюсь, что модное нынче течение data literacy не угаснет и скоро таблички будут просить только там, где они нужны.

Подводя итог

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

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

Антон Жиянов написал замечательный набор статей про проектирование интерфейса. Я попробовал применить описанные им принципы к BI системам.

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

Дальше опишу каждый из этих компонентов для BI системы. Буду делать это на примере Tableau, когда речь пойдёт на счет конкретных элементов интерфейса и т. п.

Ментальная модель

Я думаю, что в голове пользователь видит примерно так идеальное взаимодействие с BI системой:

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

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

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

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

Но обычно это выглядит примерно так:

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

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

Внутри системы на меня выпадет большой список с папками, в которых лежат разные отчеты. Некоторые папки будут называться по отделам моей компании, другие по названиям проектов, третьи по имени владельца папки. В папке отдела продаж я найду несколько отчетов без описаний: «Продажи всего», «Продажи по РФ NEW», «По городам 2.0», «Продажи 22.02_Final», «Продажи Бубликов»… Открою первый попавшийся отчет и попробую в нём разобраться. Вроде то, что нужно, но не хватает разбивки до магазина. Зайду в другой отчет, там есть нужная разбивка, но почему-то тотал продаж не сходится с предыдущим отчетом. Спрошу у коллеги, почему так и узнаю, что во втором отчете не учтены продажи из категории «Бакалея», так как они попадают в данные не через API, а менеджер грузит их раз в месяц через Excel файл.

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

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

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

1. Спрятать всю сложность от пользователя и, зная его роль в компании и его задачи, выводить самый релевантный контент. То есть в идеале, BI система — это строка поиска, которая классно даёт ответы. Такой Яндекс + Вольфрам Альфа, но только заточенный под конкретную компанию.
2. Разбить слона по кусочкам — построить систему шагов и вопросов, которые смогут провести пользователя «за ручку», чтобы решить его кейс, но при этом не переусложнить всё огромным и непонятным интерфейсом. Примеры из обычных продуктов есть в статье Антона.

Ожидания от продукта

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

Навыки

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

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

В целом я бы проектировал BI системы не прям для массового пользователя, но и не для профессионального аналитика. Для меня это больше похоже на фразы «Продвинутый пользователь ПК» или «Умеет работать с Excel» из резюме. То есть пользователь действительно обладает базовыми навыками работы с профессиональным ПО, но не готов погружаться в тонкости (читать документацию и инструкции) перед тем, как пользоваться BI системой и воспринимает её как просто сложный сайт.

Контекст использования

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

Платформа

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

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

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

 
В распространение мобильных дашбордов я пока верю не очень. Кажется, что мобильные дашборды в бизнесе решают очень узкий круг задач: это или полевые работники, либо реальный топ-менеджмент, который хочет что-то иметь под рукой, чтобы держать руку на пульсе. Всё-таки большинство рабочих задач до сих пор решаются на компьютере. Поэтому мобильные приложения и верстка дашбордов под мобильный, на мой взгляд, в бизнес-среде важны не так сильно. Но разные размеры мониторов — очень важны. Мы в команде самые важные отчеты делаем адаптивными под ноутбук и большие мониторы. Это, кстати, просто привычный паттерн веб-приложений — пользователи воспринимают как норму что сайты должны быть адаптивны.

При этом адаптивность может быть довольно простой. Например, просто меняется расположение основных блоков и их их размеры. Что-то такое:

Маленький монитор

Первые два блока стоят горизонтально

Большой монитор

При увеличении экрана они перемещаются в вертикальное положение

Цели пользователя

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

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

Подробнее про то, как это влияет на проектирование отчетов писал в статье про шаблоны верстки дашбордов. Правда сейчас понимаю, что было бы правильнее назвать это не шаблонами верстки, а подходами к проектированию.

Ожидания в целом

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

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

Задачи пользователя в интерфейсе

Для достижения целей пользователь формирует задачи (посмотреть города «А» из всех городов) и ищет действия для реализации задач в интерфейсе программы (выбрать в выпадающем списке город «A» и нажать apply). Тут как всегда всё будет сильно индивидуально, но в BI среде чаще всего нужны следующие задачи:

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

Как лучше всего реализовать эти действия в интерфейсе я рассажу в другой раз, с реальными примерами реализации в Табло. Пока просто опишу общие правила:

1. Эти действия должны быть одинаковыми от отчета к отчету (если включили кнопку apply, то включайте во всех-всех отчетах для фильтров с мультивыбором).
2. Лучше всего, если это общепринятые действия и паттерны, свойственные платформе. Для веба это подчеркнутые ссылки, выделение интерактивных элементов и т. п.
3. Если не получается использовать общепринятые паттерны (например как с Табло из-за кучи ограничений в самой системе), то всегда помогайте пользователю в этом месте и формируйте новую привычку. Но, опять же, одинаковую для всех отчетов. Например, если можно фильтровать данные с помощью клика в график, добавьте иконку или описание про это.

Вместо заключения

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

Сейчас много приходится работать с различными дашбордами для бизнеса: делать самому или помогать придумывать коллегам макеты. Выработались некоторые стандартные шаблоны под разные задачи, хочу ими поделиться.

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

Шаблон «Страница сущности»
Задача: Узнать что-то про определенную сущность (заранее знаю что хочу увидеть)

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

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

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

«Лонгрид»

«Сайт с закладками»

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

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

«Утро деньги, вечером стулья»

 
 
Шаблон «Аналитический инструмент»
Задача: Получить какой-то инсайт, не зная что именно ищу. Или сделать выводы, имея в голове определенный алгоритм

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

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

Ещё очень похожей задачей будет, если у вас в голове уже есть алгоритм, которым можно воспользоваться для того, чтобы сделать вывод. Тогда нужен или просто удобный инструмент, чтобы это сделать быстро и наглядно, или всевозможные инструменты what-if анализа. Их тоже очень класно показывать через визуализацию данных, особенно если вы следите сразу за несколькими сложными сценариями с несколькими переменными.

Рецепт (краткая версия): Разбираемся в бизнес-задаче и какими метриками описывается эта задача. Здесь важно идти от того, что происходит в реальности, к тому как это превращается в метрики и срезы. Если можем, то выбираем главные и вспомогательные метрики. Хорошо, если можем следить за изменением какой-то одной метрики, чтобы понять общий ход событий, а на остальные смотреть, если нужно прокопать причинно-следственные связи. Делаем несколько визуализацией в разных срезах. Чем мельче детализация, тем лучше (вместо средних продаж, показываем значения продаж каждого магазина и т. п.). Слева основные визуализации, справа доп. информация и различные срезы по основной метрике (если есть). Много интерактива — графики фильтруют друг друга, возможно проваливаемся в другие дашборды или показываем доп. графики и срезы при наведении. Сам «шаблон», по сути, не шаблон, а подстраивается под каждую задачу.

Рецепт (полная версия) — задачи такого класса ИМХО хорошо описаны в алгоритме Лаборатории данных Тани Бибиковой. Подробнее в статье на Хабре или на учебном курсе .

«Аналитический инструмент»

 
Шаблон «Приборная панель»
Задача: Отслеживать операционные данные на «ежедневной» основе

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

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

«Приборная панель»

Вместо вывода

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