Роль (или её отсутствие) дизайна в аналитике

Если вы недавно общались со мной, следите за мной в Twitter или принимали мой заказ в Wendy’s, вы, вероятно, знаете, как сильно я ненавижу традиционные дашборды. Мой отец, психотерапевт, работает со мной, чтобы добраться до корней моего воспитания, которые привели к этому глубоко укоренившемуся чувству.

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

При создании программного обеспечения заставить пользователей действительно использовать продукт — задача не из легких. Малейшее трение может заставить пользователя отказаться от использования. Добавьте достаточно трения в любой продукт, и пользователи и вовлеченность резко упадут. Как аналитики, мы интуитивно это понимаем. Мы постоянно измеряем удержание, когорты и вовлеченность в нашем бизнесе.

Эти принципы также применимы к аналитике. Чем больше трения в аналитике и чем меньше мы фокусируемся на пользователе, тем меньше будет использоваться наш результат. Поэтому мне интересно, почему в области данных дизайн-мышление часто так отсутствует?

Почему нам не хватает дизайн-мышления в аналитике?

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

1. Команды данных думают в рамках ограничений своих текущих инструментов, а не идеального пользовательского опыта.
2. Традиционные дашборды стали настолько товарными, что существует восприятие, что любой может создать хорошие.
3. Существует убеждение, что аналитика заканчивается на визуализации данных, а не на пользовательском опыте.
4. Существует общее заблуждение, что общий вид и ощущение не имеют значения в аналитике данных.
5. Заказчики часто просят "дашборд", когда на самом деле им нужно что-то другое (с большей функциональностью).

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

Одно из решений, которое я предложил в 2019 году, — это нанять менеджера по продуктам данных, что, похоже, набирает обороты. Но что бы этот человек на самом деле делал?

Я попытался суммировать решения этих сложных вопросов в таблице чрезмерно упрощенных "не делай" и "делай":

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

Полноценный аналитик и аналитические приложения

Аналитик, который может собрать необходимые данные, преобразовать их в формат, готовый для аналитики, и понять и проанализировать их, является невероятным ресурсом для вашей команды. Аналитик, который также может создать пользовательский опыт вокруг этого, неостановим.

Если вы подумаете о рабочем процессе аналитика, простой процесс может выглядеть примерно так:

1. Первоначальный исследовательский анализ и разовые запросы
2. Моделирование данных в dbt
3. Создание визуализаций данных
4. Написание тестов/мониторинг производительности

Но вы также можете рассмотреть возможность добавления следующего в ваш рабочий процесс.

1. Создание пользовательских историй и сценариев использования: Работайте с конечным пользователем, чтобы понять, почему именно им нужны данные и какие решения они должны принять. В общем, не просите их определять решение. Это ваша работа.
2. Создание каркасов и пользовательских потоков: Очень быстрый набросок пользовательского опыта может быть представлен для обсуждения. Это может дать действительно отличную обратную связь о том, как пользователь может в конечном итоге использовать данные.
3. Создание пользовательского интерфейса: Освободитесь от традиционного дизайна дашбордов и реализуйте дизайн, который действительно решает проблему.

Чтобы реализовать весь потенциал "полноценного аналитика", мы должны применять принципы дизайна как часть наших рабочих процессов. Мы должны изменить наше мышление от создания традиционных дашбордов к созданию ориентированных на пользователя аналитических приложений.

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

Вот несколько примеров:

Традиционные дашборды	Аналитические приложения
Созданы для общих сценариев использования	Целенаправленно созданы для конкретных сценариев использования
Стандартные взаимодействия с дашбордом	Интерактивные на основе желаемого рабочего процесса
Фиксированная, статическая компоновка	Динамическая компоновка, определяемая логикой
Каждый элемент — это плитка	Элементы могут быть сгруппированы и целенаправленно расположены
Фильтры глобальные	Пользователи имеют предпочтения и свои собственные настройки по умолчанию
Минимальный жизненный цикл разработки программного обеспечения	Сильный SDLC для повышения доверия пользователей
Внешний вид и ощущения игнорируются	Индивидуальный внешний вид и ощущения, соответствующие продуктам компании
Низкая планка производительности	Высокая планка производительности

Пример: Приложения для прогноза погоды

Давайте рассмотрим одно из оригинальных аналитических приложений: прогноз погоды.

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

Вот несколько примеров от AccuWeather и решений, которые они позволяют мне принимать:

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

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

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

Например, серферы хотят получить другую информацию. В конечном итоге они могут захотеть получить общее "Серфить или не серфить" рекомендацию. Кроме того, пилоты никогда не смогут просто полагаться на AccuWeather. Эти сценарии использования требуют своих собственных ориентированных на пользователя, целенаправленно созданных опытов.

Недостающий элемент головоломки

Хотя процесс проектирования может помочь вам создать лучший аналитический результат, в аналитическом стеке все еще отсутствует часть, которая позволяет реализовать истинно ориентированный на пользователя дизайн.

Как бы вы сегодня создали приложение, похожее на прогноз погоды?

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

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