July 30, 2020

Дизайнеру, умеющему в метрики, я готов платить на 50% больше

Рассказывает Тигран Басеян из GeekBrains. Статья скорее про то, зачем нужны метрики, а не про то, как с ними работать.

Привет-привет! Я часто говорю, что умение работать с метриками увеличивает з/п дизайнера.

Мои аргументы вы уже слышали. Дизайнер,

  • строящий продукт на бизнес-логике;
  • умеющий оценивать свою работу по считываемым изменениям пользовательского взаимодействия;
  • способный аргументировать свои решения, подкрепив их собранными данными,

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

Так считаю не только я, но и представители многих крутых продуктов — таких, в которые вам хотелось бы попасть.

Сегодня я попросил продакт-менеджера GeekBrains Тиграна Басеяна рассказать, почему он считает работу с метриками необходимым скиллом продуктового дизайнера.

Я по полгода ищу дизайнеров, способных решать проблемы пользователей

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

Почему так? Я считаю, что разницы между продактом и продуктовым дизайнером не так много, как привыкли думать. Это очень близкие люди и по зарплате, и по компетенциям, просто у каждого свой фокус.

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

Чтобы эффективно решать проблемы пользователя, нужно понимать результат решения, каким-то образом его измерять.

То, что мы измеряем, строя результат, — это и есть метрики.

Без метрик:

  • оценки переходов;
  • информации о кликах;
  • способов оценки А/В-тестов, когда сравниваются варианты решений
  • и некоторых других

тебе будет трудно всерьёз погрузиться в продукт, увидеть его изнутри.

Ты просто не можешь оценить свою работу, если не понимаешь метрики продукта — то, как твоё решение влияет на результат действий пользователя. Это умение оказывается абсолютно необходимым. Речь не о том, чтобы считать ROI или retention. Нужно считать метрики, важные для пользователя, — те, на которые ты хочешь влиять.

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

Брейнстормим метрики для воронки мероприятий


Иван: Лучше понять, что такое метрики и какими они бывают, поможет моя статья про них: https://teletype.in/@serebrennikov/Sk2Y5pb_7.


Серьёзные продукты — очень конкурентная среда. За место в них надо побороться

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

Работа в серьёзных проектах — высококонкурентная среда, где нужно очень хорошо понимать и нужды пользователя, и то, что именно ты делаешь, то, как твоя работа помогает продукту их закрыть. Без метрик этого не сделать.

Работа с метриками — это не про инструменты, а про понимание проблем и логики их решения

А вот то, как считать метрики, где их смотреть и какими инструментами пользоваться, зависит от конкретной компании; тут у каждой свой контекст. У кого-то это сквозная аналитика через Яндекс.Метрику, у других — Roistat, Google Analytics, а кто-то вообще успешно считает в Excel и ему этого достаточно.

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


Иван: чтобы лучше понимать, как работают продукты, полезно познакомиться с юнит-экономикой и кастдевом:


Почему дизайнеру круто работать с метриками

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

Если ты дизайнер, хорошо умеющий в метрики,твоё место в команде будет железобетонным.

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

Про разделение обязанностей в GeekBrains

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

А вся интересная продуктовая работа: UX-исследования, подготовка прототипов под A/B-тестирование, проведение этих тестов, сборка лендов и аналитика происходящего для подтверждения или опровержения гипотез — всё это задачи продуктового дизайнера.

Почему это так?

У меня, конечно, есть компетенции UI/UX’ера, но я понимаю, что у дизайнера они намного выше. Таким образом, дизайнер, когда он понимает, какую задачу мы решаем, предложит лучшее решение, чем смогу выдать я, уже давно отошедший от проектирования экранов.

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

Освободив время продакта и самостоятельно принимая решения в UX и UI, дизайнер, конечно, становится ценнее для команды. А значит, начинает получать больше.

Команда за работой

Метрики — для аналитиков?

Почему нельзя делегировать метрики отдельному человеку, который будет заниматься только ими?

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

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

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

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

Моё мнение: роль аналитика в команде важна — не все данные доступны, не всё понятно, как собирать; зачастую бывают ситуации, когда ты можешь прийти к нему с гипотезой и просишь дать данные для её проверки, а он может объяснить, какие данные нужны и как надо сформулировать гипотезу, чтобы они проверяли её.

Отлично, когда есть такой живой центр компетенции.

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

И он должен уметь это делать, потому что иначе его работа будет идти отдельно, а результат достигаться отдельно, пересечения между ними не будет.

А это метрики образовательного проекта geekz.ru, в котором я на позиции генерального директора.

  1. Чем больше ты понимаешь метрики, тем сильнее влияешь на продукт.
  2. Проектируя на данных, ты лучше сможешь защищать свои решения.
  3. Не работая с метриками, ты просто не сможешь говорить с командой на одном языке
  4. Если дизайнер только рисует — получается, что с метриками работает кто-то за него. Возникает дополнительное звено в процессе работы, теряется связность процесса.
  5. Понимать пользователя и предлагать решения его проблем — главная задача продуктовой команды. Значит, дизайнер должен мыслить категориями пользовательского опыта.

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


Иван: о том, как метрики помогают оценивать интерфейсные решения, можно почитать здесь: https://teletype.in/@serebrennikov/H10iGeuvX.


Какие проблемы возникнут без умения работать с метриками

В продуктовой команде мы каждую гипотезу проверяем одну-две недели: запускаем А/В-, сплит-тестирование, иногда и А/В/С-.

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

Бывает, что и продакт в этом не разбирается, — но это сразу конец продукту, разработку можно закрывать.

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

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

Почему дизайнеры, знающие метрики, очень востребованы

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

Про финансовые требования middle- и senior-дизайнеров можно сказать, что они чрезмерны, а рынок перегрет.

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

- - - - - - - - - - - - - - -

Захотелось узнать больше о метриках? У нас есть в UX Boost групповой менторинг, где учат и аналитике, и другим навыкам, помогают сделать собственный продукт, получить первые заказы и устроиться в хороший продукт.