Давайте поговорим про то, как понять, нужен ли вам в команду собственный исследователь. Как это определить? Ведь все говорят про необходимость понимания своего пользователя, про количественные и качественные исследования, client-centered design. На рынке хайп и найм.
Очень часто исследования или команда исследователей в компаниях находятся в стороне, не участвуют в продуктовом процессе. Как внутренний сервис, используемый по желанию, но не как обязательный этап. И это вполне понятно, потому что исследования ещё один пункт, который замедляет time-to-market. По крайней мере, в России это реальность 95% компаний, где есть команда или выделенный исследователь.
Дизайн не выбросишь, разработку не выбросишь, микрокопинг тоже не выбросить из процесса. А вот глубинные интервью или юзабилити-тесты вполне можно пропустить – визуальный результат в глазах менеджеров от этого не пострадает. KPI по срокам никто не отменит.
Есть ряд проблем, которые приводят к работе исследователя “в стол”:
1.Компании не понимают целевого результата.
2.Не понимают кто и с какими навыками им нужен.
3.Не умеют нанимать и проверять навыки.
4.Не включают исследования в продуктовый процесс.
Как же понять, нужен ли вам исследователь именно сейчас?
Для меня самый главный критерий – измеримость успеха и качества работы. Исходя из большого опыта с разными компаниями-клиентами и в найме в разных компаниях, я выделила список вопросов, которые помогут понять руководителям компании, нужен ли вам исследователь прямо сейчас, будет ли он приносить пользу и результат.
1. Понимаете метрики успеха?
Вы можете понять где находитесь сейчас? У вас есть веб и мобайл аналитика, продуктовая аналитика, группировка обращений. Если да – вы сможете поставить измеримые цели. Если нет – начните с этого, иначе без текущего состояния и без целей вы не сможете оценить прогресс и результат работы исследователя.
Примеры целей:
- Снижение негативных обращений – отдельная задача отдельных продуктов, которая представляет собой работу исследователя над разными точками взаимодействия сервиса с пользователем.
- Увеличение конверсии по шагам в определённых сценариях – тоже хорошо поставленная задача, если у вас есть аналитические данные и показатели.
- Уменьшение количества ошибок – отличная цель для сложных по функциональности продуктов.
Исследователь может выделить изменения малой кровью – быстро улучшают текущий процесс, и стратегические изменения – долгосрочные и более качественные изменения процесса.
2. Приоритеты: вам деньги или удобство?
Роль исследователя в продуктовом процессе двояка:
- Он может подключаться на этапе идеи для её проверки. Это значит, что время доведения фичи до пользователя увеличится. Вы готовы к этому? Это минимум плюс месяц к вашим обычным срокам.
- Тестирование – второй этап, который сильно увеличит сроки. Это ещё 2-4 недели в продуктовом процессе.
Это значит, что деньги за эти фичи вы получите позже.
Важно понимать, что у вас в приоритете, как вы будете проводить приоритизацию в разработке: сможете ли вы дать приоритет вещам, которые улучшают опыт перед запуском совершенно новых идей и фич?
Если нет – ваш исследователь будет получать деньги зря, выгорать из-за исследований в стол, а вы не получите изменений.
3. Ваши слова расходятся с делами?
На митингах и в прессе вы можете говорить про то как любите своего пользователя и как делаете для него всё возможное. В реальных ситуациях готовы ли вы решать единичные сложные задачи или проблемы пользователей? Готовы ли вникать и тратить на это своё время и время сотрудников, чтобы идти не автоматизированными стандартными путями, а делать что-то руками и придумывать как обойти свой же налаженный процесс?
Если нет – вы именно тот тип компаний, у которых слова расходятся с делом.
Если вы как менеджер не подтверждаете своих слов делами, то и вся ваша команда будет брать пример с вас и вести себя так же в тех же ситуациях.
Это приводит к неуважению пользователя и игнорированию результатов работы исследователя всей командой.
“Рыба гниёт с головы”
4. Вы сможете проверить навыки при приёме?
Есть ли у вас в команде кто-то, кто может проверить навыки исследователя при найме? Как вы поймёте уровень и набор скилов, если внутри нет компетенции, которая глубоко проверит знания и опыт именно исследовательской компетенции?
И получается, что решает либо образование, либо умение красиво говорить. Что не отражает реального положения вещей.
Вы не поймёте какого качества у вас будут результаты, не изучив глубоко человека на собеседовании. После найма, не понимая навыков, вы не сможете понять, что вам приносят некачественные неиспользуемые результаты.
В следующей статье постараюсь написать понятный гайд и дать материалы, с помощью которых эти навыки можно проверить, не являясь исследователем, а всего лишь понимая диджитал-процессы.
5. У вас есть ресурсы?
Что у вас есть сейчас из ресурсов? Есть ли дизайнеры, проектировщики, есть ли у них время и потребность в исследованиях? Каковы мощности разработки? Как часто вы можете выпускать обновления? Раз в две недели или раз в 9 месяцев?
Ответив себе на эти вопросы, вы поймёте, есть ли необходимость в исследователе прямо сейчас и с текущими процессами. Так же вы поймёте, через какое время новый сотрудник принесёт вашему продукту измеримый результат – будут ли это 3 недели или же 9 месяцев (И что вы вообще делаете в этой компании?).
6. Команда будет сопротивляться?
Самые сложные – дизайнеры. Попроще — продуктологи. И самые восприимчивые – разработчики. Так в среднем по больнице.
Команде сложно адаптироваться под новые реалии, психологически некомфортно понимать, что теперь кто-то им будет говорить как лучше не делать, а как лучше делать, будет указывать на ошибки.
Чем более творческий человек, тем более он восприимчив к критике и приземленным вещам.
UX это часто не про креатив а про нативность, привычные и проложенные пути и устоявшиеся действия.
Если нынешняя команда будет сильно сопротивляться, результат будет сомнительным. Тут важно сделать так, чтоб люди были заодно, чтоб они стали одной командой с одними и теми же целями (метрики из первого пункта).
Это решается вовлечением и вашим влиянием:
- Поговорите с командой заранее, спросите их мнения и помощи, спросите где есть проблемы и в чем бы мог исследователь им помочь.
- Посадите дизайнера рядом, пока исследователь будет тестировать продукт его работы. Или пусть проведёт сам под экспертным надзором пару тестов. Трёх встреч с пользователем хватает, чтоб люди развернулись лицом к тому, для кого делают продукт.
7. Вы прошли этап MVP?
Стартапы пытаются нанимать исследователя в команду сразу, при создании MVP. Но подходящий ли это этап?
Нужно быстро проверить идеи – это к исследователю.
Нужен быстрый дизайн и запуск, нужно потратить минимум денег чтоб показать цифры, нужно быстро нагнать первых пользователей. Всё что про “быстро” расходится с тем, зачем исследователь нужен в команде на этом этапе. Исследователь на этом этапе в команду не нужен. Для него задач мало. Вам нужен хороший аутсор-исследователь, скорее одиночка, но с опытом в аналогичной сфере.
8. У вас достаточно активных пользователей?
Если в базе 1200 пользователей(даже если B2B) – тоже не время нанимать. Работать не с чем. Рекрут сторонних пользователей дорогой. Социальный капитал вычерпаете очень быстро, исследователь останется без пользовательской базы. И это опять же, время чтоб поработать с кем-то попроектно для конкретных важных целей и результатов, но не чтобы брать человека в команду.
9. Вы можете запускать A/B-тесты?
Не столь критичная штука, но с ней результаты исследователя будут куда нагляднее, репрезентативнее и быстрее проверяемы.
Нужен сложный инструмент внутри продукта для настройки теста не просто одной страницы, но всей воронки процесса. Нужен настраиваемый однородный трафик, иногда в очень больших количествах для репрезентативности результатов.
Ответив себе на эти вопросы, вы сами поймёте, стоит ли вам брать человека в команду, или же сейчас совершенно не подходящий этап развития (состояние команды или процессов) и деньги и время будут потрачены зря.
Может быть стоит присмотреться к попроектным исследователям?