Задача может казаться понятной слишком рано
Представим обычный запрос:
«Нам нужен дашборд продаж».
Компания уже знает, что хочет видеть: выручку, план, динамику, регионы, менеджеров, продукты, маржинальность.
Каждый показатель выглядит уместным.
Но зачем, например, руководителю сравнение регионов?
Чтобы заметить территорию, которая не выполняет план?
Увидеть, где началось снижение?
Решить, куда направить внимание?
Во всех случаях на экране могут использоваться одни и те же продажи по регионам. Но роль этого сравнения будет разной.
Фраза «покажите продажи по регионам» описывает пожелание к будущему интерфейсу.
Она ещё не объясняет, зачем эта информация должна быть видимой.
Требование говорит, что хотят увидеть.
Задача объясняет, зачем это должно быть видно.
Подробность требований и ясность задачи — не одно и то же.
Особенно трудно заметить проблему тогда, когда все пожелания выглядят разумными.
Даже разумные требования могут вести в разные стороны
Владельцу бизнеса нужна общая картина.
Руководителю продаж — состояние плана и команды.
Маркетологу — заявки и конверсия.
Региональному руководителю — результаты своей территории.
Ни одно из этих требований не обязательно ошибочно.
Проблема появляется, когда они оказываются в одном дашборде только потому, что каждое по отдельности кажется полезным.
Тогда будущий экран постепенно превращается в место, где должны находиться все важные цифры бизнеса.
Но «важно для бизнеса» и «нужно именно здесь» — разные вещи.
Показатель может быть действительно ценным и при этом не относиться к задаче конкретного дашборда.
Полезное тоже может оказаться лишним, если отвечает уже на другой вопрос.
Даже собранные и согласованные требования не решают проблему, если между ними не появился приоритет.
Что должно быть видно первым?
Какой вопрос важнее остальных?
Если это не определено заранее, приоритет всё равно появится — уже внутри интерфейса.
Один показатель может отвечать на разные вопросы
Допустим, руководитель видит:
«Выручка на 12% ниже плана».
Сам показатель понятен.
Но зачем человек смотрит на него именно сейчас?
Он может пытаться определить, действительно ли ситуация требует внимания.
Или уже знает, что проблема есть, и ищет место отклонения.
Или видит, где возникло снижение, но ещё решает, нужно ли вмешиваться.
Показатель тот же.
Вопросы разные.
Поэтому даже правильно выбранный KPI сам по себе ещё не определяет задачу дашборда.
Его роль появляется только внутри вопроса, ради которого человек к нему обращается.
Сначала нужно понять, что остаётся неясным
Вернёмся к тем же −12%.
Что именно здесь пока неясно руководителю?
Есть ли реальная проблема?
Где она возникла?
Насколько отклонение существенно?
Нужно ли действовать сейчас?
Эти вопросы меняют будущий дашборд сильнее, чем кажется.
Если нужно только заметить состояние, может быть достаточно одного уровня информации.
Если требуется найти источник отклонения — понадобится другая глубина.
Если уже нужно выбрать дальнейшее действие — изменится и то, что должно находиться рядом.
Поэтому раньше вопроса:
«Что человек должен увидеть?»
возникает другой:
Что человеку должно перестать быть непонятным?
Пока проект строится вокруг того, что нужно показать, разговор естественно идёт к графикам, таблицам и показателям.
Когда проясняется сам вопрос, можно отделить необходимое от того, что лишь кажется полезным.
Но этого всё ещё недостаточно.
Важно, что изменится после того, как ситуация станет яснее.
Нужно ли вмешиваться?
Куда направить внимание?
Какое решение теперь можно принять?
Именно здесь появляется критерий, которого не было в первоначальном списке показателей: сколько действительно достаточно.
Достаточно — не значит показать всё
Почти всегда можно добавить ещё один показатель, разрез или сравнение.
Для каждого найдётся разумное объяснение.
Но необходимый объём нельзя определить отдельно от задачи.
Если руководителю важно установить только одно:
«Требует ли текущее отклонение его внимания?»
ему не обязательно сразу видеть всё, что компания знает о продажах.
Если нужно решить, куда направить ресурсы, понадобится большая глубина.
А вопрос о причинах снижения может потребовать уже отдельного анализа, а не ещё одного блока на том же экране.
Поэтому дашборд не обязан объяснять всё.
Он должен объяснять достаточно, чтобы стало ясно, что делать дальше.
Речь не о минимализме.
Сложная ситуация может требовать сложной системы.
Важно не показать меньше, а показать столько, сколько необходимо для конкретного вопроса.
Меньше — не цель.
Достаточно — цель.
Хороший дашборд знает, где остановиться
Но здесь возникает более трудный вопрос:
в какой момент информация начинает отвечать уже не на исходный вопрос, а на другой?
Сначала дашборд показывает состояние.
Потом помогает находить отклонения.
Затем от него ждут объяснения причин.
Следом — прогноза.
Потом — поддержки планирования.
Каждая из этих задач может быть важной.
Но если они начинают собираться в одном интерфейсе, проблема уже не в количестве графиков.
Перестаёт быть ясно, за что этот дашборд отвечает прежде всего.
Граница дашборда определяется не количеством доступных данных, а пределом вопроса, на который он должен помогать отвечать.
То, что остаётся за этой границей, может быть важным — просто для другой задачи.
Граница не обедняет дашборд.
Она сохраняет его смысл.
Когда смысл найден, форма перестаёт его искать
Только теперь вопрос к данным становится конкретным.
Не:
«У нас есть эти данные. Что из них можно показать?»
А:
«Какая информация действительно нужна, чтобы разобраться в этой ситуации?»
Иногда нужные данные уже есть. Иногда часть доступного массива к этому вопросу не относится. А иногда выясняется, что имеющаяся информация вообще не позволяет на него ответить.
После этого появляется основание для дизайна.
Ему больше не нужно определять главное вместо самой задачи. Он может сделать найденный приоритет видимым.
Когда смысл найден раньше формы, дизайн перестаёт искать ответ — он помогает его увидеть.
Можно знать показатели, выбрать платформу и даже представить будущий экран.
Но экран — уже форма ответа.
А до него должен появиться вопрос.
Что именно должно стать понятным?