Дашбордец
8.88K subscribers
287 photos
3 videos
75 files
780 links
Привет, котятки) Я Даша, и это мой уютный канал про дашборды - от бизнес-анализа до реализации на BI. Темы канала: data viz, BI, dashboards, DWH.
По вопросам писать: @Dddv_2705
Download Telegram
Мои впечатления от Apache Zeppelin: это не Tableau, но как песочница вполне ничего так)
Как начать работу и сделать свой дашборд: https://www.cloudera.com/tutorials/getting-started-with-apache-zeppelin.html
#Дашборд - гибкая история со своими вехами. Чем дольше пользователь смотрит на дашборд, тем больше он хочет видеть) Матрица контента нужна бизнес-аналитику, чтобы понимать, что из контента уже в проде, какие фичи готовятся, а какой контент на уровне идеи!
Линк: https://netology.ru/blog/07-2019-popolnyat-kontent-plan-matrica-kontenta
Чем дашборд отличается от инфомассы?🙈
Линк: https://www.uplab.ru/blog/dashbordy-strategicheskie-i-takticheskie/
Принцип пирамиды Минто в дашбордах.

1. Почему необходимо использовать?
‌-по мере поступления и восприятия информация автоматически сортируется сознанием в отчетливые пирамидальные структуры;
‌-любая группа идей легче усваивается, если воспринимается выстроенной
в виде пирамиды, горизонтальной или вертикальной;
-‌в формате "пирамиды" сохраняется устойчивая логика "от частного к общему".
2. Где учитывать в дашборде?
-‌при принятии решения о контенте дашборда с точки зрения ЦА;
-‌при конструировании макета дашборда (от более агрегированной аналитики в левой части макета до детализации в правой части);
-‌при построении диаграмм для демонстрации последовательных процессов (например, воронка продаж).
Линк: https://baguzin.ru/wp/printsip-piramidy-minto/
Лепестковая диаграмма является очень практичной эпюрой, позволяющей оценить один и тот же объект сразу по нескольким направлениям (метрикам).
Особенности:
-количество осей соответствует количеству метрик;
-точки на диаграмме объединены линиями, что позволяет строить сравнительный анализ сразу по нескольким объектам (с наложением);
-шкалы всех метрик должны быть унифицированы (самое практичное - в %).
Как это строить в Tableau:
https://tableaumagic.com/drawing-radar-charts-in-tableau/
В сложном мире неопределенности бизнес-требований хорошо заходят прототипы. Прототип дашборда, собранный "на коленке" поможет понять, что хочет пользователь, лучше, чем десяток интервью. Или, на крайний случай, разобраться, чего точно делать не надо😈
Линк хорошей статьи про BI- прототипирование: https://tdwi.org/Articles/2011/03/30/Better-Prototyping-Improves-BI.aspx?m=1&Page=1
Ещё немного про прототипы😊

Прототип дашборда, в отличие от макета, позволяет собрать расширенную обратную связь от пользователей. В ходе тестирования прототипа наш юзер сразу сможет дать инсайты по навигации, агрегированию и детализации данных. Наблюдения за динамикой и ходом тестирования помогут лучше понять целевую user story использования дашборда.
В дальнейшем это существенно сэкономит количество итераций для выхода на MVP.
Про преимущества прототипирования: https://www.usertesting.com/blog/small-team-prototyping/
Сегодня мои пользователи пришли ко мне и радостно рассказали, что выучили новый термин - User story😊. И очень хотят применять его к дашборду
До полноценной пользовательской истории им ещё далеко, но основной принцип они усвоили, а именно, их истории содержат:
-Для какой роли мы делаем фичу в дашборде?
-Кто заказчик?
-Как это будет выглядеть/работать?
-Зачем это/какие решения будут приниматься на основе этой аналитики?
Хорошая статья
На прошлой неделе ко мне пришел мой product owner и интеллигентно, но твердо попросил поменять визуал фильтрации даты в дашборде на Tableau. В общем, дашборд – это динамическая история, которая требует трепетного отношения к такой сущности, как время😉
Имеет значение:
• Используемый тип данных
Иерархия времени
• Вид data-фильтра, который вы выводите пользователю.
Мне самой очень нравится «ползунок» даты.
Но, увы, по опыту, пользователи наилучшим образом воспринимают выбор дат в виде традиционного календаря.
Линк про даты в Tableau:
https://help.tableau.com/current/pro/desktop/en-us/filtering.htm#FilterDates
Самый базовый hard skill — это системное мышление. Без него сложно четко изложить свои мысли, написать пост, подготовить презентацию и, конечно, создать дашборд.
Дашборд как раз и отличается от инфомассы системностью: четкой структурой и продуманной User story.
Про системное мышление лучше всего рассказывает SEВok, а на практике при проектировании дашборда можно использовать такой инструмент, как дерево решений.
У меня есть свой собственный чек-лист тестирования дашборда. Создавала я его со слезами и не раз разбитым лбом😢
Один из его разделов - тест на избыточность пользовательских сценариев.
Проверяется, может ли пользователь:
-получить одни и те же данные на дашборде с помощью принципиально разных пользовательских сценариев;
-получить одни и те же данные в разных частях дашборда/на разных диаграммах;
-есть ли избыточная фильтрация (возможность установить один и тот же фильтр несколькими независимыми способами).
В общем, в основе проектирования дашборда должен лежать принцип MECE (Mutually Exclusive & Collectively Exhaustive).
Линк
Хороший дашборд (не инфомасса!) проектируется под определенную пользовательскую роль. Соответственно, аналитика, которую отображает дашборд, отвечает на конечное число вопросов и имеет ряд ограничений по отображению и каскадированию. Иначе дашборд становится "для всех и ни для кого" и им просто перестают пользоваться🤷‍♀
Линк
Когда-то мы начали тотальную дашбордизацию в компании с оперативных дашбордов. И однажды наступил тот самый момент, когда пользователи начали просить более агрегированную аналитику, чтобы понимать, куда им дальше двигаться.
Мы для себя выделили 3 очевидных сценария:
1) добавление аналитических метрик на отдельном листе дашборда, с которого можно "провалиться"в операционную детализацию;
2) создание отдельного дашборда - аналитической панели;
3) перестройка дашборда с одновременной ролевой кастомизацией с помощью преднастроенных фильтров.
За год на разных задачах попробовали всё, второй сценарий заходит пользователям лучше всего.
Линк про виды дашбордов
Каждый product owner рано или поздно сталкивается с проблемой приживаемости своего продукта - User Adoption.
Дашборд можно рассматривать как продукт, и значит, к нему применимы все те же подходы к оценке приживаемости, как и к любому другому IT-продукту.
На первых порах можно применять 2 простых практики:
-для оперативных дашбордов использовать объективные количественные метрики посещаемости;
-для аналитических дашбордов собирать обратную связь от пользователей: формальную в виде анкетирования и неформальную в виде отзывов и пожеланий.
Полезный линк
На работе я использую Tableau, а дома под чаёк и хорошую музычку пытаюсь осваивать Tibco Spotfire.
У последнего есть такая фича, как возможность анализа неструктурированных текстов.
В глубине души я все ещё мечтаю, чтобы материалы интервью с пользователями сами собой собирались в структурированные бизнес-требования😜
Линк со сравнением двух BI-систем
Лет 5 назад я серьезно и очень вдумчиво вчитывала теорию ограничений Голдратта.Теория мне казалась интересной, а вот инструментарий - громоздким.
Но как бы мы не уворачивались, хорошие инструменты сами к нам прилипают:)
Сейчас я стабильно применяю в бизнес- анализе граф "дерево текущей реальности".
Линк про то, как его строить
У каждого бизнес-аналитика свои предпочтения по ПО для создания макетов дашбордов.
Мой топчик:
Balsamiq - для предварительных макетов;
Power Point с надстройкой think cell - для финальных макетов;
Omnigraffle - для проектирования визуальной User Story на Mac.
Линк с обзором
Искала сегодня бенчмарк неудачных визуализаций, и нашла замечательную книгу - Storytelling with data.
В книге сделан сильный акцент на трансформацию в визуализации и разбираются типовые ошибки. Про storytelling там тоже есть:)
Линк с конспектом
storytelling-with-data-cole-nussbaumer-knaflic.pdf
12.4 MB
storytelling-with-data-cole-nussbaumer-knaflic.pdf
Диаграмма рассеяния (scatter plot) очень хорошо подходит для анализа зависимостей между параметрами. Из плюсов: благодаря игре с формой, цветом и размером каждой "точки", мы можем отобразить 3 дополнительных атрибута на одной диаграмме.
Для грамотного отображения нужно помнить "правило большого пальца": помещать самые важные данные на оси X или Y, а менее важные атрибуты отображать в виде цвета, размера и формы.
Мой босс ласково называет этот тип диаграммы "грязь", и дальше макета эти диаграммы обычно у меня не уходят😈
Как строить в Tableau
Вопрос "считывания" диаграмм пользователями, -это, скорее, вопрос клиентоориентированности. Я могу сколько угодно объяснять пользователю достоинства диаграммы scatter plot aka "грязь" или диаграммы tree map, но если ему не нравятся эти диаграммы, - к моему дашборду он больше не вернется.
Ряд моих коллег считает, что нужно "заставлять пользователя" и таким образом взращивать культуру использования данных. Думаю, всё хорошо в меру, и должен быть баланс между клиентоцентричностью и просвещением в сфере визуализации.
26 главных вопросов, на которые нужно ответить прежде, чем сесть за макет дашборда