Антон Жиянов написал замечательный набор статей про проектирование интерфейса. Я попробовал применить описанные им принципы к 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 командам при внедрении и поддержке системы.

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

Условно я делю дашборды по решаемой ими задаче:
— Узнать что-то про определенную сущность (заранее знаю что хочу увидеть).
— Получить какой-то инсайт, не зная что именно ищу. Или сделать выводы, имея в голове определенный алгоритм поиска.
— Отслеживать операционные данные на «ежедневной» основе.

Шаблон «Страница сущности»
Задача: Узнать что-то про определенную сущность (заранее знаю что хочу увидеть)

Эта задача может быть в двух вариантах. Первый — когда сущность, которой вы интересуетесь можно определить в один клик (например, конкретный город из списка), или это какая-то сложносоставная сущность, для которой потребуется выделить несколько срезов (оборот продаж в определённом городе, определенного товара в определенный месяц, то есть потребуется применить несколько фильтров). Примером из обычной жизни будет поездка в другой город. Если вы турист и едете туда впервые, вы хотите узнать сводную информацию по этому городу и смотрите путеводитель — «страницу», где описана вся основная информация про этот город. Чтобы попасть на такую страницу вам было бы достаточно выбрать город из списка. Второй вариант задачи — вы уже были на каком-то курорте, но хотите посмотреть температуру воды за конкретные даты. Здесь вам понадобится выбрать и город, и даты, и саму метрику — температуру воды.

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

Рецепт: «лонгрид» или «сайт с закладками», в которых есть всё про выбранную вами сущность в разных разрезах. Первый этаж или вкладка с овервью, остальные с детальной информацией по каким-то разрезам. Основных фильтров мало и они живут в шапке дашборда, есть доп. фильтры на каждом этаже/вкладке для тонкой настройки. Интерактивность такого отчета лучше сделать средней и в основном с помощью фильтров. Если система позволяет делать асинхронную загрузку и якорные ссылки на отдельные этажи «лонгнрида», то я бы выбрал «лонгрид». Если система так не умеет (например, Табло), то лучше делать «сайт с вкладками», желательно умещая каждую вкладку на один экран (но и лонгрид можно делать, нужно смотреть конкретные кейсы). Классно иметь такие страницы на разные бизнес сущности и делать кросс-линки между собой.

«Лонгрид»

«Сайт с закладками»

Когда мы хотим изучить какой-то узкий срез и выбрать его в один клик не получается, то лучше использовать другой подход. Часто пример такого среза — сочетание метрика-«место»-время: хочу посмотреть прирост продаж год к году в городе Б за месяц X. В таком случае хорошо работает шаблон: «утром деньги, вечером стулья», когда мы просим пользователя сначала выбрать какие-то параметры и после этого показываем ему данные. Фильтры располагаем слева, справа результат (согласно направлению чтения). Пока пользователь ничего не выбрал, можно показывать общие данные по тоталу или другую полезную информацию, например топ-10 чего-то с наибольшим изменением к предыдущему периоду и т. п. Примером из обычного мира будет сайт с билетами в кино: вы выбираете фильм → время → место в зале.

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

«Утро деньги, вечером стулья»

 
 
Шаблон «Аналитический инструмент»
Задача: Получить какой-то инсайт, не зная что именно ищу. Или сделать выводы, имея в голове определенный алгоритм

Такая задача возникает, когда вы хотите исследовать какую-то область бизнеса, найти какие-то взаимосвязи и принять решение. Или понять как принятые ранее или планируемые действия повлияли или повлияют на бизнес.
В этом случае важно видеть общую картину и иметь возможность провалиться ниже для детального анализа. Такие инструменты подходят для задач, для которых дорого делать ML и подобные алгоритмы, но при этом «слепые» решения на интуиции будут неэффективны. Дизайн для таких инструментов, пожалуй, одна из самых трудных задач среди всех описанных в статье шаблонов и всегда очень сильно затачивается под задачу.

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

Ещё очень похожей задачей будет, если у вас в голове уже есть алгоритм, которым можно воспользоваться для того, чтобы сделать вывод. Тогда нужен или просто удобный инструмент, чтобы это сделать быстро и наглядно, или всевозможные инструменты what-if анализа. Их тоже очень класно показывать через визуализацию данных, особенно если вы следите сразу за несколькими сложными сценариями с несколькими переменными.

Рецепт (краткая версия): Разбираемся в бизнес-задаче и какими метриками описывается эта задача. Здесь важно идти от того, что происходит в реальности, к тому как это превращается в метрики и срезы. Если можем, то выбираем главные и вспомогательные метрики. Хорошо, если можем следить за изменением какой-то одной метрики, чтобы понять общий ход событий, а на остальные смотреть, если нужно прокопать причинно-следственные связи. Делаем несколько визуализацией в разных срезах. Чем мельче детализация, тем лучше (вместо средних продаж, показываем значения продаж каждого магазина и т. п.). Слева основные визуализации, справа доп. информация и различные срезы по основной метрике (если есть). Много интерактива — графики фильтруют друг друга, возможно проваливаемся в другие дашборды или показываем доп. графики и срезы при наведении. Сам «шаблон», по сути, не шаблон, а подстраивается под каждую задачу.

Рецепт (полная версия) — задачи такого класса ИМХО хорошо описаны в алгоритме Лаборатории данных Тани Бибиковой. Подробнее в статье на Хабре или на учебном курсе .

«Аналитический инструмент»

 
Шаблон «Приборная панель»
Задача: Отслеживать операционные данные на «ежедневной» основе

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

Рецепт: Разрабатывая дашборд для операционного мониторинга точно придется разбираться с иерархией метрик и выбрать что-то, за чем хотим следить в первую очередь. Важно давать контекст, а не только текущие значения (спарклайны с динамикой, значки приростов, средние и референсные значения). Хорошо работают регулярные структуры и small multiples, если пользователь отвечает за группу метрик. Такие отчеты должны быть наименее интерактивны, но могут вести на более детальные отчеты в виде «страниц сущностей» и т. п.

«Приборная панель»

Вместо вывода

Я постарался рассказать свои идеи, но конечно же они не покрывают все задачи и не могут являться стандартом. Можно смешивать их, они отлично работают в комбинации, а можно делать как-то совсем по-другому. Основная идея из серии «капитана очевидность»  — определяйте задачу вашего пользователя, стройте дашборды вокруг них и старайтесь при этом выделять повторяющиеся паттерны.