Павел Шерер, продюсер, #аналитик, продуктовый дизайнер мобильных и веб-сервисов, партнёр в Цифровой артели Eleven
Под дизайном в России принято понимать что-то исключительно визуальное. Тогда как на самом деле дизайн — это про процесс создания в целом. Дизайн начинается уже в тот момент, когда только рождается идея нового продукта. От того, насколько качественным он будет, напрямую зависит успешность бизнеса.
Проблема
К сожалению, многие #дизайнеры и #проектировщики не подходят к дизайну комплексно просто потому, что от них этого не требует сам бизнес. Провести исследования, спроектировать пользовательские сценарии, получить результаты тестирования — и всё, можно приступать к макетам и реализации. И только потом, в самом конце разработки, у кого-то из маркетинга возникает мысль о необходимости добавить аналитику в продукт. При этом оказывается, что архитектурно отслеживать то или иное пользовательское действие внутри сервиса нельзя, и несчастным программистам приходится «пилить костыли». К чему это приводит, понятно: усложняется развитие продукта, его техническая поддержка, ухудшается #UX. Всего пара таких моментов могут в несколько раз увеличить стоимость внедрения новой фичи и существенно снизить быстродействие интерфейса.
Чтобы не быть голословным, приведу пример.
Был почти готовый сервис по поиску определенных промышленных объектов. В сервисе была карта с маркерами, которые при изменении масштаба объединялись в кластеры (такие кружочки с цифрами). Маркеров было много, создание кластеров оказалось очень прожорливым процессом, который съедал половину оперативки и порой наглухо вешал браузер.
Решили делать кластеризацию на стороне сервера, а заодно и половину логики туда перенесли. А когда выяснилось, что действия пользователя на карте нужно отслеживать (да еще обязательно с привязкой к каналу привлечения), разработчики развели руками. Пришлось интегрировать аналитику и на сервере тоже, формировать дополнительные запросы, увеличивать время отклика карты и так далее. При этом, разумеется, пострадали и архитектура, и пользовательский опыт.
Решение
В идеале дизайн должен идти нога в ногу с аналитикой. Но обычно под аналитикой дизайнеры (проектировщики) понимают преимущественно анализ пользовательского поведения, осуществляемый на этапе проектирования. В лучшем случае сюда включается бизнес-аналитика. А про обычную веб-аналитику, например, чаще всего забывают. Не говоря уже о более глубоких уровнях вроде комплексного отслеживания каналов и конверсий.
При этом нет ничего сложного, чтобы в процессе работы получать от маркетологов и аналитиков информацию о том, что именно им необходимо будет отслеживать в новом продукте, и просто включить это в скоуп документации. Хотя бы в виде простой функциональной диаграммы:
Разработчики, получив такие данные, смогут более грамотно спроектировать архитектуру. Маркетологи уже с самого начала будут понимать метрики, делая развитие продукта более эффективным. А дизайнеры (они же проектировщики) получат более стабильный и позитивный пользовательский опыт.
Подводные камни
Однако мир не идеален. А #бизнес тем более. Иногда на этапе дизайна маркетологами и не пахнет, а дизайнер берет на себя функции и бизнес-аналитика, и проектировщика, и штатного психолога. В таком случае брать информацию о том, какие события нужно отслеживать, неоткуда. Казалось бы, неоткуда.
Но по факту нормальный дизайнер знает про основные технические ограничения платформ, равно как и про главные целевые действия своих пользователей. Нет ничего сложного в том, чтобы на базовом уровне заложить отправку основного пользовательского пути в аналитику, сформировать примерную воронку и добавить в самое ее начало информацию о канале привлечения нового юзера. Хотя бы на уровне диаграмм.
Резюмируя
Разумеется, во всём нужна мера. Стоит помнить, что от количества отправок данных во внешнюю систему аналитики чаще всего зависит ее стоимость, то есть отправлять всё подряд (мол, маркетологи потом разберутся) точно не стоит.
Кроме того, на этапе разработки рекомендуется создать универсальную систему триггеров, на которые можно вешать различные действия (включая ту же отправку событий в аналитику). Так, если потом понадобится отслеживать какой-то новый показатель, особенных проблем это не вызовет.
Грамотно настроенная на старте #аналитика позволяет очень быстро корректировать вектор развития продукта. А если она при этом достаточно гибко интегрирована, то даже кардинальная смена вектора не ухудшит качество сервиса. По крайней мере, виновницей того будет точно не аналитика.