о визуализации данных и развитии BI-систем
канал в телеграмме | подборки | видео

Избранное

Dashboard is dead. Long live Dashboard!

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

не ищем связи картинки и текста, ее нет

Что в статье у Саши
Точно стоит прочитать её полностью для формирования своего мнения, она очень классная и заставляет думать. Ниже моё субъективное восприятие:

Текущий подход к дашбордам и BI-инструментам плохо решает задачи бизнеса и вера в них слабеет. Дашбордов делается всё больше, а реальную пользу они приносят не всегда. Аналитики любят свои дашборды и переоценивают их пользу, но боятся признаться в этом. А лучше признаться позже, чем никогда. Поэтому в будущем мы откажемся от повсеместного создания дашбордов и будем управлять метаданными данных и отчетов, чтобы «умные» BI-системы с помощью AI и NLP/NLG генерировали инсайты, готовые визы и подсказки пользователям. А пользователи же собирали из этих блоков как конструктор пинборды для своих задач (не очепятка, от слова pin). При этом BI-отделы будут собирать «подборки» самых полезных пинбордов для разных ролей сотрудников, заниматься мастер-данными и иногда делать сложные отчеты.

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

тут тоже нет связи с текстом)

Один инструмент для всех задач

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

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

Окей, во многом это вопрос терминологии. Проблема в том, что под Business Intelligence понимают разные вещи. Если посмотреть википедию, то это целый набор систем и действий от репортинга (как раз дашборды) до предиктивной аналитики и циклов улучшения процессов. Так же себя стараются позиционировать и вендоры — «мы не просто дашбордики, мы экономим вам деньги».

Но при этом большинство людей, которые слышат термин Business Intelligence, в первую очередь, думают именно о дашбордах:

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

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

Современные BI-системы неплохо справляются с операционной аналитикой, но не идеально. При этом вендоры усердно идут именно в область поисковой аналитики и пытаются демократизировать данные с помощью модных AI и NLP и т. п. Мне жe кажется, что им бы стоило в первую очередь заниматься скоростью и стабильностью работы отчетов, сквозной провязкой данных, упрощением поиска отчетности, удобством администрирования и доступа к этим системам, а не «модными» направлениям. По сути, медленно работающий дашборд (частая, к сожалению, история всех BI-систем) — это нарушение минимально необходимых ожиданий пользователя по модели Кано, но этим занимаются далеко не в первую очередь.

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

И давайте, пожалуйста, не стесняться говорить, что мы делаем Reporting. В последнее время слышу от коллег, что как будто что-то нехорошее делаю. Стоп-репортинг-шейминг! =) А то такое ощущение, что надо делать везде только Self-Service и повсеместно развивать Data Literacy. Давайте, кстати, их тоже обсудим.

тут тоже нет связи с текстом, ну почти нет =)

Повсеместный Self-Service и Data Literacy

Сейчас говорят, что Excel — это плохо и ужасно, давайте сделаем везде Self-Service (я говорю про доступ к данным операционным менеджерам и сотрудникам, а не аналитикам в подразделении бизнеса). При этом, если Self-Service не взлетает, то впадают в две крайности: или ругают инструменты и пытаются сделать их проще с помощью NLP, Ask Data, AI и т. п.; или уходят в сторону людей — это не инструмент плохой, это пользователи не умеют работать с данными, давайте всех обучим Data Literacy.

Я уверен, что и тот, и тот путь приводят к одному — вендоры продают все больше лицензий и новых инструментов (думаю отчасти эта тема поэтому так и двигается), а люди так же плохо работают с данными и скоро будут ругать уже не Эксель и Кубы, а Табло и PBI. Так как суть будет та же — это просто прямой доступ к данным на стороне бизнес-пользователя, такой же, как был в Экеселе, который, о боже, тоже умеет подключаться к базам данных и OLAP. Проблема не в инструменте, а в управлении генерируемым контентом и решениями, которые делают пользователи на основе этих данных. Окей, тогда виноват не инструмент, давайте всех обучим работать с данными. И тут возникает вопрос: а почему это должно помочь?

Кажется, что мы, в целом, переоцениваем Data Driven подходы (здесь имеется ввиду анализ данных для принятия решения, построение гипотез и их проверка). Данные важны, но, к сожалению или к счастью, они не дают +100500% к эффективности просто своим наличием. Ты смотришь на данные и видишь, что есть проблема, но часто или не можешь повлиять на метрику, или, чтобы на неё повлиять, надо менять процессы и людей, а это супер сложно и часто понятно, что делать и без дашборда. Приведу личный пример — я собираю много данных о себе: и вес, и шаги, и сколько сижу за компом. Казалось бы: класс, наверное можно взять и получить кучу инсайтов! Но, как говорится «фигвам». Я столько раз крутил эти данные, делал красивые визы, но, по сути, это всё превращалось только в fun facts. Реальных инсайтов получить из них я не смог, а вот наличие контроля часто напоминает, что нужно что-то делать. А вот что нужно делать для улучшения здоровья, понятно и без дашборда, кеп. =)) Кажется, что так и в бизнесе, иногда надо просто взять и сделать, а не ждать красивого отчета.

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

тут нигде нет связи с текстом

Что дальше

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

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

— Хайп Self-Service пройдёт и большинство компаний разочаруются в нём. При этом появятся удобные NoCode и NLP инструменты, которые снимут часть работы с аналитиков данных, когда их используют в качестве переводчика с «человеческого на SQL-ный» для выгрузок и презентаций. Со временем это будет превращаться в свалку дашбордов, запросов и рабочих книг, но кто-то придумает крутой полуавтоматический процесс чистки таких завалов. Это упростит и ускорит работу бизнеса, но глобально не позволит сэкономить огромное количество денег, только сократит время на получение данных. При этом аналитики данных станут заниматься более важной работой по построению гипотез и изменениям продукта и процессов. Грань между аналитиками данных, продуктовыми аналитиками, бизнес-аналитиками процессов и менеджерами продукта будет стираться.

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

— Эксель не умрёт =)

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

The Dashboard is dead. Long live the Dashboard!

Связи правда нет, я просто подрезал идею у Саши в статье и захотел его немного потроллить =)
Модель — длиннопёс Юччи, фотограф — Валерия Бунина
 2 комментария    13326   2022   теория

Список лайфхаков Табло

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

Выпуск №1
0:00 — Как сделать удобный фактоид с приростами период к периоду
9:26 — Как показать разрыв в данных с помощью Missing Values
11:58 — Как ускорить работу в Табло за счет фишек интерфейса

Выпуск №2
0:00 — Сортировка по значению за последний месяц с помощью Nested Table Calcs
4:04 — Оформление спарклайнов при помощи Reference Lines
7:12 — Highlighted таблица с подсветкой по одной метрике из Measure Values

Выпуск №3
0:00 — UTF символы для создания цветовой легенды
3:29 — Динамический фильтр дат с окном и ренджем
7:08 — Подпись событий о запусках или маркетинговых активностях во времени на таймсерии

Выпуск №4
0:00 — Как сделать удобную адаптивную легенду
3:00 — Как подписать точки на графике по условию
7:12 — Как избежать проблем при работе с Табло на Windows

Выпуск №5
0:00 — Составные таблицы из нескольких листов
4:19 — Функция Random()
8:16 — Переименование Worksheets и Dashboards на сервере

Выпуск №6
0:00 — Тоталы в барах
4:19 — Таблица с спарклайнами
8:16 — Предыдущий период на графике

Выпуск №7
0:00 — Пагинация в таблице
4:45 — Сравнение метрики по разрезам
11:23 — Подсветка строк в таблице

Выпуск №8
0:00 — Бины и группировка максимума
5:38 — Выравнивание в бар-чарт таблице
13:05 — Подсветка выходных

Выпуск №9
0:00 — Дубль графиков
6:01 — Топ N в каждой категории
9:22 — Размер точек на карте

Выпуск №10
0:00 — Run Rate
12:30 — Двойная цветовая легенда
15:04 — Apply to Totals

Плейлист со всеми выпусками:

Кем работать, если нравится визуализация данных

Читатель блога спросил кем работать, если нравится визуализация данных. Собрал небольшой гайд по профессиям, где одним из основных навыков является визуализация данных. Всё ниже сказанное — моё субъективное мнение и опыт. Зарплаты Московские, net по результатам анализа рынка аналитики и инструмента быстрого анализа зп по запросу. Примеры вакансий не самые актуальные, а самые подходящие по навыкам и т. п. Если есть чем дополнить статью и я что-то пропустил — пишите.

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

Разработчик дашбордов

Тэги: BI-аналитик, BI разработчик, Data Visualization Engineer, Разработчик отчётности, Разработчик + название BI системы, Консультант по + название BI системы.

Что делать: Разрабатывать и поддерживать дашборды и внутреннюю отчетность в компании.

Основные навыки: техническое знание BI системы (Tableau, Power BI, Qlik), графический и UX дизайн, сбор требований, SQL и подготовка данных.

Насколько много визуализации: 60% — визуализация, 20% — сбор требований, 20% — подготовка данных.

Зарплаты: junior — 50-80, middle — 100-140, senior — 160-200.

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

Примеры вакансий и фриланса:
https://hh.ru/vacancy/38814023
https://hh.ru/vacancy/38402536
https://hh.ru/vacancy/38763777
https://www.upwork.com/search/jobs/?q=tableau
https://www.standav.com/careers_v4/index.html?job_id=z5G7h3

Аналитик данных

Тэги: Data analyst, Бизнес-аналитик, Аналитик, Аналитик баз данных, Маркетинговый аналитик, Продуктовый аналитик.

Что делать: Полный цикл анализа данных: подготовка и обработка данных, анализ, представление результата в виде дашборда (чаще всего)

Основные навыки: Python, практическая мат. статистика, SQL и подготовка данных, технические знание BI системы, сбор требований и управление проектами.

Насколько много визуализации: 35% — подготовка данных, 35% — анализ данных, 15% — визуализация данных, 15% — сбор требований.

Зарплаты: junior — 30-80, middle — 100-180, senior — 180-260.

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

Примеры вакансий и фриланса:
https://yandex.ru/jobs/vacancies/analytics/analyst_eda_test/1w=
https://hh.ru/vacancy/39416083
https://hh.ru/vacancy/39657872
https://www.upwork.com/search/jobs/?q=analyst

Дизайнер интерфейсов аналитических платформ

Тэги: UX дизайнер, Аналитические системы, Корпоративные системы.

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

Основные навыки: Информационный дизайн, верстка и типографика, UX/UI дизайн, Figma.

Насколько много визуализации: 50% — сбор требований, 30% — проектирование и отрисовка визуализаций и интерфейсов, 20% — проектирование сценариев.

Зарплаты: junior — 30-80, middle — 100-140, senior — 140-220.

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

Примеры вакансий и фриланса:
https://hh.ru/vacancy/38732193
https://hh.ru/vacancy/40129963
https://www.upwork.com/job/detail-orientated-designer-for-data-analysis-app

Фронт-энд разработчик

Тэги: d3.js и любые другие библиотеки визуализации.

Что делать: Разрабатывать аналитические web-приложения или сложные кабинеты с большим количеством визуализаций.

Основные навыки: JS, фреймворки, CSS, информационный дизайн.

Насколько много визуализации: 70% — написание и тестирование кода, 15% — сбор требований, 15% — дизайн визуализаций.

Зарплаты: junior — 30-90, middle — 130-160, senior — 180-280.

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

Примеры вакансий и фриланса:
https://hh.ru/vacancy/39967086
https://hh.ru/vacancy/39924837
https://hh.ru/vacancy/39687471
https://www.upwork.com/search/jobs/?q=d3.js

Дизайнер инфографики

Тэги: Дизайнер инфографики, Дизайнер презентаций.

Что делать: Делать инфографику и важные печатные корпоративные отчеты.

Основные навыки: Информационный дизайн, верстка и типографика, Illustrator, Power Point.

Насколько много визуализации: 70% — проектирование и отрисовка инфографики, 30% — сбор требований.

Зарплаты: junior — 30-40, middle — 80-120, senior — 120-160.

Востребованность: В целом довольно востребованное направление, можно найти как и отдельные вакансии, так и пойти в одно из агентств, которые на этом специализируются: https://infografika.agency/ru/ https://infografika.in/ и т. п.

Примеры вакансий и фриланса:
https://hh.ru/vacancy/39930792
https://hh.ru/vacancy/39653396
https://hh.ru/vacancy/39941199
https://hh.ru/vacancy/40143575
https://www.upwork.com/search/jobs/?q=infographics

Журналист данных

Тэги: Data журналист.

Что делать: Собирать и исследовать данные, формировать из них медиа-истории и статьи.

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

Насколько много визуализации: 50% — сбор данных, 25% — создание истории, 25% — визуализация.

Зарплаты: junior — 30-40, middle — 60-80, senior — 120-150.

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

Примеры вакансий:
https://journal.tinkoff.ru/team/infographics-designer/
https://hh.ru/vacancy/38148283

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

Помимо стандартных hh и т. п., работу можно поискать тут:
https://www.datavisualizationsociety.com/find-a-job
https://t.me/analysts_hunter
https://t.me/biheadhunter
https://revealthedata.com/examples/hh/
https://revealthedata.com/examples/vacancies/

График План-Факт во времени

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

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

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

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

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

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

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

Не найдя 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 системам.

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

Дальше опишу каждый из этих компонентов для 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 командам при внедрении и поддержке системы.

Ранее Ctrl + ↓