Сначала мы придумываем, потом – делаем. Звучит логично и безальтернативно. Однако на практике дашборд может строится не с нуля, а под заданный результат – конечную «картинку». Например, под слайд в презентации или набросок стейкхолдера «на салфетке», который в начале работы образно нарисовал своё видение результата, не погружаясь в детали и конкретику.

Частый случай – создание нового дашборда методом «клонирования», когда дублируют уже работающий дашборд. При этом изменяют состав данных для визуализации, наименования и значения, а также вносят точечные (вроде бы) правки в композицию и элементы управления.

Хорошо это или плохо – начинать работу с уже заданного конечного результата? Попробуем разобраться.

Дашборд по «классической» методике

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

Иллюстрация из https://theaiminstitute.com/innovation/the-design-thinking-process-optimized-for-b2b/

Иллюстрация из https://think360studio.com/process

Подробнее об этом можно прочитать в статье про проектирование пользовательского опыта или других публикациях.

Несмотря на вроде бы очевидные методику и процессы, часто возникают ситуации, когда разработка интерфейса проходит не «по учебнику».

Дашборд «хочу вот так»: почему выбирают и чем рискуют?

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

Рассмотрим этапы разработки в двух вариантах: с нуля и от образа результата.

Упростим картину с помощью условных блоков. Каждый из них обозначает объем работы и времени на проектирование. Это поможет нам наглядно показать, где и каким именно образом различаются подходы к созданию дашборда.

Ориентироваться будем на обширный, но, конечно, субъективный опыт. Поэтому если вам есть, что добавить или возразить, дополните описание в комментариях.

Каждый блок снабжён крайне условными ресурсными затратами - это квадратики соответствующего цвета.

Красные блоки - это риски. Они могут быть более сложными и вариативными (т.е. либо реализоваться, либо нет). Расшифруем те, что есть на схеме:

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

Когда доработка существующего решения не даёт лучших результатов

Разберем сложности разработки дашборда методом «клонирования» на примере реального кейса.

Дано. Есть работающий дашборд.
Он спроектирован для анализа запасов товаров в разных филиалах с разбивкой по месяцам. Пользователь может выбрать категорию товара и интересующий его город филиала.

На иллюстрации представлено состояние дашборда, когда выбрана «Категория 1» и город «Москва». Блоки в правой части отображают именно эти данные. Дополнительная (опциональная) задача пользователя – определить вид товара внутри категории, которого больше всего в запасах.

Задача. На основе этого дашборда сделать новый.

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

Решение. Адаптируем данные, ищем компромисс.
Вносить изменения потребовалось, начиная с заголовка дашборда. Он перестал вмещаться, когда добавили вторую кнопку. Пришлось уменьшить размер его шрифта.
На иллюстрации – состояние дашборда после выбора «Торговая точка 1» в легенде блока визуализации кольцевой диаграммы.

Дашборд, созданный по образцу с новыми данными и новыми задачами

На этом изменения и компромиссы не закончились. В значениях под кольцевой диаграммой вместо понятного показателя «% выполнения плана» пришлось сделать более короткий вариант «Факт». Его смысловая нагрузка не соответствует задаче – зато соблюден визуальный образ. Максимум, что было возможно в легенде – добавить отклонения «К плану» в процентах. Также здесь понадобилось сделать прокрутку, так как строк в новом дашборде больше, чем в оригинале.

В правом блоке, где отображаются изменения в течение времени, добавили горизонтальную прокрутку. Для нижнего блока она не так критична, так как пользователю нужны в основном только самые большие по модулю значения А вот в верхнем использовать её придётся регулярно, для того, чтобы увидеть значение по текущей дате, если она больше 12.

Ещё один значимый аспект, но не очевидный визуально. Пользователь высокого уровня не имеет возможности сравнивать результаты разных городов. Он может только выбрать нужный или «Все» – пункт, который недоступен для остальных ролей.

Из позитивных решений – визуальная индикация цветом. Акцентирует отрицательные состояния значений, в том числе в легенде диаграммы. Кроме того, появился показатель «План» в правом верхнем блоке «Результаты по суткам». Он наглядно показывает отклонения от заданного уровня продаж.

Вывод. Буквальное следование образцу в этом случае не привело к хорошему результату.

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

Допустим ли такой результат? В каких-то случаях, наверное, да. Хочется ли так делать? Очевидно, нет.

…или с чистого листа?

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

Например, спроектировать дашборд так, как показано на иллюстрациях:

Итог альтернативного процесса проектирования

Самое важное – выполнен ли план. Если нет – последовательно смотрим, где именно самые проблемные места.

Фильтры внизу крайнего левого блока дублируют действия на строках линейных диаграмм, позволяя выбирать нужные элементы двумя способами. Справа – вид дашборда для пользователя низкого уровня. Неактивен фильтр для выбора филиала и скрыт блок, показывающий значения филиалов.

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

Подведём итоги

Вернемся к общим вопросам и нашему анализу подходов.

Риски ошибок и сложностей в разработке, а также в работах по приведению данных из источника будут идентичными. Их можно вынести «за скобки».

А теперь – сопоставим блоки ресурсных затрат по обоим вариантам, описанным выше:

Каждый квадратик - условная единица ресурсных затрат

Всё просто: если никакие риски не реализуются, то первый вариант ("от образца"), очевидно, выгоднее. Однако, если хотя бы часть рисков себя проявят - то ситуация меняется на обратную; и чем больше и глубже будут рисковые "проблемы", тем более драматичным станет разрыв.

Какие общие выводы можно сделать?

В некоторых случаях вариант работы «от результата» оправдан, как мы увидели на примере. Если не возникают риски, описанные в таблице (либо какие-либо еще), команда экономит время и силы, создавая решение быстрее.

Однако перед тем как создавать дашборд таким способом, необходимо чётко представлять все связанные с этим нюансы. Даже если вы хорошо знаете сферу, автоматизируемые процессы, особенности платформы, стадии проектирования и разработки. Есть риск «сползания» команды в цикл доработок и согласований изменений.

Дополнительный риск – необходимость вносить изменения в макет, утвержденный на высоком уровне на стороне Заказчика. Повторять этот процесс обычно нежелательно, как и реализовывать решение, не полностью соответствующее этому макету.
Последовательная работа по методике выглядит более надёжным выбором. Рисков существенно меньше, но и затраты времени и денег на разработку будут больше (чем «оптмимистичный сценарий» по варианту 1, разумеется).

Невозможно рассчитать коэффициент «правильности» применения того или иного подхода. Всё зависит от конкретных условий работы команды. Так что универсальной рекомендации, увы, не получится.

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

Что первично – курица или яйцо? Создаем дашборд «с нуля» или от визуального образа результата