Прототипирование дашбордов в BI-системах: что это за процесс и почему он так важен

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

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

Если собираются данные в визуально понятном виде, интерпретируются и применяются на их основе решения — в компании подход Data Driven. Если процесс аналитики ещё не сформирован, организация использует подход Data Inspired. Она полагается только на свои опыт и интуицию, и это применимо, если ниша небольшая или организация прекрасно знает свой рынок.

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

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

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

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

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

Ключевые преимущества прототипирования дашбордов:

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

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

Далее мы рассмотрим основные этапы, из которых состоит прототипирование дашбордов.

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

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

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

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

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

Далее ещё раз собирается обратная связь и утверждается финальный прототип. Затем начинается перенос прототипа в BI-систему и процесс подготовки данных:

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

Минусы: нет гибкости в плане интеграций с внешними сервисами, нет защиты — чувствительные данные могут потеряться, потребуется много времени для построения всей BI-системы.

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

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

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

FastBoard — BI-платформа для визуального анализа данных. С её помощью за 4 недели можно спроектировать дашборды, согласовать их с руководителем и загрузить первые датасеты. Как говорилось выше, продуктовая команда готова помочь сформулировать бизнес-сценарий для анализа данных и предложить готовый прототип, собранный на виртуальных данных.

Для построения макета дашборда не нужны объёмные ТЗ или знания программирования. В первые 14 уже можно собрать прототип при помощи конструктора. Затем, если нет опыта работы в редакторе SQL-запросов, делегировать на команду FastBoard подключение источников и создание моделей данных, чтобы метрики начали коррелировать между собой.

Этот способ помогает аналитической команде, бизнесу, воспитать философию Data Driven. Совместная работа с данными экономит время специалистов, которое они могут инвестировать на формирование новых гипотез. Оптимизация P&L, анализ показателей контроллинга, планирование инвестиций, визуализация cashflow — всё это доступно в FastBoard рамках единого окна. А если для кого-то из коллег всё же Excel — это максимально привычная среда для работы с данными, FastBoard может загрузить таблицу с показателями или выгрузить её.

Минусы: хотя все прежде описанные варианты бесплатны, FastBoard — это продукт, и за внедрение и эксплуатацию нужно платить. Это инвестиция в скорое погружение в философию Data-Driven.

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

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

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

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

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

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

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

Ещё раз пройдемся по ключевым моментам: