{ "version": "https:\/\/jsonfeed.org\/version\/1", "title": "Блог об аналитике, визуализации данных, data science и BI, заметки с тегом: ux", "home_page_url": "http:\/\/test.leftjoin.ru\/tags\/ux\/", "feed_url": "http:\/\/test.leftjoin.ru\/tags\/ux\/json\/", "icon": "http:\/\/test.leftjoin.ru\/user\/userpic@2x.jpg", "author": { "name": "Николай Валиотти", "url": "http:\/\/test.leftjoin.ru\/", "avatar": "http:\/\/test.leftjoin.ru\/user\/userpic@2x.jpg" }, "items": [ { "id": "147", "url": "http:\/\/test.leftjoin.ru\/all\/kak-pereverstka-pomogaet-prevratit-horoshiy-dashbord-v-otlichny\/", "title": "Как переверстка помогает превратить хороший дашборд в отличный", "content_html": "

<\/p>\n

В кастомных системах сквозной аналитики конечный продукт, с которым взаимодействует пользователь — дашборды. Он не видит хранилище, витрины данных, скрипты, а дашборды видит каждый день, поэтому важно сделать их не только функциональными, но и понятными. Не всегда удается сразу нащупать оптимальный вариант, и полезно вести работу поэтапно.<\/p>\n

Дело в том, что в современных BI-тулах, которые мы используем — в частности, в популярном Tableau — возможности кастомизации гораздо шире, чем может себе представить сотрудник, мигрирующий с excel-таблиц. Часто пользователь просто не знает, каким вообще может быть дашборд и как составить ТЗ.<\/p>\n

В итоге дашборд содержит огромное количество данных, но возможность их продуктивно использовать спрятана за фильтрами, визуальной сложностью, долгой загрузкой.<\/p>\n

Именно такая ситуация сложилась у нас в процессе работы с образовательным стартапом Refocus.<\/p>\n

Один из главных их дашбордов — обзор SLA (Service Level Agreement).<\/b> Его пользователи — руководители отдела продаж и сейлз-менеджеры. Именно здесь их интересует прежде всего скорость обработки входящих лидов в зависимости от ряда факторов, от источника лида до региона.<\/p>\n

Нормативное значение этого показателя для Refocus — 15 минут, значит, там, где он выше, есть потенциал для оптимизации процессов и роста выручки.<\/p>\n

Мы работаем над дашбордами итеративно:<\/b> интервью с пользователем — прототип — фидбэк — следующая версия — фидбэк, и так далее. Но в случае с SLA после утверждения финальной версии остались нерешенные аналитиками функциональные проблемы.<\/p>\n

У заказчика было желание оптимизировать дашборды и бюджет на это, так что мы предложили общую переверстку и подключили к проекту датавиз-эксперта.<\/p>\n

Версия 1: с чем мы работаем<\/h2>\n

Первая версия SLA-дашборда, которой некоторое время пользовался клиент, выглядела так:<\/p>\n

<\/p>\n

В фокусе три графика:<\/p>\n

    \n
  1. Скаттерплот по времени ответа<\/b> с момента получения лида.<\/li>\n
  2. Гистограмма по медианному времени ответа.<\/b><\/li>\n
  3. Гистограмма по средней длительности первого звонка<\/b> с лидом.<\/li>\n<\/ol>\n

    Справа — 15 фильтров, от региона и гранулярности до имени сотрудника, работавшего с лидом.<\/p>\n

    Сверху — много текста, поясняющего тонкости работы с фильтрами по времени.<\/p>\n

    Задача<\/h2>\n

    Представьте, что ваш технический бэкграунд испарился, и вы на месте пользователя: о чем вам говорят эти графики? Сколько кликов вам нужно совершить, чтобы оценить перформанс подчиненных в вашем отделе? Чтобы сравнить SLA для лидов из разных источников? Ясен ли текст-легенда?<\/p>\n

    А главное — есть ли у вас понимание, как сделать понятнее и что сказать исполнителю проекта?<\/p>\n

    У аналитиков в этой области может быть слепая зона — нам-то на картине выше все понятно. А в прямые задачи датавиз-спеца входит проинтерпретировать запрос пользователя в контексте существующего функционала и создать визуализацию на стыке предпочтений заказчика и здравого смысла.<\/p>\n

    Важно определить и причины этих проблем. Иногда ошибки — просто неудачная попытка выполнить запрос заказчика. Конечно, всегда можно отмести «плохой» запрос и сделать, как правильно — но тогда можно потерять важные для заказчика функции.<\/p>\n

    Проблемы этого дашборда:<\/b><\/p>\n