В сложном мире неопределенности бизнес-требований хорошо заходят прототипы. Прототип дашборда, собранный "на коленке" поможет понять, что хочет пользователь, лучше, чем десяток интервью. Или, на крайний случай, разобраться, чего точно делать не надо😈
Линк хорошей статьи про 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

Диаграмма рассеяния (scatter plot) очень хорошо подходит для анализа зависимостей между параметрами. Из плюсов: благодаря игре с формой, цветом и размером каждой "точки", мы можем отобразить 3 дополнительных атрибута на одной диаграмме.
Для грамотного отображения нужно помнить "правило большого пальца": помещать самые важные данные на оси X или Y, а менее важные атрибуты отображать в виде цвета, размера и формы.
Мой босс ласково называет этот тип диаграммы "грязь", и дальше макета эти диаграммы обычно у меня не уходят😈
Как строить в Tableau

Вопрос "считывания" диаграмм пользователями, -это, скорее, вопрос клиентоориентированности. Я могу сколько угодно объяснять пользователю достоинства диаграммы scatter plot aka "грязь" или диаграммы tree map, но если ему не нравятся эти диаграммы, - к моему дашборду он больше не вернется.
Ряд моих коллег считает, что нужно "заставлять пользователя" и таким образом взращивать культуру использования данных. Думаю, всё хорошо в меру, и должен быть баланс между клиентоцентричностью и просвещением в сфере визуализации.
26 главных вопросов, на которые нужно ответить прежде, чем сесть за макет дашборда

Много лет назад, когда трава была зеленее, а про BI слышали единицы, мой тогдашний босс узнал слово "дашборд". Он долго показывал мне скомпонованные графички на excel, а я не понимала, как в excel делать динамические обновляемые дашборды.
Сегодня наткнулась на Clear Analytics
Агрегирует данные из разных источников сразу в excel с возможностью строить дашборды на плече Power BI. Из плюсов: пользователь больше не просит выгрузить "табличку в excel", ведь все данные и так в excel. Из минусов: да-да, это все ещё старый добрый excel с расширенными возможностями по объединению источников и построению дашбордов.
Тискаю демку, смотрю видосики

Чтобы начать использовать BI и клепать свои дашборды, нужно купить BI-систему🙈
Гайд по вариантам ценообразования BI-ПО в 2019 году читать тут.

Тема data discrimination как никогда актуальна, дашбордов это тоже касается:) Есть ряд этических аспектов, которые надо продумывать сильно заранее, ещё на этапе макета:
1) Конфиденциальность данных в управленческом процессе.
Если данные в дашборде каскадируются до конкретного сотрудника(в явном или зашифрованные виде), то, в случае неидеальной ролевой модели доступа к дашборду, они могут попасть не в те руки. Риски в этом случае сильно зависят от бизнес-процессов и корпоративной культуры, но они, увы, есть: от попыток управления сотрудником "через голову" (при сквозной аналитике) до вмешательства в управленческие процессы смежных подразделений.
2) Публичность демонстрации дашборда.
Если дашборд планируется выводить в общее пространство (например, на интерактивную доску), необходимо заручиться одобрением рядовых сотрудников. Одно дело, когда дашборд отражает, например, неперсонализированные производственные показатели, и совсем другое - когда выводятся рейтинги сотрудников. Не все готовы к навязанной конкуренции, и не все готовы выносить её в публичную плоскость.
3) Дискриминирующие метрики.
Моя любимая тема:) Любые данные с помощью относительных показателей и определенных разрезов можно вывести так, что объективный лидер сдвинется на последнюю строчку пьедестала. Поэтому в дашборде можно руководствоваться 2 правилами:
- при сравнении приводить показатели в сопоставимом виде по периодам, размерности, гранулярности, и пр., и в крайнем случае приводить метрики в относительный вид с единым знаменателем(на единицу чего-то).
-если метрику нельзя сделать полностью объективной, выводить текстовым пояснением или примечанием на всплывающем окне доп.сведения, которые позволяют правильно интерпретировать значения.
Очень кратенько про этику и ИИ (применимо и к дашбордам): линк

Если описывать то, что делает BI -специалист каждый день, то получится примерно так, как это описал Джонатан Корум на картинке.
Он же дал мне, пожалуйста, главный фреймворк работы с дашбордами: Визуализация ≠ объяснение.
Объяснять и принимать решения должен бизнес, и дашборды ему в помощь:)
Линк на старую, но полезную статью про визуализацию и сторителлинг на основе выступления Джонатана Корума

В то время, как все озабочены культурой принятия решений на основе данных, остро встает вопрос: ставить данные во главу угла (Data-Driven Decision) или воспринимать их только как один из множества элементов разнородных "входов", на который следует обращать внимание при принятии решений (Data-Informed Decision).
Линк на полезную статью-размышление на эту тему, а также про data-культуру