Блог Ромы Бунина

о визуализации данных, дизайне BI систем и работе с Tableau

канал в телеграмме | подборки примеров | подкасты и видео 

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

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

Опрос в канале

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

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

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

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

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

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

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

Не найдя best practice по этому вопросу и не получив каких-то научных обоснований от коллег по цеху, решил подойти к задаче методом перебора решений.

Часть графиков придумал сам, часть посоветовали коллеги и читатели блога. Варианты:
— Линия факт — Ареа план
— Линия факт — Бары план
— Линия факт — Засечки план
— Бары факт — Засечки план
— Ареа факт — Линия план
— Линия факт — Линия план
— Линия факт — Линия план + заливка между линиями
— Линия факт — Ареа план + заливка между линиями

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

Линия факт — Ареа план

Мой исходный вариант. Больше всего в нём мне нравится, что линия остается фактом, как и обычные графики, где нет плана.

Плюсы:
— Срифмован с остальными графиками, для которых нет плана. Они просто линии, а тут мы добавляем «фон в виде» плана.
— Физично отображает выражение «факт идёт выше плана». План как гора на фоне, которую мы хотим достичь, факт выше «горы» или «ниже».
— Легко считывается динамика плана и факта по отдельности.
— Легко можно продолжить рисовать прогноз линией другого цвета.
— Легко реализуется и масштабируется в Табло.
— Можно заменять план на другие форматы «фона» — прошлый год, среднее по рынку и т. п.

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

Линия факт — Бары план

Очень похож на предыдущие график, по-сути просто делаем дискретным ареа. Поэтому все те же самые плюсы-минусы, но есть и дополнительные:

Плюсы:
— Можно подсвечивать конкретные даты по выполнению плана.

Минусы:
— «Рябит» малёк, когда много дат.
— Техническая заморочка с шириной баров при изменении скейла (Табло оно иногда такое Таблё).

Линия факт — Засечки план

Плюсы:
— Классно «зарифмован» основной график и график отклонений.
— Может работать с отрицательным планом.

Минусы:
— «Рябит», когда много дат.
— Настройка ширины тиков только ручная и будет плыть для разной ширины экрана.
— Хуже считывается сама линия плана.

Бары факт — Засечки план

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

Плюсы:
— Классно «зарифмован» с буллет-чартами и выглядит «физично» (похоже на заполнение прогресс-бара).
— Довольно классический и понятный формат.
— Можно делать акцент на «плохих» и «хороших» барах.

Минусы:
— «Рябит» малёк, когда много дат или спарклайны.
— Настройка ширины тиков только ручная и будет плыть для разной ширины экрана.

Ареа факт — Линия план

Это тот вариант, который мне мало нравится. Хотя он оказался более привычен, судя по количеству голосов. Самая моя большая к нему претензия, что по сравнению с теми графиками, где есть только факт (линия), почему-то меняется отображение факта на ареа-чарт.

Плюсы:
— «Зарифмован» с буллет-чартами, так как тоже заполняется как прогресс-бар.
— Довольно классический и понятный формат.

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

Линия факт — Линия план

На мой вкус самый беззубый вариант из всех. Вроде просто, но контраст между планом и фактом маленький и никаких особо преимуществ нет.

Плюсы:
— Просто.
— Хорошо считывать отдельно динамику плана и факта.

Минусы:
— Сложно отслеживать положение линий относительно друг-друга.

Такой вариант, кстати, предлагает стандарт IBCS, но с отметками в виде заполненных и не заполненных точек. Что-то как-то не айс. Для спарклайнов точно не подойдет.

Линия факт — Линия план + заливка между линиями

Этот вариант предложил один из читателей канала и показал вот такую ссылку на Натана Яу. Вообще вариант прикольный, но мне лично, очень сложно тут считывать само значение плана.

Плюсы:
— Аккуратный, мало чернил. Классно смотрится спраклайном.
— Акцент на «хорошие» и «плохие» даты.

Минусы:
— Сложно отследить линию плана из-за «перекручивания».
— Чтобы сделать «линию» плана, которая очерчивает область заливки, используется неприятный лайфхак в Табло.

Линия факт — Ареа план + заливка между линиями

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

Плюсы:
— Довольно хорошо считывается.
— Акцент на «хорошие» и «плохие» даты.
— «Зарифмован» с графиком отклонений.
— «Зарифмован» с обычными графиками фактов.
— «Зарифмован» с буллет-чартами.

Минусы:
— Нормально считывается динамика линии плана, но не идеально.

Анализ

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

Составил табличку сравнений вариантов и проставил плюсики.

Итого, решил взять последний вариант «Линия факт — Ареа план + заливка между линиями». Кажется, что это самый сбалансированный вариант из всех. Хотя не могу сказать, что он идеальный. У каждого из вариантов есть куча плюсов и минусов и этот показался мне наиболее робастным: он сохраняет факт линией, а подсветка сразу даёт понимание, что есть план, а что факт. При этом, легко увидеть, в какие периоды было отставание от плана, и такой вариант удобно реализовать в Табло.

П. С. Спасибо большое Саше Богачеву за обсуждения. И ещё многие написали в личку с идеями, тоже большое спасибо: Роман Зубарев, Егор Ларин и Павел.

Видеоподкаст c Ольгой Колчевой

Записал подкаст с Ольгой Колчевой. Большинство из вас знакомы с ней как с Solution Engineer в компании Tableau. Но в этот раз Оля представляла не компанию, а просто согласилась поболтать про развитие BI и о том как работается за рубежом.

Обсудили чем отличается найм в Европе, как попала в Tableau, как развивать Data Literacy в компании и почему Self-Service это хорошо.

Аудиоверсия
Текстовая версия — под видео (спасибо Наташе Shirosayuri!)

0:44 Карьерный путь
Карьерный путь был очень тернистым. После школы решила, что единственное, что я люблю — это математика и пошла на мехмат. Это место оказалось сильно не по мне, потому что школьная математика представлялась тем, что проводит параллели с реальным миром. Фундаментальная математика очень теоретическая, а я очень практический человек: всегда нужно знать, зачем это нужно. После окончания решила никогда не иметь ничего общего с математикой. Лучшее, что я там получила: меня научили учиться.

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

После университета пошла в магистратуру ВШЭ и стала искать работу на part-time, чтобы можно было совмещать. Так я попала в группу, которая занималась отчётом о прибылях и убытках департамента системного интегратора. Там был классный отдел, который занимался автоматизациями. Можно было договориться о задачах очень быстро, без бюрократии. Так я и автоматизировала половину своей работы. Поняла, что совсем далеко от математики, автоматизации и технологий мне не интересно. Очень понравилось, что я смогла часы ручного ввода автоматизировать до часа. Поработала там три года: решила, что хочу двигаться дальше.

Подруге предложили собеседование в телеком-операторе, а это был не её профиль. Она предложила отправить моё резюме. Оказалось, что там надо быть аналитиком, так что я рассказала про свой опыт, знание математики. Про SQL я знала только по опыту работы с Microsoft Access: sql, которые там генерируются. На собеседовании мне задачи дали на дом. Моих знаний sql явно не хватало, чтобы их решить, так что я сделала таблички в Access’e и посмотрела, какие получатся запросы. В итоге приняли, и пока согласовывали, я выучила sql. Я была единственным человеком с доступом к базе данных в нашем отделе, и она ещё строилась. Все задачи были мои, я могла быстро развиваться. Но в какой-то момент я упёрлась в потолок, потому что зависела от IT, который развивал эту БД. К тому же за год можно выучить все sql запросы, так что я вновь решила куда-то дальше идти.
Так я попала в команду, которая повлияла на меня больше всего — Lamoda. Я думала, что это интернет магазин из подвала. Там оказался красивый офис на несколько этажей и огромная команда. Я встретила своего будущего руководителя: уютная, замечательная девушка, в толстовке, которая села в стул вместе с ногами прямо при hr’е. Я решила: раз здесь такая атмосфера — я хочу здесь работать. Когда расспрашивали про знания, я поняла, что ещё и интересная. Проработала четыре года, и, кажется, никогда бы оттуда не ушла, если бы не переезд в Германию. Там я у разработчиков научилась очень многому. Для аналитика это было не очень важно, но если ты был готов впитывать, они всем делились. Благодаря всему этому я оказалась в Tableau. Они искали специалистов, так что я позвонила, прошла собеседование, и вот я здесь.

10:00 Как переехала и искала работу
У меня несколько лет была мысль попробовать за границу, но всё время было ощущение, что я не на том уровне.
Моя ситуация осложнялась тем, что я не знаю немецкого. Пул был изначально очень узкий. На разосланные 20 резюме мне ответили из четырёх мест, в двух я в итоге получила оффер, в третью компанию я уже не пошла на финальную стадию собеседования, чтобы не тратить ни своё, ни чужое время. Достаточно быстро это прошло: я переехала в феврале, а уже в июле вышла на работу. Поэтому если кто-то хочет поискать работу за рубежом, я бы рекомендовала попробовать и предложила бы обратить внимание на интервью.

12:55 Отличия при найме на работу
В отличие от России, на интервью совершенно другие вопросы и ты к нему по-другому готовишься. В России мне не пришло бы в голову досконально изучить сайт компании. Здесь по крайней мере на собеседованиях ожидали, что я буду знать о компании, кто её основатель, к чему они идут. Боле осознанный выбор работодателя не с точки зрения работы, а с точки зрения идеологии.

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

15:49 Чем занимается Solution Engineer в Tableau?
Я работаю с рынком России и у нас меньше специализаций. Многие компании в России не могут или не хотят говорить по-английски. Поэтому моя роль немного отличается от того, чем занимаются мои коллеги. Я немного и саппорт, и customer success manager, и учитель.

Если в идеале: когда компания решает, что она хочет купить Tableau, то должна понять, соответствует ли это её критериям. Я должна прийти и помочь им задать правильные вопросы, направить в нужном русле. Я не буду делать дашборды за наших заказчиков, но буду помогать находить ресурсы, информацию, сделать dashboard polishing. Иногда это специфическая информация, которую я знаю по опыту. Больше как техническая поддержка во время пре-сейла.

18:30 Какая культура в Tableau?

Мне нравится дух компании, потому что очень мало бюрократии, много открытости. Когда я пришла сюда, я увидела людей, которыми хочу стать, когда вырасту. Мы реально любим наш продукт. Например, каждый наш sales manager действительно сам делает дашборды. Вся наша компания пользуется Tableau.

Есть два подхода к отчётности. Один — когда тебе нужно ось сверху, подпись снизу, шрифт с завиточками и так далее. Аналитика для меня немного про другое: для получения понятного, удобного результата. Тут Tableau самый лучший инструмент, который может быть. Понимаю, что могут быть боли с форматированием. Иногда для реализации нужны hacks&tricks. Из тех дашбордов, что я делаю для своих дейликов, ни один не занял более четырёх часов. Я их дорабатываю время от времени, но они позволяют мне отслеживать то, что я делаю, поддерживать связь с клиентами.

22:53 Как управляют Tableau как продуктом?
Есть несколько потоков информации, которые отслеживают наши product managers.

Community forum, где голосуют за идеи. Есть такие, за которые проголосовало очень много людей, но они до сих пор не реализованы. Здесь скорее есть какие-то причины, например, технические. Идеи community форума проверяются, тестируются, прототпируются и включаются или не включаются в продукт. Если посмотреть на Tableau, как он развивался, то можно заметить, что он исторически делал всё не так, как стандартный BI. Всем это понравилось, но всё равно захотели туда включить стандартный BI.

Есть также стратегические моменты: большие интеграции с крупными вендорами, стратегические направления, которые решаются на высоком уровне. Важно понимать, сколько людей хотят эту фичу. Можно делать классные вещи, которые нужны 2% пользователей, но лучше это сбалансировать. Недавно услышала в подкасте термин: quality of life feature и это очень важно. Возможно мы, как профессионалы, научились уже обходить какие-то сложные моменты, но для массового потребителя они могут быть супер важны.

29:35 — Лайфхаки для развития Data Literacy
Я очень редко думаю о будущем, потому что очень многим нужно освоить те инструменты, которые уже есть сейчас. Понятно, что там будет машинное обучение, интеграции с AI более удобные и незаметные, возможно с голосовым интерфейсом. Я не знаю, идём мы в эту сторону или нет. Но считаю, что мы всё время хотим чего-то нового, в то время, как очень большое количество компаний живут в прошлом. Для меня важнее вместо новой фичи для 1% пользователей, чтобы поднималась грамотность работы с данными. Новые технологии — это хорошо. Но чтобы они не оставались сферическим котом в вакууме, нам нужно подготовить аудиторию. Повышать уровень образования, чтобы вне зависимости от того, что ты заканчиваешь, ты имел базовые знания по работе с данными.

Blueprint очень классный, но должна быть команда, которая может этим заниматься на full time. Это называется center of excellence. Я проработала с Tableau несколько лет до того, как стала сотрудником здесь, но я не знала очень многих вещей. Когда ты решаешь какую-то задачу, ты гуглишь, как её решить, но не смотришь на весь продукт в целом. Когда у тебя кроме этого есть другие задачи, таким самообразованием достаточно сложно заниматься. Поэтому в компании должны быть люди, главная обязанность которых — знать, как работают те инструменты, за которые компания платит. У этих людей должно быть меньше снобизма по отношению к пользователям, когда ты даже не пытаешься объяснить какие-то моменты. Потому что потом возникают какие-то заплатки, дашборды, которые потом перестают обновляться, если нет тех, кто за этим следит.

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

35:45 — Про необычные проекты и P&L кондитера
Самый интересный проект у меня идёт прямо сейчас. У нас есть пре-релиз сайт и там можно тестировать ещё не релизнутые фичи. Есть партнёр, который как раз занимается этим, даёт фидбек. Это всё связано с докеризацией Tableau-сервера и поскольку я с этим не очень знакома, интересно изучать и погружаться в эту тему.

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

Для меня сейчас неожиданно, если где-то нет BI. Недавно помогала девушке, с которой познакомилась в Instagram, она домашний кондитер. У нас возникло обсуждение о том, как считать свой отчёт о прибыли и убытках. В итоге мы сделали для неё google doc + tableau public для того, чтобы анализировать свою эффективность. Ей достаточно вводить свои данные, и это масштабируется до бесконечности.

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

41:41 — За чем следит
Количество потоков информации огромно. Есть несколько людей внутри и снаружи компании, за которыми я слежу, например Betany Liens??. Слежу за Сашей Варламовым и кучей ребят в комьюнити. С Егором Лариным постоянно обсуждаем какие-то другие вопросы, например, хотим сделать дашборд про Destiny 2.

У нас команда из 10 человек, они делятся чем-то в рабочих чатах, а я делаю для себя закладки. Я не всех людей знаю, на кого я подписана, но если кто-то из коллег поделился, значит это важно. Если вижу несколько полезных постов от одного и того же человека, то подписываюсь и слежу за его обновлениями.

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

45:40 — Блиц с Tableau Day: Self-service, AI, NLP
Self-service или reporting?
Однозначно self-service. Reporting должен быть, но когда он не имеет отношение к аналитике. Для этого ничего не нужно, все уже знают как делать его качественно. Аналитика должно быть self-service, потому что иначе это испорченный телефон. Даже бизнес-пользователи, возможно, не должны готовить данные сами, но должны понимать те, которые подготовлены для них.
Что мешает внедрять self-service?
Певрое: люди не хотят этого делать. Это как образование в стране: большая сложная задача. Если её никто не решает, то она не решается. Когда уже есть желание, тогда нужно внедрять правильные тулы и мотивировать студентов делать всё правильно. Иногда люди боятся, что всё будет автоматизировано и их заменят. Поэтому им нужно дать другой мотивирующий фактор. Я также видела, как желание высшего руководства ломается о сильное нежелание большинства.

Как будет влиять на BI NLP и AI?
Очень многие вещи, которые люди делают, нужно автоматизировать. Чтобы они занимались более важными, сложными задачами, где надо думать. Я люблю разные тулы, которые связаны с процессингом голоса. Считаю, что все эти классные достижения должны быть везде. Они не решат все вопросы, потому что человеческая экспертиза и интуиция незаменимы. Ещё есть фактор доверия к тому, что сделал AI. Например, мы сейчас включаем эти функции, пользователь может что-то замоделировать, но это не та математика, которую ты можешь проследить от первого до последнего шага и как-то проверить. Понятно, что я могу доверять data scientist’у, который написал эту функцию. Все ошибаются, это абсолютно нормально, но я хочу знать, как именно они ошибаются. Поэтому сложно доверять AI, который предоставляет тебе данные, и ты не можешь их проверить. Мы по-прежнему больше доверяем людям, чем машинам.

Что посоветуешь тем, кто хочет внедрять self-service?
Здесь у меня совет есть к тому, кто будет хоть что-то внедрять. Редко я вижу, что в компаниях есть конкретный список требований, чего именно хотят добиться внедрением нового инструмента. Ты хочешь, чтобы что-то стало лучше. Почему, как, какие у тебя задачи? Хотите что-то внедрить, определитесь, зачем это вам. Иначе вы тратите ресурсы, время, деньги фактически зря. Если вы не знаете, какой результат хотите получить, как вы поймете, что получили его? Важно определиться с целями, определить шаги к ним, подготовить пользователей, не навязывать ему это. С пользователем нужно говорить, объяснять, потому что self-service потребует их максимального вовлечения в процесс.

59:16 — Мини-блиц №2

  • Level of detail или table calculation?
  • Сама я больше использую первое, поэтому настойчиво пытаюсь себя пересадить на второе.
  • Extract или live?
  • Live.
  • Tableau Prep или Tableau Desktop?
  • Оба.

Вместо заключения
Очень рекомендую попробовать встать на роль консультанта, больше общаться. И заниматься саморазвитием. Например, я сейчас читаю литературу о том, как люди в принципе воспринимают информацию. Эти два совета не связаны между собой, но очень важны для меня.

Таблица или график? Как убедить заказчика

Читатель блога написал классный вопрос:
«В ходе работы приходится сталкиваться с заказчиком, который приемлет только таблички с множеством фильтров. На все предложения сделать покрасивее — отвечает отказом, говорит, что тогда потеряется функционал. К слову, в книге ~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.

Видеоподкаст c Кириллом Беляевым

Записал подкаст с Кириллом Беляевым — дизайнером из Риги и автором канала своего имени.

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

У Кирилла есть проект с логотипами-заготовками Pre-logo и ещё он делает очень крутой дизайн на заказ — примеры работ. Не реклама, искренняя рекомендация если вам вдруг будет нужен дизайн.

Аудиоверсия
Текстовая версия — под видео (спасибо Наташе Shirosayuri!)

0:50 Про самоидентификацию как дизайнера

Чаще всего называю себя дизайнером. Если уточнить, то графический, digital-дизайнер или интерфейсный дизайнер. Зависит от того, кому я это говорю, чтобы им было проще. Почти весь спектр дизайна, который не про среду и не про одежду. Всё, что касается графики в той или иной степени, чуть-чуть потрогал.

Про образование, мотивацию и становление

Когда учился в школе, было модно среди родителей пытаться куда-то направить. Это сейчас они уже понимают, что было бы лучше не мешать. Теория моих родителей была в том, чтобы я стал инженером, потому что у меня было хорошо с математикой, но я сильно споткнулся о физику. То ли из-за учителя, то ли потому что она мне просто не интересна была. Поэтому неожиданно в 9м классе я решил пойти в художку. Я как бы до этого в другие секции ходил, ну и школа была недалеко от дома. Случилось так, что в нашей группе из 7-8 человек разновозрастных была молодая преподавательница, которая как будто недавно университет закончила. Это было здорово: она не пыталась нас ничему научить, всегда пыталась сделать так, чтобы нам было интересно. Это сильно втянуло: мы занимались и линогравюрой, и карандашами, всем, чем угодно. Позже, наверное в 10 классе, нам открыли все окна и дали масляные краски (чего, кажется, в художках нельзя делать), мы там все обнюхались. Всё было просто отлично. Тогда я решил, что это здорово, потому что в этом есть какой-то драйв. Начал думать, куда поступать: не на художника же. Были 90е, художник однозначно был нищий человек, никаких вариантов. Быть нищим очень не хотелось.

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

На среду у меня не было опыта художественного опыта в объёмности, про моду меня отговаривали, что это сплошное нетрадиционно-ориентированное, так что остался графический дизайн, так что я пошёл туда. Ходил на подготовительные курсы, специалитет по старой программе: 5 лет учёбы и ещё полгода на диплом. Это было долго и скучно, но у нас были рисунок и живопись, которые преподавали в том числе и преподаватели из мухи? Эти два навыка, по прошествии многих лет, дают очень хороший бекграунд. Не могу иногда понять, что это работает, но благодаря этому я знаю, как цвета смешивать, например. Работает на уровне ощущений. Года два назад я начал ощущать этот вклад, до этого вообще не задумывался, не ощущал ни сама техника, технология или методика. Но потом я понял, что люди пытаются понять что-то про цветовой круг, а я знаю точно, что их как-минимум много, это не единственный способ, цвета можно по-разному сочетать. Так что я подумал: если для меня это очевидно, а они что-то пытаются понять, то всё-таки где-то я это знание получил. Так что взглянув в ретроспективу я понял, что это всё из университета.

После университета пошёл работать по специальности, в маленькую студию. Разослал резюме очень много куда, в том числе сделал наflash-e и отправил в студию Лебедева и получил ответ от Людвига Быстроновского, процитирую: «Простите меня великодушно, но я не буду ебаться с вашим flash-ом». Обидно, но что уж тут сделаешь. В следующий раз вместо непонятных форматов я отправлял огромный jpeg 5000х3000, на котором было много разных картинок: один файл точно пройдёт, что-нибудь да увидят.

Поработал два года в студии, пробовал сделать свою, после чего пошёл в бюро Горбунова учиться делать интерфейсы. Они тогда только начинались, поэтому казалось, что это более счётная, проектируемая история, в меньше степени здесь важно логотип делать красненьким и делать его больше или меньше. По крайней мере так казалось. В итоге, конечно, оказалось, что всё то же самое, просто не в логотипе дело, а в другом: контролы побольше, диапазоны поменьше. Тем не менее, из-за того, что это более инженерная история, коммуникация должна быть более структурная. Хотелось меньше договариваться и больше тратить время на производство дизайна. Следующим витком была визуализация, где, казалось, ещё больше инженерной компоненты, потому что здесь нет этого пользовательского опыта, нам надо данные визуализировать. То есть опыт есть, но по большей мере одинаковый: человеку нужно получить инсайт. Поэтому пошёл потом в лабораторию, после неё — в компанию, которая строила аэротрубы и там я занимался всем дизайном подряд: дешборды, айдентика, etc.

11:17 Это более творческая профессия или боле инженерная?

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

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

14:32 Что нравилось в data visualization, как в него пришёл?

Я занимался dataviz’ом с той задачей, о которой говорил [получить инсайт]. Есть, конечно, и более простая визуализация данных. Или всё, что связано с New York Times и другими изданиями, где журналистика данных и визуализация используется как часть повествования. Практики у меня в этом очень мало. Там, допускаю, не один пользовательский опыт, потому что там визуализация не продукт, а, скорее, иллюстрация: у тебя огромная статья, ты хочешь через неё что-то донести, эмоции, факты, показать, какую огромную работу ты проделал и твой вывод точно верный. Это уже другой опыт: не нужно давать пользователю инструмент, чтобы он свои инсайты искал, надо показать, что мы проедали работу. Или была визуализация, как беженцы из Африки бегут в Италию, огромные маршруты, тут нужно просто чтобы масштаб сработал, и ты ужаснулся тому, как люди в кровь ноги стирают. Про такую визуализацию я не очень много знаю.

В Лаборатории делали в основном для финансов, для науки, где почти в ста процентах случаев нужно дать инструмент. Визуализация в центре, нет какого-то повествования. Если и есть, то это какая-то маленькая кнопка infо, спрятанная в сбоку. Это какая-то штука на весь экран. И ещё есть контролы, и здесь отличие от журналистики данных в том, что там это какие-то простые один-два ползунка, которыми точно все смогут воспользоваться. Если мы можем сделать, чтобы оно работало по скроллу — это ещё лучше. Для финтеха, например, так не получится: у нас один экран, он может даже не скроллится. Куча интерфейсного интерфейса, данных, которые ты препарируешь. Весь опыт пользовательский на уровне интерфейса, а не на уровне визуализации данных. Сложно отделить в какой-то момент, но я бы как-то так делал.

22:39 Как сочетать интерфейс и визуализацию, как сделать, чтобы пользователь понимал интерфейсные элементы в самой визуализации

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

История про управления, кажется, больше касается графиков, которые один на экране. Дешборд это когда больше одного элемента: таблица, фактоиды, график, или два основных. А когда там один scatterplot, то можно добавлять интерфейс, потому что мы будем управлять эти точками.

Про паттерны проектирования, разница между интерфейсами в визуализации данных и вне её, лайфхаки для тех, кто делает сложные интерфейсы для бизнеса

Посоветовал бы начать с кривой обучения. Когда человек в первый раз открывает Facebook или Twitter, то с первого раза ему нужно понять, как этим пользоваться. С бизнес-инструментом хочется сказать, что это не Facebook, люди же будут с этим работать, но дешборды носят другим людям, поэтому на них я бы всё же смотрел, как на Facebook. Это вершина айсебрга бизнес-платформы, и вот она, в плане интерфейса, должна быть такой же простой. Там будет много информации, без неё он не сможет даже существовать. Хочется, чтобы взаимодействие с этой информацией было как можно проще, возможно, через скролл, минимум простых интерактивных элементов. И на этот инструмент смотрят 2-5-10 минут. Дальше есть более глубокие, за которыми человек проводит 15-20-30 минут подряд, можно делать сложнее: меньше скроллов, больше фильтров. И так вплоть до интерфейса Bloomberg’а, в котором люди сидят днями, смотрят в один экран, в котором происходит непонятно что. Всё закодировано, потому что на экран выведено всё в один клик, но функций так много, что мы не можем уже словами писать, всё сокращено до аббревиатур и иконок. И это нужно, чтобы сделать быстро какую-то свою задачу, возможно будут учиться этому несколько лет, но оно того стоит. Ну вот на одной стороне он, а на другой даже не Twitter, он кажется слишком сложным. Какой-то просто новостной портал, где ничего кликать не нужно, просто скроллишь ленту и всё. Это почти всегда на время завязано, здесь ещё важно про непрерывные итерации. Поэтому при проектировании интерфейса пытаешься его на эту шкалу приземлить, чтобы прикинуть примерно уровень сложности. Потом, конечно, живые пользователи, тестирование.

27:05 Есть ли какие-то интерфейсные хаки, как сделать онбординг максимально эффективно

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

Что касается видео и документации, то весь мой опыт достаточно скверный. Но недавно я видел видео, которое рассказывал какую-то простую штуку, но было сделано как клип из 90х. Ты не можешь оторваться, ты его посмотрел и уже хочешь-не хочешь, но знаешь, как это работает. Не важно, насколько скучно или сложно то, что человек должен посмотреть, если там будет какая-то интересная обёртка, парень в кепке это будет рассказывать, или петух с оторванной головой, который будет спотыкаться на каждом контроле, выпадать. Это точно посмотрят. Конечно, дороговато в производстве, но есть много энтузиастов, которым нравится это делать. Здесь можно отделить содержание и форму: форма должна помочь мне здесь остаться на этом видео, а содержание оно и есть. Люди точно знают, что в мануалах много полезного и хорошо скорее всего написано. Они по большему счёту уверены, что смогут найти всё, что им нужно, но это всё равно сложно. И эмоции ещё. И если это разработчик, то он много мануалов читает: надо разбираться в языках программирования, sql-ях. Он уже зачитался мануалами, можно уже котиков полистать? А ты тут ему и делаешь мануал с котиками. Это работает для Tinkoff, журнал который для бизнеса, то для внутреннего инструмента, который никто снаружи не увидит, делать что хочешь можно.

32:21Примеры работ

Вот формат промежуточный между визуализацией, как ты её себе представляешь, и чем-то журнальным. Это карта музея недалеко от Риги. Изначально она выглядела так:

Это карта с реалистичными домиками, милая по стилистике и вся в цветных цифрах с огромной легендой. И это всё на А4.Это музей под открытым небом, он достаточно большой: здесь привезённые со всей Латвии дома поселений разных эпох. Они сгруппированы по цветам по регионам: ближе к Беларуси и России одни племена жили, ближе к морю другие, и у них были свои особенности. Снизу сами эти группы по цветам размечены. Из-за того, что это А4, музей большой и ты ходишь по нему долго, первое, что происходит: ты складываешь карту пополам и начинаешь её туда-сюда переворачивать, что неудобно. Так же неудобно сличать цифры по цветам и с легендой, в которой цвета нет. Меня это очень раздражало и я хотел понять, можно ли это сделать нормально. Я попробовал, мне кажется, у меня получилось.

Я её упростил и выбросил часть текста, который для меня, как для посетителя, не нёс никакой информации. Там были какие-то дополнительные сведения, год реконструкции ещё добавлен, например. При этом он есть всегда на самом домике. Для навигации дом реконструкции — лишний. Также попробовал привязывать то, что близко расположено, усиками. В итоге собрал на А4, распечатал на А5, и стало удобно пользоваться. Здесь используются все эти приёмы про подачу информации, цветовое кодирование, но это не совсем визуализация, конечно. Скорее предоставление информации. Информационный дизайн.

Если говорить про махровую? визуализацию, то здесь больше подойдёт этот пример.

Это график, мы его ещё вместе делали, о том, как произошла «оцифровка» профессии и изменения в зарплате и часах, для США. Она что-то показывает, но в моей голове больше похоже на data art. Выглядит здорово, но сходу понять сложно. Так что мы достали данные, пошли смотреть, как можно сделать лучше. Вспомнили про эти гантельки, много экспериментировали, в итоге получилось вот так:

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

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

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

Вот эта штука вообще примитивная. Есть такие графики и они чудовищно непонятные:

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

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

45:11 Почему решил вернуться в классический дизайн?

Поскольку я пришёл в визуализацию из дизайна, мне кажется я её с точки зрения прошёл, как игру. Она с точки зрения графического представления имеет какое-то конечное представление. Более того, вся эта конечность вцелом в четырёх книжках Тафти описана. То есть этому можно всему научиться, пройти и дальше уже начинается история про журналистику данных: это не про дизайн, скорее про сторителлинг. Можно было туда пойти, но поскольку я этим занимался в Лаборатории, у нас там даже направления такого не было. Подумал, в новостное агентство идти? Нет, наверное, люблю удалённо работать, а они так не умеют. Так что в ту сторону нет. А если в сторону науки и создания новых типов визуализации, это ещё одно направление в моём представлении, то оно требует большего погружения в статистику, в анализ, более технические вещи. Была возможность в лаборатории туда немного погрузиться, я понял, что это интересно, но для меня конкретно трение высокое. Поэтому я решил, что за единицу времени буду больше делать того, где трение меньше. То есть не захотелось выбирать самый сложный путь. При этом сейчас, если что-то в интерфейсах нужно, я радуюсь, что у меня этот опыт есть: сразу понимаю, где нужно что-то сделать, где нет. Например, когда говорят, что надо визуализацию сделать, можно остановиться на трёх фактоидах. Ещё есть такое направление, как инфографика, где больше иллюстрирование: надо показать на карте какой-нибудь маршрут, например. Тоже визуализация, но не данных, а пути. Само по себе понятие визуализация достаточно широкое: с одной стороны есть 3D-визуализация, с другой есть визуализация данных. Мы делаем что-то видимым. Можно было пойти в какое-то такое иллюстрирование, но на тот момент проектировать те же интерфейсы мне казалось интересней. Может и вернусь, это же так: видишь что-то прикольное, делаешь. Ещё и рынок, если говорить про СНГ, он смешной.

Единственная мотивация для дизайнеров идти в BI — много денег. За ней можно идти. Но тем не менее, для дизайна это конечная область, ты там как дизайнер всё перепробуешь, найдёшь лучшие сочетания.
Если представить, что ты очень прагматичен и при этом быстро осваиваешь такие специфичные штуки как Tableau. А он достаточно странный, это и не код и не борд, непонятная вещь, сходу сложно представить, на что похож. Вот если вспомнить эти ощущения фантомные от моих первых заходов в Photoshop и 3ds Max тоже: сходу не поймёшь. При этом интересно, что и в Photoshop’e и 3ds Max’е можно скрипты запускать. Порог входа высокий. Нужно иметь быстрое усвоение странных вещей для того, чтобы разобраться, дойти до какого-то уровня и потом выйти из этой истории. Здорово, если кто-то так сделает и расскажет остальным, сколько можно на этом поднять. И ещё посчитает, сколько он входил, потому что мне кажется, что для дизайнеров вход будет дороже, чем для инженера.

53:38 Про профисточники в графическом дизайне или UX

На начальном уровне стоит брать книжки классические, например Раскин, Тафти. Старые советы бюро про интерфейсы и визуализацию. В начале следить за кем-то конкретным бегать не надо. Когда ты на уровне middle или выше, кажется, ни за кем не получается следить, потому что сегодня студия N делает классно, а завтра — нет. И сидеть, следить за ней.. Был Тафти, все следили за ним, а он начал искусством заниматься. Можно переключиться вслед за ним, но если тебе визуализация интересна, тебе эти камни не сильно помогут. Можно искать крупицы смысла в его текста, но… За всё время у меня много чего перестроилось, единственное, что осталось неизменным, это Бирман. Единственный стабильный источник информации, на который можно рассчитывать: там не будет больше определенного процента флуда, будет всё ещё что-то интересное, полезное, метко сформулированное. Бывает, что ты много чего знаешь и понимаешь, но сказать не можешь. А у него есть такое полезное свойство: он умеет формулировать. Я видел его TikTok’и, не знаю, зачем они мне, но это такой показатель адекватности: если он может оценить свои силы так, чтобы там появиться, релевантно, значит он на месте. Как только я вижу ребят, которые бегут за остальными в Youtube, возникает вопрос: а вы там ничего не забыли, в своих 99-х в интернете?

Ещё скажу, чтобы люди ходили на курсы. Прекрасно понимаю, что они дорогие, поэтому предлагаю капать на голову работодателю, спрашивать при устройстве на работу: сколько курсов в год мы проходим? Не «проходим ли», а «сколько». Потому что по моему опыту это хорошая встряска, переупаковка всего, что ты знаешь. Я очень рад, что на курсы Ли попал не когда только начинал, а уже чуть ли ни на уходе из лаборатории. То есть я уже делал сложные вещи, у меня не было в этом потребности, но ещё раз всё это пересобрать и вспомнить базу — супер. Когда ты уже достаточно хорошо всему научился и вспоминаешь азы, они более широко раскрываются. Вещи из первой самой простой книжки Тафти, когда я их прокручиваю в голове, замечаю, насколько оно многомерно раскрывается. Понимаешь: незачем на треды смотреть, надо просто раз в год вспоминать всю классику и ходить раз в год на курс бюро или лабораторию. С Тафти ещё полезно, потому что это не наш родной язык, поэтому если ты развиваешь английский, со временем прочтение Тафти делает его более насыщенным. Но интенсивы Лаборатории для junior designer я бы не рекомендовал. Они слишком интенсивные для новичков, ты мало усваиваешь, расстроишься, что потратил деньги. Лучше уж на уровне pre-middle. Либо искать курсы длиннее.

1:02:31 Блиц

Три базовых навыка графической вёрстки?

  1. Работа с пространством, то есть когда у тебя есть текст и белая область вокруг, ограниченная листом или экраном.
  2. Пройти курс про шрифты, чтобы увидеть список ужасных шрифтов и выкинуть их. Оставить себе 5-10 нормальных, это можно один раз сделать и жить с ними. На начальном этапе можно даже не понимать, почему шрифт плохой или хороший, можно узнать у кого-нибудь список, ограничить себя им и остальные забыть
  3. Google it — всё надо гуглить. Сейчас можно нагуглить любой контекст, даже не понимая языка. Найти можно вообще всё, перевести, даже если ты не знаешь, как это люди обычно используют, было это или нет, потому что умея это, можно и шрифты нагуглить нормальные, и инструкции по работе с пространством. В общем, это самый главный навык любого специалиста, у которого есть компьютер или телефон.
  4. В случае с визуализацией, хорошо пойти разобраться в цветах, палитрах, принципах триад, сочетаний, найти для себя color brewer, чтобы просто знать, что есть готовые палитры, потому что в визуализации много возлагается на цветовое кодирование, это самое сильное и часто используемое кодирование. Иногда даже говорят, что другие не надо использовать, потому что они намного сложнее. Чтобы не использовать все оттенки серого или понимать, когда данные уже вышли в следующее измерение и тебе нужно вводить цвет или работать на уровне оттенков.
    Пространство, шрифт, цвет — это база. У графического дизайнера дальше бы пошли ещё формы, но для визуализации они нужны в последнюю очередь.

Figma или Photoshop?

Если говорить о визуализации, то Figma. Если про графический дизайн в целом, то оба. Сейчас важнее что-то сделать и получить approve от реального мира, и Figma позволяет получить это быстрее. Чтобы быстрее понять глубину кроличьей норы, то лучше Photoshop. Чем раньше ты её поймёшь, тем быстрее развеются иллюзии и станет интереснее. Иногда кажется, что дизайн скучно — просто посмотри, что люди в фотошопе делают и реши, насколько это скучно.

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

Шрифты с засечками или без?
Для визуализации без. Мой опыт больше о бизнесе и науке, где много данных, много всего, там часто кегль нельзя сделать большим, поэтому с экраном проще считывается без засечек. Во всём остальном как угодно, можно и Twitter сделать с засечками круто. Очень интересно, что всегда об этом спрашивают, но никто не говорит: шрифт без засечек или а-ля Comic Sans? Хотя, по-моему, это тоже две большие величины. Или категория шрифтов, которая scripts называется. Это просто шрифт, как узкий или широкий. Для интерфейса широкий сложно: будет плохо вмещать. Засечки примерно из той же категории.

Три любимых шрифта?
Есть шрифт Suisse Int’l который разработали швейцарцы, его люди, ничего не знающие про дизайн, назовут Arial’ом или Helvetica, но он немного другой. Им я могу сделать много всего, он похож на мой дефолтный. И, наверное, всё. Много в памяти шрифтов, названий, но выделить сложно. Они же все по времени меняются. Хороших много. Назову один, хотя подозреваю, он тоже скоро из категории любимых уйдёт, потому что надоедает.

Шпроты или шаверма?
Имеешь ввиду Рига или Питер? Конечно, Рига, если бы был Питер я бы уже вернулся. А так, наверное, ни шпроты, ни шаверма, хотя она по-вкуснее будет.

Видеоподкаст c Дмитрием Аношиным

Записал подкаст с Дмитрием Аношиным — инженером данных Amazon и автором канала Инжиниринг Данных и основателем проекта Datalearn.

Разговор получился довольно философским, много про развитие специалиста и путь Димы. У Димы очень интересный подход к построению карьеры — супер креативный и проактивный. Тот случай, когда построение нетворкинга явно дает свои плоды.

В этот раз снова ничего не смотрели, поэтому можно просто послушать подкаст. Но! В прошлый раз, когда я спрашивал про аудио-подкаст или видео, мне написала коллега, что ей бы вообще подошёл бы текст. Я подготовкой текста заниматься не готов и она решила мне с этим помочь. Если вам нравится текстовый формат — пишите и может сделаем это постоянной практикой. Так что за конспект, все спасибки Наташе Shirosayuri! Текст ниже под видео.

0:00 Как дела, чем занимаешься?

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

2:01 Почему сейчас сложнее войти в профессию?

Я начинал десять лет назад, и мне повезло — я занимаюсь одним и тем и развивался вместе с индустрией. Когда я начинал было IBM SPSS, Business Object, MIcroStrategy, Cognos, Oracle BI. Сейчас инструментов очень много, поэтому разобраться в них по-началу может быть сложно. Ещё очень много проблем с вордингом — все пишут в вакансиях по-разному и не понятно, чем именно будешь заниматься.

6:03 Как ты переехал и искал работу?

У меня была идея фикс — что нужно переехать. Я активно занимался нетворкингом — писал всем вендорам и пытался найти связи, хотел очень хотел уехать в Tableau в Австралию, но не получилось. Здесь важный момент, что мой подход: я пытаюсь сразу, если у меня доступ куда-то есть, максимально общаюсь везде, пишу и т. п. Например, я находил какие-то интересные презентации, которые потом переделывал, переписывал, публиковал от себя. Для своего блога кривого что-то писал. Даже заводит инстаграм аккаунт @tableau_official (у них его тогда ещё не было) и довольно долго его вёл, это было где-то в 2012-2013.

Ещё, скажем, я не могу назвать себя экспертом в чём-то одном. У меня такой подход: я пытаюсь максимально широко брать, там-сям, самую суть выдёргивать из этого всего и как-то использовать. Я даже иногда людям завидую, которые занимаются, например, только Tableau: они могут классные вещи делать. Я его поверхностно знаю, могу быстро разобраться и, если надо, научиться, но красивый дашборд я не сделаю. Я знаю, где посмотреть, но сам сделать с ходу не смогу.

13:36 Аналитик — специалист на все руки, или должен хорошо знать только какую-то область?

Сразу скажу, что западный рынок очень сильно отличается. Думаю, это связано с тем, что у компаний нет таких жёстких условий экономить на всём деньги. Доходит вплоть до того, что есть специалисты в командах, которые занимаются только визуализацией данных. Человек умеет круто нарисовать дашборд в Tableau. И он при этом очень востребованный. В Америке, в Европе ты найдёшь работу со знанием только Tableau, но это всё равно тебя загоняет в рамке. Например, я в Amazon’e практически каждую неделю провожу собеседования, не важно, data engineer, BI-engineer. Там огромный список компетенций. Они хотят видеть, чтобы человек sql знал, моделирование, хотя оно ему даже и не нужно и в Amazon’e его не используют. В общем, если компания маленькая — то нужно быть специалистом на все руки, если большая — то, круто быть узким спецом, но это ограничивает твой поиск.

22:03 Чем занимается data engineer в Amazon’e?

Я хотел рассказать про data engineer’a, откуда это появилось. Потому что я всегда был BI-разработчиком. Как я говорил, когда я начинал работать там было всего 4 разновидности вакансий. И мне нравилось быть BI-разработчиком, потому что на вопрос, а это кстати полезный ответ на собеседовании, когда у тебя спрашивают: «почему ты любишь быть BI-разработчиком?», — ты легко отвечаешь: «А я между IT и бизнесом». Когда переехал в Канаду, работал здесь BI-разработчиком и искал только такую позицию, откликнулся в Amazon на эту вакансию, а когда меня взяли на работу, у меня титул был BI-разработчика, а роль в системе — дата инженер. Я внимания тогда не обратил, первые два года вообще не парился, кто такой дата инженер.

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

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

В целом у для Data Engineer’s в Амазоне есть три типа заказчиков: bi-разработчики, software development engineer и команды machine learning .

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

Другая популярная история — с командами разработчиков, software develompent engineers. Если они строят кастомный интерфейс (вместо табло делают свой фронтенд), то им нужны данные. Задача дата-инженера — приготовить им данные и автоматизировать, чтобы их приложение смотрело куда-то. Он может использовать какой-нибудь sql-engine, и тебе надо подготовить всё для этого. А потом приходит какой-нибудь менеджер и говорит, что пользователи захотели новую фичу. Например, искать по тексту. Или, сказали, что когда ищут по тексту, то слишком долго грузится. Значит надо сделать так, чтобы грузилось быстрее. Либо подобрать другой движок, либо другую технологию. Тебе, как дата-инженеру, надо отвечать на это всё. С разработчиками работать сложнее всего потому что у них свой подход на создание пайплайнов, хранилищ данных, если у них вообще термин такой есть: у них структуры данных, структуры хранения. С ними больше всегда конфронтаций: кто прав, кто виноват, как делать. Это не лично моё мнение, я говорил с другими дата-инженерами. Все говорят, что это тяжело. В Amazon’e сейчас все эти историю про работу с разработчиками-программистами идут в мой опыт. Так что когда меня будут спрашивать про сложные ситуации: «Опишите ситуацию, когда вы с кем-то поспорили или случилась сложная ситуация, как вы из неё выбрались?» Я сразу расскажу, что была команда разработчиков, мы с ними совсем не могли сработаться, но в итоге нашли общий язык. Они говорили про свои concern-ы, я слушаю их, мы пишем архитектурные документы, они их ревьюируют, оставляют комментарии, я отвечаю. Получается коллаборация. Это мегакейс, как мы работаем с программистами.

Последний кейс — это работа с data scientist и machine learning. С data scientist’ами работать лучше всего. Хуже всего с программистами, Когда мы работаем с data scientist, они в нас души не чают, потому что они фокусируются на проблемах. Берут dataset’ы, например, в питоне начинают что-то делать, чтобы посчитать модель. У них возникает проблема номер 1: на ноутбуке не хватает памяти чтобы взять большой dataset, им надо это масштабировать. Они не знают, как в облаке дать разрешение на доступ из другого аккаунта. Ты им помогаешь, и они нереально благодарны. Получается, задача дата-инженера когда он работает с data scientist’ом: убрать road blockers для ребят и помогать отправить модель в production. Таким образом, дата-инженер — это человек, который поможет data scientist’у решить все эти проблемы. Например, в моей новой команде нет других дата-инженеров, нет других разработчиков ПО, есть только data scientist’ы и product-менеджер. Таким образом, у меня теперь полная свобода действий.

43:34 Как у вас организован Data Governance?

В Amazon’e со скоростью, с которой мы двигаемся и с какой фичи сыпятся, — мы мало этим занимаемся. То есть главный concern — безопасность и качество данных, чтобы показатели были правильные и как ты собираешься проверять эти данные. Я считаю, что data governance это комплекс. Туда входит и безопасность, и качество, то есть ты про это переживаешь. Ещё один аспект — это data catalog. То есть у тебя есть модель данных, описание. В Amazon’e есть внутренние инструменты, где ты можешь хранить каталог данных. Но поему опыту, несмотря на то, что тебя часто спрашивают про модели данных, у тебя по факту не всегда хватает времени их сделать. Это не моя сильная сторона, теоретически и про необходимость я знаю, но это как бы trade off для меня. Либо скорость, либо надёжность.

47:05 Какие есть рекомендации для разработки модели данных?

Тут всё просто, я всю логику храню в базе данных. Я должен показывать в Tableau именно тот кусок, который будет удобно работать в Tableau. Если им не подходит длинная или широкая таблица, значит я такую таблицу не должен делать, иначе неразбериха потом будет. Мне будет лучше сделать несколько таблиц. Мы часто делаем в Tableau data blending, и ты можешь уже и разную гранулярность показывать на конкретном view, на конкретном дашборде можешь сджойнить и показать.

Я не фанат огромных таблиц. Они классные, когда у тебя row level data, когда ты в staging эти данные собираешь, пусть они будут любого размера, но когда ты будешь уже показывать метрики, то я постараюсь максимально разграничить. В таблице должны лежать метрики, аддитивные друг с другом. Иначе, если мы туда положим разные вещи, и будем думать, что бизнес-пользователь знает, как с этим работать, он обязательно сделает всё наоборот. Моя задача таким образом: максимально разложить на кусочки.

51:28 Экстракт или live

Про это я могу рассказать. Я же был Tableau администратором. Когда мы работаем с редшифтом, у него есть проблема concurrency — сколько одновременных запросов он может обрабатывать. Если у тебя много пользователей и ты им даёшь live-connection, получается, что каждое твое изменение фильтра dimension автоматически отправляет запрос в хранилище данных. Что не круто. Для меня в Tableau всё очень просто: если я могу создать экстракт — я создаю экстракт. Сам по себе экстракт становится кэшем, который позволяет нам работать с Tableau во фронтенде, чтобы не ждать запросы. Я всегда делаю экстракт, и ставлю на расписание.

Экстракт состоит из двух частей: сколько работает запрос, и может ли Tableau сервер его переварить. Если не может, значит надо уменьшать историю, увеличивать агрегаты. Если ничего не помогает, переключаюсь на live. Но live это история о трёх dimension’ах и двух показателях для огромного dataset’а. Потому что, например, у нас есть одна маленькая таблица, в ней миллиарды строк, парень пример показывал про 21 миллиард строк, и у него там несколько метрик в dimesion’ах. Когда он меняет фильтры, то Tableau за несколько секунд всё меняет. Я в книге писал главу big data для tableau, там очень простой подход: если у тебя big data, то Tableau делает рендеринг, отображает результат, а весь heavy lifting идёт в твой data engine, хранилище данных, hadoop, не важно что. Даже спорить не надо «нужно»/«не нужно», потому что мне кажется это best practices: экстракт для всего, только если работаете с огромными данными, то тогда live-connection.

57:49 Блиц

— Озеро или облако?
— Озеро.

— Редшифт или Вертика?
— Редшифт.

— Редшифт или Кликхаус? Ну вдруг, мало ли.
— Редшифт. Ну, если бы я был в России, я бы взял Кликхаус. Хотя я с ним не работал, но как я понял он для продвинутых дата-инженеров, надо брать Кликхаус, Аэрфло и Редаш. Или, если есть деньги, Табло. И всё это на Питоне сделать! Тогда ты такой модный образцовый хипстер.

— Виктория или Бостон?
— Виктория.

— «Сиквел» или «Эскьюэль»?
— «Сиквел».

Миро-дискуссию про стайлгайды

Андрей Демидов из ДатаЙоги пригласил пообщаться на счет стайлгайдов. Поговорили про то зачем нужны гайды, из каких частей они должны состоять и как лучше их внедрять в организации. А вот миро доска с ссылками и картинками. По-моему получилось очень интересно — Андрей задавал отличные вопросы и было весело! 🤘

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

Команда ДатаЙоги сейчас готовит слайды, а у меня есть первая пилотная версия книги-шаблона, которую можно скачать и посмотреть. Если вы готовы помочь или есть идеи, что стоит улучшить  — пишите мне или Андрею.

Алгоритм разработки дашборда — Dashboard Canvas

Дмитрий Аношин создал и ведёт проект datalearn.ru  — бесплатные курсы о том, как стать инженером данных или аналитиком. Он рассказывает про инструменты и том как работать с данными. Мне очень нравится его инициатива — это классно делиться знаниями и реальными примерами. Я провёл вместе с ребятами вебинар на тему разработки дашбордов и рассказал в первый раз на большую аудиторию про свою разработку — Dashboard Canvas. Это yet another framework, но чем больше им пользуюсь, тем больше верю что это очень полезная инициатива.

Вот запись вебинара и материалы:

Ссылки и материалы из вебинара:
Презентация и шаблон в pptx лежат в Миро
Интерактивная статья про пай-чарты
TUG про стайлгайд

Почему визуализация лучше табличек

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

И вот тут начинается история про визуализацию. Медсестра измеряла давление каждые 5-7 минут и следила за динамикой. Результаты она записывала «в столбик» на бумажку. Давление — нестабильный показатель и от измерения к измерению оно довольно сильно пляшет. Даже людям советуют измерять несколько раз и потом усреднять. Медсестра говорила, что нужно где-то 4 измерения, чтобы понять среднее значение.

Через полчаса измерений врач спрашивает: «Ну как, не падает?». Они с медсестрой смотрят на бумажку, думают-думают, и говорят: «Ну вроде нет, но не понятно, надо ещё последить» и не могут ничего решить. Я понимаю, что в критическом варианте, они бы увидели что давление падает даже в табличке. Но, представьте, насколько было бы проще, если бы у них был график. Ниже реальные данные за час наблюдений, каждое наблюдение — пара точек. Видно, что если брать скользящее среднее за 4 измерения (линии), то давление на самом деле немного падало, а потом пришло в норму. Синее— систолическое давление, оранжевое — диастолическое.

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

А измеряют давление собакам оказывается на хвосте! 🐶

 2 комментария    5972   3 мес   пример

Видеоподкаст с Николаем Валиотти

Записал подкаст с Николаем Валиотти — аналитиком и экспертом по работе с данными, автором канала Left Join и основателем компании Valiotti Analytics.

Было интересно по-общаться про построение полного цикла аналитики: от построения dwh до визуализации и поиска инсайтов. Поговорили про роль аналитики в компании, современные open source продукты на примере одного из проектов и обсудили будущее аналитики.

0:37 — Про карьерный путь
3:21 — Как пришёл в аналитику
8:05 — Что нравится в профессии
10:00 — Какие вызовы есть в профессиональной сфере
14:16 — Как выбрать: новые и модные технологии, или старые и надежные
19:05 — Пример проекта по построению полного цикла аналитики
30:51 — Как будет развиваться область BI
33:35 — Про Self-Service аналитику
38:33 — Про роль аналитика в компании
43:17 — Будущее аналитики
50:02 — Про построение хранилища данных и разработку dwh
55:25 — Блиц

Интерфейсы в 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 командам при внедрении и поддержке системы.

Видеоподкаст с Андреем Демидовым

Записал подкаст с Андреем Демидовым — дата-йогом, предпринимателем и основателем datayoga.ru

Беседа получилась длинной — немного «обо всем», но при этом очень вдохновляющей и легкой. У Андрея, как у какого-то мага — за пазухой куча интересных проектов, активностей и очень классный взгляд на сообщество и бизнес в целом. Отдельно рекомендую последнюю работу — общение с пилотом про дизайн приборной панели самолёта.

0:37 — Про карьерный путь
9:35 — Как появилась идея сделать связь между духовными практиками и визуализацией данных
14:15 — Текущие проекты
30:10 — Какие вызовы есть в профессиональной сфере
32:20 — Визуализация для изучения иностранных языков
40:51 — Как будет развиваться область BI
48:27 — Self-Service vs Reporting
[58:55 — Нужны ли письменные описания и интерпретации результатов анализа на дашборде
1:06:53 — Сложные vs Простые визуализации, подходы к проектированию UX
1:15:04 — Жесткие стандарты или рекомендации и принципы
1:21:05 — Блиц

Лайфхаки Tableau #2

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

Видеоподкаст с Александром Варламовым

Записал подкаст с Александром Варламовым, автором блога Coul Blue Data и классного профиля в Табло Паблик.

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

0:43 — Карьерный путь и как пришёл в дата-арт
11:17 — Что нравится в работе
16:25 — Дженерализация vs Специализация в BI
22:08 — Self-service vs Dashboard factory
28:06 — Какие навыки нужны BI специалисту
31:19 — Пример работы Саши с разбором в Табло
50:29 — Зачем следит и где вдохновляется
53:30 — Зачем вести Паблик и заниматься дата-артом BI специалисту
55:47 — Блиц

Лайфхаки Tableau

Последние четыре года я много работаю с Табло. Оно стало основным инструментом визуализации, который я использую как для работы, так и для фана. До этого все визуализации я прогал на js, например, что-то такое вакансии с hh.ru, сравнение стран, бюджет США. Визуализации на js — это потрясающе гибкие и шустро работающие штуки, но время их создания иногда зашкаливает. Хотя библиотеки типа d3.js и фреймворков типа vue.js помогают делать их быстрее, но всё равно это каждый раз долго (может я просто не программист, но даже классные программисты, с которыми я работал, так быстро делать визы не могут). Поэтому теперь я работаю в Табло, из всех WYSIWYG инструментов он самый гибкий и позволяет делать классные работы довольно быстро, а иногда очень быстро.

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

Я никогда не хотел делать много контента про изучение инструмента, так как для этого существует отличные учебные материалы на официальном сайте Табло. Чтобы понять основы и познакомиться с интерфейсом этого хватит за глаза. Но при этом есть много мелких и интересных лайфхаков, приёмов и т. п., которые делают жизнь с Табло намного приятнее. Их я собираю по всяким статьям, видео, от коллег, а что-то придумываю сам. Хочу попробовать запустить формат коротких видео с лайфхаками на каких-то бизнесовых примерах. Видео будут ориентированы на тех, кто уже работает с Табло. Лайфхаки буду собирать и из интернета, и из своей практики. Сколько времени мне сэкономила, например, фича перетягивания даты через правую кнопку мыши или дублирование поля с ctrl/cmd, а узнаешь про это обычно случайно.

Вот пилотный выпуск, пишите идеи и пожелания.

0:00 — Сортировка по значению за последний месяц с помощью nested table calcs
4:04 — Оформление спарклайнов при помощи reference lines
7:12 — Highlighted таблица с подсветкой по одной метрике из measure values

Ранее Ctrl + ↓