Проектирование взаимодействия

Проектирование взаимодействия

Мне кажется, что в последние годы наше коммьюнити было слишком сосредоточено на красоте и «эффективности» дашбордов.

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

Но при всём этом как будто не хватило внимания самому главному - пользовательскому опыту.

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

📍 BI - это не про графики

📍 BI - это про поведение системы

📍 А ещё я за продуктовый подход в развитии BI (и против «давайте просто ещё один дашбордик сделаем»)

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

Проблема большинства BI-систем в том, что их делают разработчики «как удобно им», а не «как понятно пользователю».

В итоге дашборд превращается в испытание на внимательность, а не инструмент бизнеса.

В чём проблема?

• дашборды вызывают высокое когнитивное сопротивление

• пользователи - не программисты (и не обязаны ими становиться)

• мы ориентируемся на задачи, а не на цели

• живёт подход «давайте заставим пользователя стать умнее»

Спойлер: он не работает.

Проектирование взаимодействия - это манифест против такого подхода.

Основные тезисы ПВ

▪️ Разработчики делают BI для разработчиков

Часто дашборд построен «как удобно разработчикам», а не «как удобно человеку, принимающему решения».

▪️ Взаимодействие в BI важнее графиков

BI - это не набор визуализаций.

BI - это среда взаимодействия с данными.

▪️ Ключевой инструмент - персонажи

Сначала понимаем, для кого система и зачем.

Пока вы не знаете, зачем человек открывает отчёт - вы не знаете, как его делать.

▪️ Пользователь ≠ самый технический человек в комнате

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

▪️ Не ломайте пользователя через колено

Не переучиваем табличкеров.

Для многих людей таблица - это способ мышления.

Если пользователю нужна таблица - сделайте лучшую таблицу в его жизни, а не «компромисс ради визуализации».

▪️ Интерфейс должен служить человеку, а не демонстрировать технологии

Не усложняйте.

Не перегружайте.

Каждая лишняя кнопка - минус к time-to-insight

(и плюс к «почему этим никто не пользуется?»).

По моим прикидкам, в крупных компаниях, где дашборды исчисляются сотнями и тысячами, количество мусорных отчётов может доходить до 30-40%.

И это, кажется, очень много.

Нам нужна переупаковка текущих практик.

Проектирование взаимодействия — это:

• процесс определения продукта, а не нотация к разработке

• изобретение таких взаимодействий, которые помогают пользователям достигать бизнес-целей, не мешая личным

• фокус на целях и персонажах

• определение внутренней логики продукта через внешнее поведение

И да, на всякий случай: ПВ ≠ дизайн интерфейса ≠ визуализация данных.

Персонажи - главный инструмент проектирования

Они одушевляют разработку и не дают проектировать «в вакууме».

Мы отвечаем на вопросы:

• зачем человек открывает дашборд

• какую цель он преследует

• какое решение должен принять

• что он сделает после того, как закроет отчёт

Сдвигаем фокус:

с самой разработки → на цели пользователей

Проектирование взаимодействия кладёт счастье в сердечко пользователей

и награждает BI самым важным продуктовым свойством - преданностью аудитории.

Когда BI спроектирован как продукт,

его начинают любить,

а не «терпеть, потому что надо».

В итоге

BI - это система принятия решений.

Она должна быть:

• простой, как дрова

• логичной, как хороший интерфейс

• надёжной, как привычка

И если дашборд понимает только его автор - это не аналитика.

Это хобби.

🚀 Продолжение будет

🦫 Всем дбобра