Проектирование взаимодействия Мне кажется, что в последние годы наше коммьюнити было слишком сосредоточено на красоте и «эффективности» дашбордов. Мы много говорили про типы графиков, оси, подписи, шрифты, отступы, документации, сбор обратной связи, гештальт, Тафти, AI, архитектуру хранилища, семантический слой, автоматизацию - и, конечно, про сакральный вопрос: в какой цвет красить коню яйца. Но при всём этом как будто не хватило внимания самому главному - пользовательскому опыту. Проектирование взаимодействия - это практика, которая фокусирует процесс разработки вокруг пользователя и его целей. 📍 BI - это не про графики 📍 BI - это про поведение системы 📍 А ещё я за продуктовый подход в развитии BI (и против «давайте просто ещё один дашбордик сделаем») Задача дашборда - помогать человеку мыслить и принимать решения, а не демонстрировать архитектуру данных и глубину вашего дата-лейка. Проблема большинства BI-систем в том, что их делают разработчики «как удобно им», а не «как понятно пользователю». В итоге дашборд превращается в испытание на внимательность, а не инструмент бизнеса. В чём проблема? • дашборды вызывают высокое когнитивное сопротивление • пользователи - не программисты (и не обязаны ими становиться) • мы ориентируемся на задачи, а не на цели • живёт подход «давайте заставим пользователя стать умнее» Спойлер: он не работает. Проектирование взаимодействия - это манифест против такого подхода. Основные тезисы ПВ ▪️ Разработчики делают BI для разработчиков Часто дашборд построен «как удобно разработчикам», а не «как удобно человеку, принимающему решения». ▪️ Взаимодействие в BI важнее графиков BI - это не набор визуализаций. BI - это среда взаимодействия с данными. ▪️ Ключевой инструмент - персонажи Сначала понимаем, для кого система и зачем. Пока вы не знаете, зачем человек открывает отчёт - вы не знаете, как его делать. ▪️ Пользователь ≠ самый технический человек в комнате Люди приходят в дашборд решать задачи, а не разгадывать вашу модель данных как квест. ▪️ Не ломайте пользователя через колено Не переучиваем табличкеров. Для многих людей таблица - это способ мышления. Если пользователю нужна таблица - сделайте лучшую таблицу в его жизни, а не «компромисс ради визуализации». ▪️ Интерфейс должен служить человеку, а не демонстрировать технологии Не усложняйте. Не перегружайте. Каждая лишняя кнопка - минус к time-to-insight (и плюс к «почему этим никто не пользуется?»). По моим прикидкам, в крупных компаниях, где дашборды исчисляются сотнями и тысячами, количество мусорных отчётов может доходить до 30-40%. И это, кажется, очень много. Нам нужна переупаковка текущих практик. Проектирование взаимодействия — это: • процесс определения продукта, а не нотация к разработке • изобретение таких взаимодействий, которые помогают пользователям достигать бизнес-целей, не мешая личным • фокус на целях и персонажах • определение внутренней логики продукта через внешнее поведение И да, на всякий случай: ПВ ≠ дизайн интерфейса ≠ визуализация данных. Персонажи - главный инструмент проектирования Они одушевляют разработку и не дают проектировать «в вакууме». Мы отвечаем на вопросы: • зачем человек открывает дашборд • какую цель он преследует • какое решение должен принять • что он сделает после того, как закроет отчёт Сдвигаем фокус: с самой разработки → на цели пользователей Проектирование взаимодействия кладёт счастье в сердечко пользователей и награждает BI самым важным продуктовым свойством - преданностью аудитории. Когда BI спроектирован как продукт, его начинают любить, а не «терпеть, потому что надо». В итоге BI - это система принятия решений. Она должна быть: • простой, как дрова • логичной, как хороший интерфейс • надёжной, как привычка И если дашборд понимает только его автор - это не аналитика. Это хобби. 🚀 Продолжение будет 🦫 Всем дбобра