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

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

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

Видеоподкаст 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 комментария    4428   22 дн   пример

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

Записал подкаст с Николаем Валиотти — аналитиком и экспертом по работе с данными, автором канала 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

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

Записал подкаст с Александром Богачевым. Саша — автор канала Чартомойка и книги «Графики, которые убеждают всех».

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

Подборка проектов из подкаста — https://revealthedata.com/examples/digest/all/primery-rabot-aleksandra-bogacheva/

1:55 — Как попал в визуализацию данных
6:02 — Медицинская инфографика — про визуализацию в медицине
23:57 — РИА Новости — про метрики медийных проектов, выбор тем для проектов и упрощение визуализаций для медиа
1:00:51 — Спец проекты — про подходы к работе с проектом
1:15:05 — Чем занимается сейчас — чем вдохновляется
1:22:31 — Блиц

Пять классных работ в Табло

Готовлюсь к проведению Лабораторного курса — обновляю список классных примеров в Табло, которые буду показывать слушателям. Добавил в него ещё 5 работ.
 

Распределение земли по назначению в США
На этой визуализации показан «каждый» акр земли в штатах и зачем он используется. При этом супер уместно используется анимация, которая показывает разные срезы этого распределения: географически, в абсолютном или относительном сравнении по типам. Это работа Александра Варламова — дата-виз энтузиаста из Казани. Как он такое делает, можно послушать на его выступлении на дне открытых данных.

  

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

 

Поездки Такси в Нью-Йорке

На этой визуализации 3 дня поездок такси в Нью-Йорке, показана каждая точка поездки и её длительность. Ещё есть два POI — куда люди уезжают от Эмпайр Стейт Билдинг и из аэропорта Кеннеди. У этой визуализации только одна проблема — переиспользование цветов легенды для разных метрик на разных графиках. Это путает и является грубой ошибкой, но всё равно не смог не включить эту работу в список.

 

Уровень преступности в разных штатах США
Удачная реализация Camel plot (сам придумал, так как не смог найти как это называется) — графиков в которых ограничена ось Y, и если значение больше него, то оно наслаивается сверху.

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

В работе автор решает проблему сложности считываемости графика тем, что при наведении появляются обычные тайм-серии. На них ещё круто добавлено сравнение со средним по стране.

 

Я бы это задачу решал ещё более наглядно и добавлял бы что-то на подобии такой легенды:

 

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

Классные работы в Табло можно искать в галерее работ Viz of the Day. Ещё можно поискать работы, которые подают на Make Over Monday (сами работы можно искать в твиттере). И там, и там, к сожалению, приходится копаться с пинцетом.

Видеоподкаст с Наташей Степановой

Провели видеоподкаст с Наташей Степановой — программисткой и автором канала Визуализируй это!

Поговорили про её карьерный путь, программирование визуализаций в вебе и отличие svg и canvas.

1:02 — Карьерный путь
5:39 — Примеры проектов
24:38 — Про визуализацию в вебе
29:20 — SVG vs Canvas
35:30 — Стек для проектов
42:08 — За чем следит и с чего начать изучать визуализацию в вебе
46:47 — Блиц

Новая подборка крутых примеров

Продолжаю эксперимент с дайджестом классных примеров. Собрал ещё три работы, которые меня вдохновили на этой неделе. Дисклеймер, в этой рубрике не только новые работы, но и те, которые я просто увидел впервые. Поэтому тут будут и старые работы, но я не видел их в основных чатах по визуализации. =)
 

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

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

 

Самый кайф создатели проекта почему поместили в подвал сайта. Там можно выбрать конкретный матч и посмотреть модель стадиона и полные графики в разных разрезах. Это просто огонь, тот редкий случай когда 3D в самый раз, так как отображает реальность данных:

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

 

Топ футболистов по забитым голам

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

 

Неравенство зарплат мужчин и женщин в Англии
Гардиан визуализировали результаты отчетов компаний о неравенстве зарплат (да-да, такие отчеты обязаны сдавать крупные компании в Англии). Работа состоит из двух классных графиков: распределения и джой плота.

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

 

Ниже в статье joy-plot — график, названный в честь обложки альбома Unknown Pleasure группы Joy Division. Вот как бывает — графики получают имена! Мне этот график очень нравится, он даже у меня на стартовой странице сайта стоит )) Он классно подходит для этих данных, наглядно сравниваются распределения по разным индустриям и удобно сравнивать пики распределения. Обратите внимание, как точки с прошлого графика на этом графике стали областями — это классный приём: сохранили каркас (читатель с ним уже знаком), но при этом выбрали более подходящее визуальное представление (точки тут бы шумели и отвлекали от основной сущности визуализации — индустрии):

Ранее Ctrl + ↓