🔫 JTBD в разработке дашбордов
Многие аналитики до сих пор смотрят на дашборд как набор визуализаций или аккуратно сверстанной витрины.
Я предлагаю вам посмотреть на него, как на продукт, который должен выполнять конкретные задачи.
Как формулировать эти задачи?
Для этого отлично подходит фреймворк JTBD (Job to be Done) из управления продуктами:
- когда происходит Х,
- я хочу Y,
- чтобы Z.
Я взял кейс товарища Колоколова - https://alexkolokolov.com/ru/gallery/sales_dashboard и мы со студентами курса раскритиковали проанализировали, для каких задач задумывался этот дашборд, судя по показателям и графикам.
Насчитали их 4:
1. Когда количество заказов снижается, я хочу понять, это проблема входящего потока или падение конверсиии, чтобы выбрать направление анализа.
2. Когда объём заказов или конверсия не устраивают, я хочу понять, на каких этапах воронки происходят основные потери, чтобы сфокусировать усилия на конкретных стадиях процесса.
3. Когда объём заказов или конверсия не устраивают, я хочу определить, какие причины закрытия дают наибольший вклад в потери заказов, чтобы работать с ценой, продуктом или процессом.
4. Когда объём заказов или конверсия не устраивают, я хочу понять, это проблема на уровне всей компании или конкретных отделов/менеджеров, чтобы работать с конкретными случаями.
Оказалось, что данный дашборд ни одну из этих 4 задач не выполняет...
Для начала в Miro мы собрали макеты, которые отвечают на одну из этих задач, но зато исчерпывающе. Получилось проще и без перегруза.
Скоро покажу, как мои студенты переверстают дашборд полностью. Вы сможете сравнить до и после, сказать свое мнение.
И помните: ценность дашборда определяется не красотой графиков, а тем, какие задачи он решает. И решает ли
