Гештальт-принципы визуализации данных

Слово "гештальт" не ассоциируется с графиками - между тем, полезно знать, как юзеры воспринимают наши отчеты и дашборды 📈

Гештальт-принципы разработали немецкие психологи — они помогают понять, как человек воспринимает визуальную информацию. Разберемся, как использовать их в нашу пользу.

1. Близость

Если элементы расположены рядом, мозг свяжет их в единую группу.

➖ Как это можем использовать мы:

1. Размещайте элементы графика (подпись, легенда) ближе к самому графику;
2. Ставьте рядом графики, связь которых хотите подчеркнуть — если нужно обозначить связь роста двух KPI, разумно разместить их рядом.
⁠
#датавиз

Сегодня расскажу ещё о двух свойствах, связанных друг с другом.

2. Сходство

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

➖ Как это можем использовать мы:

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

3. Ограждение

Если элементы заключены в выделенную область, мозг отделит эту группу от остального массива элементов.

➖ Как это можем использовать мы:

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

Заключительная часть рассказа о гештальт-принципах.

4. Замкнутость

Мозг любит простые формы — настолько, что готов дорисовать их там, где их нет.

➖ Как это можем использовать мы:

Всевозможные рамки стоит убирать — отчеты будут восприниматься лучше.

5. Непрерывность

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

➖ Для аналитиков этот принцип, в первую очередь, о порядке:

1. Визуальные элементы графика (подписи, легенда) должны быть выровнены единообразно. Все отступы также лучше стандартизировать;
2. В визуализацию тоже можно внести порядок — например, отсортировав элементы барчарта, легенду от большего к меньшему, либо упорядочив графики по важности или по времени.

6. Соединенность

Это сильный принцип - если элементы соединены, мозг воспримет их как одно целое. И неважно, какого цвета и формы наши элементы :)

➖ Как это можем использовать мы:

1. Если важно подчеркнуть, что зависимость есть — смело соединяйте точки на графике;
2. В обратную сторону это тоже будет работать — если нет уверенности, что величины зависимы, соединять точки не стоит.​

#датавиз

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

В качестве датасета я взяла стандартный Iris. Парой несложных движений получилось улучшить исходный график:
➖ за счет цвета появилось дополнительное измерение (принцип сходства)
➖ график стал легче восприниматься — убрали лишние линии (принцип замкнутости)
➖ выровняли легенду и подписи к осям (принцип непрерывности и близости)

#датавиз

На графике из прошлого поста есть спорный момент — на нем "отрезан" ноль.

➖ Это вообще законно?

Короткий ответ — не всегда.

На этот счет есть интересная статья в блоге Practical Reporting, но на мой вкус, предложенная схема громоздкая.

Вот какие правила я вывела для себя:

➖ Если метрика меняется на 10-15% и за такими изменениями важно смотреть — оторвать ось от нуля нужно;
➖ Если расстояние до нуля не несет никакого физического смысла — оторвать ось можно;
➖ Если будущие читатели уже понимают масштаб данных (например, знают MAU продукта) и для них представляют интерес любые изменения — оторвать ось можно.

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

А в таких случаях лучше сохранять ноль:
➖ На графике больше одной линии — оторвав ноль, мы рискуем ввести читателя в заблуждение;
➖ Нам важны абсолютные значения (и читатели не знакомы с масштабом данных);
➖ Используется график с опорой на площадь (bar-chart, area-chart) — убирать ноль в этой ситуации категорически нельзя, физический смысл пропадет;
➖ Наблюдается значительное изменение метрики.

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

#датавиз

Недавно мой коллега Саша рассказал, что поддержка GA-Universal Analytics закончилась 1 июля, на смену ему пришла Google Analytics 4. А жаль.

В этот раз изменения совсем не косметические — меняется модель сбора данных.

Пользоваться GA4 я, конечно же, не буду, однако обращу внимание на open-source альтернативы. Все они self-hosted, что на мой взгляд правильно в перспективе развития продукта.

В списке ниже только бесплатные сервисы — альтернатив на подписочной модели гораздо больше.

➖ PostHog — наверное, самая известная и близкая по функционалу к GA платформа для продуктовой аналитики.

➖ Matomo — можно перенести старые данные из GA даже в self-hosted версию, что на самом деле очень круто (демо).

➖ Open Web Analytics — полностью бесплатный инструмент, который, помимо прочего, позволяет строить хитмапы вашего сайта. А это дорогого стоит! Но на мой вкус, сыроват (демо)

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

➖ Umami — простая и лаконичная альтернатива GA. Лично мне нравится тем, что все аккуратно укладывается на одну страницу (демо). Отлично подходит для начинающих.

➖ Ackee — по концепции очень похож на Umami, но еще и неплохо расширяется плагинами (демо).

➖ GoatCounter — достойная по качеству расчета альтернатива, однако есть неудобства в UI (демо).

➖ Plausible — легковесный инструмент, считается, что он быстрее GA. Могу отметить очень приятный UI и интересные фишки наподобие мониторинга почты или слэка (демо).

#инструменты

Смотрите, какая красота (автор).

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

Что не нравится:
➖ Как минимум, стоило разделить партии по рейтингу Эло — скорее всего, картинка для <1000, <1500 и выше была бы ощутимо разной;
➖ Неясно, что считается конечной позицией для короля — в случае победы, мата, пата. Из пояснения можно предположить, что здесь не только поражения;
➖ Неясно, что происходит с пешками, перешедшими в другую фигуру — автор не уточняет, как обрабатывался такой случай.

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

Инструменты: данные обработаны в R (rchess, bigchess), визуализация в ggplot2.
Датасет можно найти тут.

А если вы, как и я, из питоно-господ, для чтения партий есть отличная python-chess.

#датавиз #инструменты

➖ Субботний #датавиз.

Нарисовала связи между словами в тексте Daft Punk — Harder, Better, Faster, Stronger. Слов немного, так что рисовать такие отношения удобно и наглядно.

Я не люблю хордовые диаграммы в работе: из них непросто достать смысл. Однако в качестве арт-объекта они очень неплохи.

Инструменты: Python, визуал сделан с помощью библиотеки mne и доработан тонкой настройкой matplotlib.

Как это сделано: текст почищен, составлены биграммы (пары рядом стоящих слов). По биграммам составлена co-occurrence matrix и уже по ней построена диаграмма.

Опытный взгляд наверняка заметил, что график из прошлого поста выглядит необычно. Например, цепляет глаз, что темно-синим соединены слова, которые на деле не встречаются рядом.
​
Дело в выбранной цветовой схеме.

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

Таким образом, цветовая схема может серьезно поменять восприятие и не все они одинаково полезны.
⁠
Среди исследователей популярны такие колормапы как rainbow и jet — в ранних версиях матлаба «радужная» схема была стандартной, откуда перекочевала в matplotlib и многие другие библиотеки. Впоследствии их заменили на более удачные. Нам тоже лучше их избегать, чтобы не вводить в заблуждение читателей.

На тему восприятия цветовых схем проводились исследования [1]–[3], ссылки на полный текст оставлю в конце поста, здесь же приведу краткие итоги.

Глобально цветовые схемы делятся на четыре больших группы (тут можно найти много примеров применительно к matplotlib и производным от него библиотекам):
➖ Sequential (последовательные): используется один цвет разной яркости. Нужны для отображения изменений;
➖ Diverging (расходящиеся): градиент от одного цвета к другому. Нужны для выделения отклонения от медианы;
➖ Qualitative (качественные): наборы разных цветов. Сложны в работе, но подходят для разделения кластеров точек;
➖ Прочие: все остальные колормапы. Как правило, они нужны для конкретных случаев (например, gist_earth для рисования перепадов высот на местности).

rainbow и jet как раз относятся к последним.

➖ Там, где нужно визуально сравнить величины, будут работать цветовые схемы, упорядоченность которых интуитивно понятна. Самый простой пример — градиент от светлого к темному.
В "радужной" схеме порядок тоже есть, но он основан на возрастании длины волны, что не очень очевидно для большинства читателей.
➖ Наше зрение лучше воспринимает высокие пространственные частоты (число циклов изменения яркости на один угол зрительного поля) — проще говоря, чем четче изображение, тем лучше мы различаем детали. Следовательно, чем сильнее меняется яркость, тем лучше видны нюансы. Это хорошо видно на рисунке 2.

Здесь я никак не покрываю тему восприятия цвета дальтониками — об этом расскажу в другой раз.

Список литературы (номера кликабельны):

[1] Jamie R. Nuñez, Christopher R. Anderton, Ryan S. Renslow (2018). Optimizing colormaps with consideration for color vision deficiency to enable accurate interpretation of scientific data, PLOS one. doi: 10.1371/journal.pone.0199239
[2] Rogowitz, Bernice & Treinish, Lloyd. (1996). How Not to Lie with Visualization. Computers in physics. 10. doi: 10.1063/1.4822401.
[3] D. Borland and R. M. Taylor Ii. (March-April 2007) Rainbow Color Map (Still) Considered Harmful, IEEE Computer Graphics and Applications, vol. 27, no. 2, pp. 14-17, doi: 10.1109/MCG.2007.323435.

#датавиз

И, конечно, пример.

Как мы видим, jet подсветила резкие перепады там, где их на деле нет. Именно поэтому в matplotlib по умолчанию используется viridis.

💬 Пожалуйста, поделитесь в комментариях — что вы думаете о таких разборах?

➖ Субботний #датавиз.

Нашла на Kaggle датасет — Kaggle Machine Learning & Data Science Survey и нарисовала по нему Stanley-диаграмму. Опросник большой и интересный, но сегодня ответим на вопрос "Чем же занимаются эти ваши айтишники".

Датасет обработан, чтобы сократить число профессий до 4 категорий:
⏺️Analyst
⏺️Data Scientist
⏺️ML Engineer
⏺️Software Engineer

Можно заметить, что задачи между ролями ощутимо пересекаются.

Инструменты: python, графическая часть на plotly.

Нужно сделать поправку на то, что опрос изначально адресован людям, работающим с данными на постоянной основе. Если расширить аудиторию опроса на Embedded-разработчиков, картинка, конечно, поменяется.

Решила вынести лонгриды на понедельник.

Хочу поисследовать процессы в аналитических командах. Если сталкивались — присоединяйтесь к обсуждению в комментариях 💬

Понедельничный #фреймворк

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

➖ Сегодня поговорим о фреймворке RICE для приоритезации.

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

Это полезно делать и на этапе планирования АБ-тестов, если они пока не автоматизированы и проводятся руками.

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

Reach — охват (сколько людей затронет фича?);
Impact — влияние (прибыльность идеи, выраженная в денежном либо любом другом численном эквиваленте);
Confidence — уверенность в оценке охвата, влияния и трудозатрат;
Effort — трудозатраты (например, число часов, которое потратит разработчик).

Чтобы получить оценку задачи, нужно перемножить первые три фактора и поделить на трудозатраты.

Например, мы хотим оценить две доработки:
(1) добавить партнерскую кнопку на финальный экран регистрации
(2) исправить баг, который влияет на 5% клиентов и гарантированно не затронет остальных.
Для оценки MAU нашего продукта составит 5000 человек, ежемесячный прирост ~10%.

➖ Reach:

(1) Охват первой фичи можно оценить в 500 человек, при сохранении темпов прироста значение будет расти;
(2) Охват второй фичи составит 250 человек, он не изменится в будущем.

➖ Impact:

Здесь не получится привести влияние к единой размерности (в случае первой задачи эффект измерим деньгами, второй — лояльностью пользователей). Поэтому мы вольны придумать собственную шкалу.
Например, я буду использовать шкалу от 0 до 3, где 0 — отсутствие влияния, 3 — влияние на всю аудиторию продукта.

(1) Оценка первой фичи — 1.5. Влияние будет оказано на небольшой сегмент, но принесет прибыль и улучшит отношения с партнерами.
(2) Оценка второй фичи — 0.5. Она даст нам лояльность очень узкого сегмента аудитории, но совершенно не факт, что принесет нам прибыль.

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

➖ Confidence:

Этот показатель субъективен, но в конце концов, автор продукта ориентируется в нем лучше.
Здесь я буду использовать шкалу от 0 до 1 — показатель, насколько мы верим в необходимость фичи.

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

➖ Effort:

Можно оценивать в часах, можно в человеко-часах — зависит от распределения ролей в команде.

(1) Возьмем 1 неделю на проектирование и согласование, 1 неделю на разработку и внедрение, суммарно 2 недели;
(2) Потребуется 1-2 недели на разбор, 1 неделя на планирование, 1-2 недели на разработку, 1 неделя на тестирование, а также неизвестные на текущий момент сроки включения в релиз и раскатки. Суммарно от 4-6 недель.

Проведем оценку:

Фича 1: 500x1.5x1/2 = 375
Фича 2: 250x0.5x0.3/5 = 7.5
​
Как и любая методика оценки, RICE субъективна. Но с ее помощью можно навести порядок в бэклоге и убедиться, что команда работает на цели продукта.

➖ Субботний #датавиз.

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

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

Инструменты: python, matplotlib.

В комментарии приложу вариант с более долгой «экспозицией» следа и итоговую траекторию движения грузов.