Но что ещё интересно, лектор провёл небольшое дополнительное исследование - как разные стили ведения интервью (нейтральный, поддерживающий и конфронтирующий "challenging") влияют на качество результатов, и обнаружил, что особо никак. Качество результатов для интервьюеров с разными техниками модерации не отличались. Но окей, это исследования на трёх десятках студентов, наверняка есть более глубокие работы на тему. Если читали что-то интересное - присылайте мне)
Сам курс хороший, хотя скорее с перекосом в философию науки, чем в практику. Если интересно только про техники вопросов, то вам, напомню, нужна неделя 4 урок 3)
https://www.coursera.org/learn/qualitative-methods
Сам курс хороший, хотя скорее с перекосом в философию науки, чем в практику. Если интересно только про техники вопросов, то вам, напомню, нужна неделя 4 урок 3)
https://www.coursera.org/learn/qualitative-methods
И напоследок, если погуглить "probing technics" ещё немного, мы наткнемся на статью в блоге Gallup (у них есть блог! Пишут статей 5 в год, но пока не понял, толковые ли). Так вот, Gallup, и у них в статье указано, что не так всё просто, и probing искажает данные, так что надо аккуратней https://news.gallup.com/opinion/methodology/223286/effects-probing-survey-research.aspx
___
Ещё про модерацию:
https://t.me/uxread/79 Инди Янг про хейт спичи на исследованиях и как их переживать
https://t.me/uxread/120 можно записаться на исследования в другие компании, посмотреть, как модерируют
https://t.me/uxread/16 - Интерком про точечные интервью с пользователями, совершившим определенное действие на сайте
https://t.me/uxread/23 - Deliveroo про полевые исследования у людей дома
Другие методы #Methods
Другие кейсы #Cases
___
Ещё про модерацию:
https://t.me/uxread/79 Инди Янг про хейт спичи на исследованиях и как их переживать
https://t.me/uxread/120 можно записаться на исследования в другие компании, посмотреть, как модерируют
https://t.me/uxread/16 - Интерком про точечные интервью с пользователями, совершившим определенное действие на сайте
https://t.me/uxread/23 - Deliveroo про полевые исследования у людей дома
Другие методы #Methods
Другие кейсы #Cases
Выглядит как реклама, но нет.
Нашёл компанию, которая предлагает супер таргетированный рекрут экспертов для интервью.
Они, впрочем, позиционируют это не как рекрут респондентов, а как организацию созвонов с expert advisors, но это не важно.
Суть в том, что они готовы искать для вас людей, которые проектировали радиаторы для огромных двигателей, госзакупщиков софта для чрезвычайных ситуаций, или неврологов, специализирующихся на работе с болезнью Альцгеймера в общественных больницах.
Среди клиентов, понятное дело, IDEO (ну ещё бы) и Big Three consulting firms. Цена - от 300$ до 900$ за одно часовое интервью, что, внезапно, меньше, чем я ожидал бы.
А, ну и конечно можно зарегистрироваться как эксперт, и получать свои миллионы.
https://deepbench.io/find
(UPD: Саша Фенин скинул пост с обзором таких сообществ, их миллион, оказывается https://t.me/startupoftheday/888)
Нашёл компанию, которая предлагает супер таргетированный рекрут экспертов для интервью.
Они, впрочем, позиционируют это не как рекрут респондентов, а как организацию созвонов с expert advisors, но это не важно.
Суть в том, что они готовы искать для вас людей, которые проектировали радиаторы для огромных двигателей, госзакупщиков софта для чрезвычайных ситуаций, или неврологов, специализирующихся на работе с болезнью Альцгеймера в общественных больницах.
Среди клиентов, понятное дело, IDEO (ну ещё бы) и Big Three consulting firms. Цена - от 300$ до 900$ за одно часовое интервью, что, внезапно, меньше, чем я ожидал бы.
А, ну и конечно можно зарегистрироваться как эксперт, и получать свои миллионы.
https://deepbench.io/find
(UPD: Саша Фенин скинул пост с обзором таких сообществ, их миллион, оказывается https://t.me/startupoftheday/888)
Telegram
Стартап дня
Месяц назад в #стартапдня попало фейковое экспертное сообщество. AdvisoryCloud много всего обещает, берет деньги и ничего не делает. Сегодня - обзор тех, кто на самом деле помогает компаниям найти консультации независимых специалистов, а людям зарабатывать…
Как имплицитное чувство вины за потребление мешает покупать красивые вещи (связка anticipatory guilt и hedonic consumption)
Исследование о том, как разные качества продукта влияют на решение о его покупке, которое заодно объясняет, почему люди дарят друг другу бесполезные подарки.
Участникам исследования давали несколько пар продуктов (две пары наушников, два ноутбука, две шоколадки, два моющих средства), так, что у одного продукта в паре были больше выражены "полезные" качества (наушники долго держали батарею, но были не очень красивыми), а у второго - "гедонистические" (наушники были очень красивые, но батарею держали недолго).
По итогам обнаружили, что люди чаще выбирают для себя вещи с выраженными практичными качествами (ноутбук с ёмкой батарей, но страшный), а для других - с более гедонистическими (ноутбук с маленькой батареей, но стильным дизайном).
Авторы предполагают, что дело в "имплицитном чувстве вины за потребление" - неловко для себя желать слишком бесполезно-красивого. Эта гипотеза подтвердилась, хотя и очень опосредованно (они показали, что люди, выбирая продукты для других, испытывают субъективно более низкий уровень вины (anticipatory guilt from hedonic consumption)
Для нас это значит, что изменения hedonic quality (например, визуальные улучшения), вероятно, больше влияют на рекомендательные метрики (например, НПС), но меньше на готовность покупать и пользоваться продуктом самому.
Оп! В теории можно сделать продукт, которые все всем рекомендуют, но покупать его как-то неудобно.
Вот статья http://journal.sjdm.org/16/16428a/jdm16428a.html, опубликована на сайте Society for Judgment and Decision Making, там ещё много забавных.
___
https://t.me/uxread/68 Head of behavior science в Google
https://t.me/uxread/93 Канеман про работу памяти, дневниковые исследования и оптимальное время для опросов
Больше "околонаучных" заметок #Science
Исследование о том, как разные качества продукта влияют на решение о его покупке, которое заодно объясняет, почему люди дарят друг другу бесполезные подарки.
Участникам исследования давали несколько пар продуктов (две пары наушников, два ноутбука, две шоколадки, два моющих средства), так, что у одного продукта в паре были больше выражены "полезные" качества (наушники долго держали батарею, но были не очень красивыми), а у второго - "гедонистические" (наушники были очень красивые, но батарею держали недолго).
По итогам обнаружили, что люди чаще выбирают для себя вещи с выраженными практичными качествами (ноутбук с ёмкой батарей, но страшный), а для других - с более гедонистическими (ноутбук с маленькой батареей, но стильным дизайном).
Авторы предполагают, что дело в "имплицитном чувстве вины за потребление" - неловко для себя желать слишком бесполезно-красивого. Эта гипотеза подтвердилась, хотя и очень опосредованно (они показали, что люди, выбирая продукты для других, испытывают субъективно более низкий уровень вины (anticipatory guilt from hedonic consumption)
Для нас это значит, что изменения hedonic quality (например, визуальные улучшения), вероятно, больше влияют на рекомендательные метрики (например, НПС), но меньше на готовность покупать и пользоваться продуктом самому.
Оп! В теории можно сделать продукт, которые все всем рекомендуют, но покупать его как-то неудобно.
Вот статья http://journal.sjdm.org/16/16428a/jdm16428a.html, опубликована на сайте Society for Judgment and Decision Making, там ещё много забавных.
___
https://t.me/uxread/68 Head of behavior science в Google
https://t.me/uxread/93 Канеман про работу памяти, дневниковые исследования и оптимальное время для опросов
Больше "околонаучных" заметок #Science
Telegram
UX Research
Оказывается, в Walmart и в Google есть позиция Head of Behavioral Science.
Я всегда думал, что попытки применить behavioral economics при создании продуктов не очень работают, все знают, что Канеман крутой, но никто не говорит "почитал Канемана и придумал…
Я всегда думал, что попытки применить behavioral economics при создании продуктов не очень работают, все знают, что Канеман крутой, но никто не говорит "почитал Канемана и придумал…
Тут интересно поразмышлять ещё о двух вещах:
Интересно, как это коррелирует с культурными различиями. Кажется, что в обществах, где нормально демонстрировать богатство, hedonic qualities будут повышать и собственную мотивацию к покупке, а вот в культурах с суровой протестантской этикой (или со старой аристократией, где публичное потребление - признак низкого статуса) люди будут предпочитать более утилилитарные продукты.
И ещё о том, как возрастает роль hedonic qualities в любых системах со временем. Для b2с систем этот процесс произошёл несколько лет назад - интернет банки превратились в hedonic systems со сториз. Для b2b этот процесс идёт прямо сейчас - изначально b2b продукты это utilitarian systems, которые должны работать, и выполнять задачу, а субъективный опыт конечных пользователей не так уж важен. Но постепенно роль конечных пользователей в выборе софта растёт (slack, например, растёт "снизу вверх"), и b2b превращаются в hedonic systems (Athenahealth немного писали на эту тему https://t.me/uxread/60). Глобально для цифровых продуктов этот процесс идёт последние 50 лет, но про это я порассуждаю чуть-чуть попозже, пока уровень занудства не стал критическим.
Интересно, как это коррелирует с культурными различиями. Кажется, что в обществах, где нормально демонстрировать богатство, hedonic qualities будут повышать и собственную мотивацию к покупке, а вот в культурах с суровой протестантской этикой (или со старой аристократией, где публичное потребление - признак низкого статуса) люди будут предпочитать более утилилитарные продукты.
И ещё о том, как возрастает роль hedonic qualities в любых системах со временем. Для b2с систем этот процесс произошёл несколько лет назад - интернет банки превратились в hedonic systems со сториз. Для b2b этот процесс идёт прямо сейчас - изначально b2b продукты это utilitarian systems, которые должны работать, и выполнять задачу, а субъективный опыт конечных пользователей не так уж важен. Но постепенно роль конечных пользователей в выборе софта растёт (slack, например, растёт "снизу вверх"), и b2b превращаются в hedonic systems (Athenahealth немного писали на эту тему https://t.me/uxread/60). Глобально для цифровых продуктов этот процесс идёт последние 50 лет, но про это я порассуждаю чуть-чуть попозже, пока уровень занудства не стал критическим.
Telegram
UX Research
Как Athenahealth оценили ROI дизайна и перекроили весь процесс
https://youtu.be/nG47ufRgY1k
Jennifer Cardello рассказывает, как у них в Athenahealth было 60 дизайнеров и 5 исследователей, а продукт всё равно был страшным и запутанным, потому что дизайнеров…
https://youtu.be/nG47ufRgY1k
Jennifer Cardello рассказывает, как у них в Athenahealth было 60 дизайнеров и 5 исследователей, а продукт всё равно был страшным и запутанным, потому что дизайнеров…
Machine learning для исследований на этапе формирования и проверки гипотез
Статья про использование machine learning для UX исследований от athenahealth
Эти знают, о чём говорят - вот кейс, где они построили регрессионную модель, чтобы обосновать ROI дизайна через NPS и ретеншн.
Статья - такой вводный чек-лист, который поможет понять, как это вообще работает, и какие задач могут решаться с помощью статистики и ML методов в исследованиях.
Они делят методы на три группы, в зависимости от того, какой тип задач исследователя они решают, и для каждой группы рассказывают про конкретные задачи.
Discover - по сути этап exploratory research. Чем тут поможет ML:
1) Персоны на основе кластеризации. У вас есть набор данных пользователей с признаками каждого, вы можете сформировать кластеры-группы на основе этих признаков. Тут не буду углубляться, в статье кратко описывают несколько видов кластеризации и их различия.
2) Association Rules - для выявления, какие события чаще встречаются вместе в одной сессии, или чаще встречаются для одного типа пользователей
3) Выявление частых сценариев (process mining) из неструктурированного лога событий аналитики. Это интересный кейс, когда вы хотите выявить какие-то неочевидные последовательности действий и пользовательские пути
Test hypotheses - этап проверки решений
Регрессия и деревья решений (decision trees) для предсказания того, какие события чаще ведут к целевому событию. Например, какие события в триальной сессии лучше всего предсказывают покупку, или какие параметры писем лучше всего предсказывают их конверсию, или какие параметры партнёров являются лучшим предиктором роста для них. В статье описано несколько типов регрессии, разница между ней и деревьями решений и даются ссылки на более подробные источники.
Data simplification - это, строго говоря, не про исследования, а про подготовку данных для анализа
1) Снижение размерности (Dimensionality Reduction) для более наглядного представления данных или их более простой обработки.
2) Подготовка данных, кратко описываются подходы и софт для подготовки.
https://link.medium.com/DNCUdct7I6
___
Ещё про исследования на разных этапах
https://t.me/uxread/13 - IBM про исследования на разных стадиях создания продукта
https://t.me/uxread/104 исследовательские процессы в в Spotify - mixed research и смешанный департамент product insights
В заметке ниже хорошие статьи про продуктовую аналитику
Статья про использование machine learning для UX исследований от athenahealth
Эти знают, о чём говорят - вот кейс, где они построили регрессионную модель, чтобы обосновать ROI дизайна через NPS и ретеншн.
Статья - такой вводный чек-лист, который поможет понять, как это вообще работает, и какие задач могут решаться с помощью статистики и ML методов в исследованиях.
Они делят методы на три группы, в зависимости от того, какой тип задач исследователя они решают, и для каждой группы рассказывают про конкретные задачи.
Discover - по сути этап exploratory research. Чем тут поможет ML:
1) Персоны на основе кластеризации. У вас есть набор данных пользователей с признаками каждого, вы можете сформировать кластеры-группы на основе этих признаков. Тут не буду углубляться, в статье кратко описывают несколько видов кластеризации и их различия.
2) Association Rules - для выявления, какие события чаще встречаются вместе в одной сессии, или чаще встречаются для одного типа пользователей
3) Выявление частых сценариев (process mining) из неструктурированного лога событий аналитики. Это интересный кейс, когда вы хотите выявить какие-то неочевидные последовательности действий и пользовательские пути
Test hypotheses - этап проверки решений
Регрессия и деревья решений (decision trees) для предсказания того, какие события чаще ведут к целевому событию. Например, какие события в триальной сессии лучше всего предсказывают покупку, или какие параметры писем лучше всего предсказывают их конверсию, или какие параметры партнёров являются лучшим предиктором роста для них. В статье описано несколько типов регрессии, разница между ней и деревьями решений и даются ссылки на более подробные источники.
Data simplification - это, строго говоря, не про исследования, а про подготовку данных для анализа
1) Снижение размерности (Dimensionality Reduction) для более наглядного представления данных или их более простой обработки.
2) Подготовка данных, кратко описываются подходы и софт для подготовки.
https://link.medium.com/DNCUdct7I6
___
Ещё про исследования на разных этапах
https://t.me/uxread/13 - IBM про исследования на разных стадиях создания продукта
https://t.me/uxread/104 исследовательские процессы в в Spotify - mixed research и смешанный департамент product insights
В заметке ниже хорошие статьи про продуктовую аналитику
Telegram
UX Research
Во-вторых, вот история, как ребята всех переубедили.
1) Они делали софт для хранения медицинских данных, который очень удачно подходил под свежие государственные требования, что позволяло им делать неудобный софт и отлично продавать его (государство платило…
1) Они делали софт для хранения медицинских данных, который очень удачно подходил под свежие государственные требования, что позволяло им делать неудобный софт и отлично продавать его (государство платило…
Что ещё можно посмотреть по теме:
- Очень хорошо про mixed research и конкретно про machine learning в UX пишет Антон в product science, вот его обзор области, а вот очень понятный рассказ, как они используют графы в продуктовой аналитике, с примерами и объяснениями, понятными, даже если вы в этом не шарите вообще (как я)
- Ещё один короткий кейс про графы, чем они лучше воронок, и как их использовать во имя конверсии
Ну и если хотите научиться руками строить простые предиктивные модельки и боитесь питона, у Куличевского есть практичный курс для новичков, я когда-то проходил, и теперь могу делать простенький машин лёрнинг в гугл таблицах)
- Очень хорошо про mixed research и конкретно про machine learning в UX пишет Антон в product science, вот его обзор области, а вот очень понятный рассказ, как они используют графы в продуктовой аналитике, с примерами и объяснениями, понятными, даже если вы в этом не шарите вообще (как я)
- Ещё один короткий кейс про графы, чем они лучше воронок, и как их использовать во имя конверсии
Ну и если хотите научиться руками строить простые предиктивные модельки и боитесь питона, у Куличевского есть практичный курс для новичков, я когда-то проходил, и теперь могу делать простенький машин лёрнинг в гугл таблицах)
YouTube
Growth Funnels vs Growth Graphs & Matrices | Paul Levchuk at Secrets of Growth
Get your free executive summary of 2019 Marketing Benchmark Report: https://growthmarketingstage.com/marketing-benchmark-report
Paul is a Head of Data at Preply.com. Also, he led Growth Hacking team at Depositphotos and used to be a CMO for GoVitall.
At…
Paul is a Head of Data at Preply.com. Also, he led Growth Hacking team at Depositphotos and used to be a CMO for GoVitall.
At…
Иногда вижу, что дизайнеры и исследователи не знают, как подступиться к продуктовой аналитике. Они не понимают
а) как её настроить (что писать в ТЗ на настройку, какие события нужно отслеживать),
б) за какими метриками следить в настроенной системе и как с помощью аналитики улучшать продукт.
Я не продуктовый аналитик, но расскажу о своем опыте, так как не видел внятного базового объяснения для таких, как я, исследователей и дизайнеров.
Шаг 1 - понять целевое поведение в интерфейсе
Вы как дизайнер создаете или тестируете интерфейсы.
Допустим, вы работаете над чекаутом, дашбордом, или новой навигацией.
За любым из этих интерфейсов стоит целевое поведение: то, как люди будут себя в нём вести, если вы сделаете этот интерфейс очень хорошо. Целевое поведение — то, ради чего вы и создаете интерфейс.
• Идеальный чекаут — тот, через который пользователь пройдёт быстро и не задумываясь.
• Идеальный каталог — тот, в котором пользователь быстро находит то, что нужно.
• Идеальный дашборд — тот, что регулярно используют, и на основе которого быстро принимают решение.
Часто возможных целевых сценариев несколько, суть от этого не меняется.
Шаг 2 - описать целевое поведение через события в продукте
Вы продумали целевое поведение. Следующий шаг — описать его в терминах событий: переходов на страницы, кликов на элементы, заполнения полей, и времени между ними.
• Идеальный чекаут -> тот через который проходят все без потерь -> видим в аналитике последовательность страниц, в которой аудитория не уменьшается (воронка без сужения)
• Идеальный каталог -> люди быстро находят нужную информацию и переходят на нужную страницу -> среднее время на странице каталога низкое, после переходов на страницы второго уровня нет возвратов назад к каталогу
• Идеальный дашборд -> его регулярно используют для быстрой оценки ситуации -> высокое dau/mau (заходят много раз за месяц), короткое время на странице дашборда (т.к. быстро принимают решение, что делать дальше).
Часть событий отслеживаются аналитическими системами "из коробки" (посещения отдельных страниц, время на странице), часть нужно настраивать (заполнение отдельных полей, отслеживание системных ошибок).
Сначала может быть сложно описывать целевые сценарии с помощью событий. Если это так, попробуйте представить, как кто-то работает с интерфейсом оптимальным образом, что в этот момент пишется в логах? Это оно.
Шаг 3 - на основе событий подобрать метрики
Когда у вас есть целевое поведение, описанное в виде событий на сайте, вам легче придумать метрики, которые покажут качество интерфейса. Они отражают, насколько реальное поведение в продукте близко к целевому.
• Для воронки чекаута — конверсия на каждом шаге
• Для каталога — время на разводящей и % возвратов со страниц второго уровня на разводящую
• Для дашборда — время на странице дашборда и, регулярность его использования средним пользователем.
Вы не сможете придумать метрики или понять, какие события отслеживать, пока не поймёте, зачем вы делаете интерфейс, и как выглядит идеальное поведение в нём.
Используйте типовые подборки событий
Есть типовые способы описывать успешные сценарии и частые проблемы - воронка (успешность линейных сценариев), bounce rate (проблемы с маркетингом/плохая навигация), rage clicks (недостаток обратной связи в интерфейсе), конверсия форм (качество формы и понятность описания), графы для сложных и разветвленных сценариев (например тут https://t.me/uxread/144).
Есть даже типовые способы описывать успешные сценарии для разных продуктов. Вы можете погуглить metrics for content products, или типичные дашборды для eсommerce. Такие подборки не всегда хороши, но они дают понимание, как качество продуктов можно описывать в виде событий и метрик.
Подытожим
Чтобы понять, какие события отслеживать, составьте в уме цепочку:
Зачем продукт/интерфейс нужен -> как выглядит идеальный сценарий пользователя -> как этот идеальный сценарий можно описать в виде событий на сайте.
Если настраиваете аналитику для большого продукта, начните с нескольких ключевых сценариев.
#Frameworks
а) как её настроить (что писать в ТЗ на настройку, какие события нужно отслеживать),
б) за какими метриками следить в настроенной системе и как с помощью аналитики улучшать продукт.
Я не продуктовый аналитик, но расскажу о своем опыте, так как не видел внятного базового объяснения для таких, как я, исследователей и дизайнеров.
Шаг 1 - понять целевое поведение в интерфейсе
Вы как дизайнер создаете или тестируете интерфейсы.
Допустим, вы работаете над чекаутом, дашбордом, или новой навигацией.
За любым из этих интерфейсов стоит целевое поведение: то, как люди будут себя в нём вести, если вы сделаете этот интерфейс очень хорошо. Целевое поведение — то, ради чего вы и создаете интерфейс.
• Идеальный чекаут — тот, через который пользователь пройдёт быстро и не задумываясь.
• Идеальный каталог — тот, в котором пользователь быстро находит то, что нужно.
• Идеальный дашборд — тот, что регулярно используют, и на основе которого быстро принимают решение.
Часто возможных целевых сценариев несколько, суть от этого не меняется.
Шаг 2 - описать целевое поведение через события в продукте
Вы продумали целевое поведение. Следующий шаг — описать его в терминах событий: переходов на страницы, кликов на элементы, заполнения полей, и времени между ними.
• Идеальный чекаут -> тот через который проходят все без потерь -> видим в аналитике последовательность страниц, в которой аудитория не уменьшается (воронка без сужения)
• Идеальный каталог -> люди быстро находят нужную информацию и переходят на нужную страницу -> среднее время на странице каталога низкое, после переходов на страницы второго уровня нет возвратов назад к каталогу
• Идеальный дашборд -> его регулярно используют для быстрой оценки ситуации -> высокое dau/mau (заходят много раз за месяц), короткое время на странице дашборда (т.к. быстро принимают решение, что делать дальше).
Часть событий отслеживаются аналитическими системами "из коробки" (посещения отдельных страниц, время на странице), часть нужно настраивать (заполнение отдельных полей, отслеживание системных ошибок).
Сначала может быть сложно описывать целевые сценарии с помощью событий. Если это так, попробуйте представить, как кто-то работает с интерфейсом оптимальным образом, что в этот момент пишется в логах? Это оно.
Шаг 3 - на основе событий подобрать метрики
Когда у вас есть целевое поведение, описанное в виде событий на сайте, вам легче придумать метрики, которые покажут качество интерфейса. Они отражают, насколько реальное поведение в продукте близко к целевому.
• Для воронки чекаута — конверсия на каждом шаге
• Для каталога — время на разводящей и % возвратов со страниц второго уровня на разводящую
• Для дашборда — время на странице дашборда и, регулярность его использования средним пользователем.
Вы не сможете придумать метрики или понять, какие события отслеживать, пока не поймёте, зачем вы делаете интерфейс, и как выглядит идеальное поведение в нём.
Используйте типовые подборки событий
Есть типовые способы описывать успешные сценарии и частые проблемы - воронка (успешность линейных сценариев), bounce rate (проблемы с маркетингом/плохая навигация), rage clicks (недостаток обратной связи в интерфейсе), конверсия форм (качество формы и понятность описания), графы для сложных и разветвленных сценариев (например тут https://t.me/uxread/144).
Есть даже типовые способы описывать успешные сценарии для разных продуктов. Вы можете погуглить metrics for content products, или типичные дашборды для eсommerce. Такие подборки не всегда хороши, но они дают понимание, как качество продуктов можно описывать в виде событий и метрик.
Подытожим
Чтобы понять, какие события отслеживать, составьте в уме цепочку:
Зачем продукт/интерфейс нужен -> как выглядит идеальный сценарий пользователя -> как этот идеальный сценарий можно описать в виде событий на сайте.
Если настраиваете аналитику для большого продукта, начните с нескольких ключевых сценариев.
#Frameworks
Telegram
Королёв про всё остальное (ex UX Research)
Что ещё можно посмотреть по теме:
- Очень хорошо про mixed research и конкретно про machine learning в UX пишет Антон в product science, вот его обзор области, а вот очень понятный рассказ, как они используют графы в продуктовой аналитике, с примерами и объяснениями…
- Очень хорошо про mixed research и конкретно про machine learning в UX пишет Антон в product science, вот его обзор области, а вот очень понятный рассказ, как они используют графы в продуктовой аналитике, с примерами и объяснениями…
👍1
Не настраивайте метрики для “политических” фич.
Напоследок - у некоторых фич очень сложно обнаружить целевой сценарий: его нет ни в ТЗ, ни в коммуникациях, не понятны ни метрики успешности, ни метрики качества.
Такое может быть, если фича делается не для удобства пользователя, а для других целей: пиара (привлечение внимания с помощью хайповой технологии), маркетинга и продаж (больше буллет поинтов в таблице сравнения с конкурентом), или под пожелания конкретного инвестора.
Для бизнеса эти функции могут быть не менее важны, чем классические продуктовые (бизнес != продукт), но с ними важно работать иначе, и не пытаться описывать их через пользовательские события, да и пользовательские метрики в них часто не нужны.
____
Ещё про фреймворки для исследований:
https://t.me/uxread/102 как структурированно продумывать исследовательские задачи, вопросы и гипотезы
https://t.me/uxread/87 feature canvas для планирования работы над фичей
https://t.me/uxread/144 - хорошие кейсы применения продуктовой аналитики
#Frameworks
Напоследок - у некоторых фич очень сложно обнаружить целевой сценарий: его нет ни в ТЗ, ни в коммуникациях, не понятны ни метрики успешности, ни метрики качества.
Такое может быть, если фича делается не для удобства пользователя, а для других целей: пиара (привлечение внимания с помощью хайповой технологии), маркетинга и продаж (больше буллет поинтов в таблице сравнения с конкурентом), или под пожелания конкретного инвестора.
Для бизнеса эти функции могут быть не менее важны, чем классические продуктовые (бизнес != продукт), но с ними важно работать иначе, и не пытаться описывать их через пользовательские события, да и пользовательские метрики в них часто не нужны.
____
Ещё про фреймворки для исследований:
https://t.me/uxread/102 как структурированно продумывать исследовательские задачи, вопросы и гипотезы
https://t.me/uxread/87 feature canvas для планирования работы над фичей
https://t.me/uxread/144 - хорошие кейсы применения продуктовой аналитики
#Frameworks
Telegram
UX Research
Написал статью о том, как планирую сложные исследования http://bit.ly/2XOXdvt
____
Другие фреймворки для мышления об исследованиях
https://t.me/uxread/145 как структурированно продумывать гипотезы для аналитики
https://t.me/uxread/87 feature canvas для планирования…
____
Другие фреймворки для мышления об исследованиях
https://t.me/uxread/145 как структурированно продумывать гипотезы для аналитики
https://t.me/uxread/87 feature canvas для планирования…
Как мы используем полнотекстовую базу транскриптов интервью вместо базы инсайтов
Мы начали использовать для исследований связку Zoom+Otter.ai, и пока получается неплохо.
Сам Otter - инструмент для автоматического транскрибирования интервью, в него можно вручную загружать записи для расшифровки, а можно интегрировать с Зумом, тогда все встречи будут стримиться в Otter и транскрибироваться в реальном времени (можно прямо во время беседы видеть субтитры). Работает он только для английского языка, но я хочу рассказать про то, как такие подобные инструменты в принципе могут повлиять на процесс исследований (уверен, на русском тоже появятся).
Во-первых, коллаборативная разметка транскрипта для быстрого отчёта.
Когда-то писал, что исследователи Airbnb обязуют наблюдателей делать заметки во время тестов. Один наблюдатель отвечает за саммари, другой за запись интересных цитат, третий - за доп вопросы, после интервью общая сессия на 10 минут для сведения заметок.
Как результат, наблюдатели не выключаются в телефон, как обычно, а у модератора есть уже почти готовый отчёт, написанный наблюдателями во время сессий.
С Оттером ещё лучше - он умеет в живом режиме стримить субтитры со встречи. Этот транскрипт по ходу могут размечать, комментировать, добавлять в него картинки и скриншоты из зума все участники с team аккаунтом.
Т.е. на выходе с каждой сессии у вас уже есть размеченный транскрипт со скриншотами.
Во-вторых, корпус расшифрованных интервью с полнотекстовым поиском.
При интеграции с Зумом все записи интервью автоматически транскрибируются и хранятся в Оттере. По ним работает полнотекстовый поиск - вы можете по ключевым словам искать все цитаты респондентов, связанные с конкретной тематикой.
Искать можно по всем записям сразу, или по выделенным группам записей, что позволяет сформировать запрос вида "покажи мне всё, что b2b клиенты когда-либо говорили про billing integrations, на любом интервью за последний год". Кроме полнотекстового поиска есть возможность размечать текст комментариями/тегами.
Окей, вы можете быстро искать упоминания любой проблемы в своих интервью. Это уже неплохо, хотя если вы пользуетесь платформой для тестирований вроде uzertesting или uzerzoom, то у вас всё это уже есть - и авторасшифровки интервью, и разметка тегами, и полнотекстовый поиск, и всё это сделано удобней. Но тут есть другой момент
Расшифровка и база транскриптов из всех интервью, а не только исследовательских
Другой момент заключается в том, что сессии с клиентами проводят не только исследователи, но ещё и аккаунт-менеджеры, сейлзы, продакты, дизайнеры, и даже тимлиды, если вы угорели по демократизации исследований. Их вопросы и нужные им инсайты пересекаются, но вы едва ли заставите сейлзов делать отчёты, или вести базу инсайтов. И вы не станете покупать учётку Юзертестинга на каждого из них, а вот учётка Оттера стоит 20$ в месяц на человека, что позволяет в теории подсадить на него всех, и получать расшифровки сессий с клиентами, независимо от того, кто их проводит.
А это значит, что дизайнеры, наконец, смогут послушать, что новые клиенты говорят сейлзам про онбординг в продукте, продакты послушать запросы на новые фичи, которые озвучивают аккаунт-менеджерам, а маркетологи помониторить все упоминания маркетинговых материалов во обсуждениях с клиентами.
Вот это тотальная видимость, которую мы заслужили.
____
Ещё про способы хранения инсайтов
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/44 Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся
Про автоматизации и nocode в исследованиях:
https://t.me/uxread/122 Cally.ru - русскоязычный аналог Calendly для автоскедулинга интервью
https://t.me/uxread/8 Как Mesosphere (b2b) настроили процесс ежеденедельных UX тестирований без выделенного исследователя
https://t.me/uxread/46 Tomer Sharon угорел по nocode и автоматизировал все процессы исследований, какие можно (рекрут, sheduling встреч, составление отчётов)
#ResearchNocode
#Bases
Мы начали использовать для исследований связку Zoom+Otter.ai, и пока получается неплохо.
Сам Otter - инструмент для автоматического транскрибирования интервью, в него можно вручную загружать записи для расшифровки, а можно интегрировать с Зумом, тогда все встречи будут стримиться в Otter и транскрибироваться в реальном времени (можно прямо во время беседы видеть субтитры). Работает он только для английского языка, но я хочу рассказать про то, как такие подобные инструменты в принципе могут повлиять на процесс исследований (уверен, на русском тоже появятся).
Во-первых, коллаборативная разметка транскрипта для быстрого отчёта.
Когда-то писал, что исследователи Airbnb обязуют наблюдателей делать заметки во время тестов. Один наблюдатель отвечает за саммари, другой за запись интересных цитат, третий - за доп вопросы, после интервью общая сессия на 10 минут для сведения заметок.
Как результат, наблюдатели не выключаются в телефон, как обычно, а у модератора есть уже почти готовый отчёт, написанный наблюдателями во время сессий.
С Оттером ещё лучше - он умеет в живом режиме стримить субтитры со встречи. Этот транскрипт по ходу могут размечать, комментировать, добавлять в него картинки и скриншоты из зума все участники с team аккаунтом.
Т.е. на выходе с каждой сессии у вас уже есть размеченный транскрипт со скриншотами.
Во-вторых, корпус расшифрованных интервью с полнотекстовым поиском.
При интеграции с Зумом все записи интервью автоматически транскрибируются и хранятся в Оттере. По ним работает полнотекстовый поиск - вы можете по ключевым словам искать все цитаты респондентов, связанные с конкретной тематикой.
Искать можно по всем записям сразу, или по выделенным группам записей, что позволяет сформировать запрос вида "покажи мне всё, что b2b клиенты когда-либо говорили про billing integrations, на любом интервью за последний год". Кроме полнотекстового поиска есть возможность размечать текст комментариями/тегами.
Окей, вы можете быстро искать упоминания любой проблемы в своих интервью. Это уже неплохо, хотя если вы пользуетесь платформой для тестирований вроде uzertesting или uzerzoom, то у вас всё это уже есть - и авторасшифровки интервью, и разметка тегами, и полнотекстовый поиск, и всё это сделано удобней. Но тут есть другой момент
Расшифровка и база транскриптов из всех интервью, а не только исследовательских
Другой момент заключается в том, что сессии с клиентами проводят не только исследователи, но ещё и аккаунт-менеджеры, сейлзы, продакты, дизайнеры, и даже тимлиды, если вы угорели по демократизации исследований. Их вопросы и нужные им инсайты пересекаются, но вы едва ли заставите сейлзов делать отчёты, или вести базу инсайтов. И вы не станете покупать учётку Юзертестинга на каждого из них, а вот учётка Оттера стоит 20$ в месяц на человека, что позволяет в теории подсадить на него всех, и получать расшифровки сессий с клиентами, независимо от того, кто их проводит.
А это значит, что дизайнеры, наконец, смогут послушать, что новые клиенты говорят сейлзам про онбординг в продукте, продакты послушать запросы на новые фичи, которые озвучивают аккаунт-менеджерам, а маркетологи помониторить все упоминания маркетинговых материалов во обсуждениях с клиентами.
Вот это тотальная видимость, которую мы заслужили.
____
Ещё про способы хранения инсайтов
https://t.me/uxread/96 база инсайтов Майкрософт
https://t.me/uxread/44 Tomer Sharon из WeWork первым сделал базу инсайтов на Airtable, на которую мы все теперь равняемся
Про автоматизации и nocode в исследованиях:
https://t.me/uxread/122 Cally.ru - русскоязычный аналог Calendly для автоскедулинга интервью
https://t.me/uxread/8 Как Mesosphere (b2b) настроили процесс ежеденедельных UX тестирований без выделенного исследователя
https://t.me/uxread/46 Tomer Sharon угорел по nocode и автоматизировал все процессы исследований, какие можно (рекрут, sheduling встреч, составление отчётов)
#ResearchNocode
#Bases
Telegram
UX Research
База инсайтов Майкрософт
Про библиотеку инсайтов Microsoft - the Human Insights System (HITS)
https://medium.com/microsoft-design/how-microsofts-human-insights-library-creates-a-living-body-of-knowledge-fff54e53f5ec
Сначала про процессы вокруг, потом про…
Про библиотеку инсайтов Microsoft - the Human Insights System (HITS)
https://medium.com/microsoft-design/how-microsofts-human-insights-library-creates-a-living-body-of-knowledge-fff54e53f5ec
Сначала про процессы вокруг, потом про…
Написал про technology acceptance model - как устроена модель, как с помощью опросника предсказывать adoption фич до запуска, и насколько это валидно
https://bit.ly/3hoCGYs
Пару фактов вынесу сюда:
1) В 2019-м вышло метаисследование (обзор 114 работ) на тему того, что TAM предсказывает использование цифровых технологий учителями.
2) Для бизнес систем TAM позволяет объяснить от 15 до 60% использования.
3) Athenahealth с 17-го года используют опросник для concept validation - скоринга фич на этапе концептов. Опрос позволяет прореживать баклог и отсекать нерелевантные для пользователей функции.
4) Хотя все говорят, что спрашивать об использовании напрямую нельзя, во многих исследованиях attitude toward adoption (замеренный опросником) довольно здорово коррелирует с реальным adoption в будущем.
____
Другие забавные методы:
https://t.me/uxread/89 Как проводить Кано
https://t.me/uxread/130 UX curve как опыт исследования опыт в динамике, дешёвая замена дневников
https://t.me/uxread/57 Как Superhuman научились оценивать достижение product-market fit опросником
Больше методов исследований #Methods
Больше "околонаучных" заметок #Science
https://bit.ly/3hoCGYs
Пару фактов вынесу сюда:
1) В 2019-м вышло метаисследование (обзор 114 работ) на тему того, что TAM предсказывает использование цифровых технологий учителями.
2) Для бизнес систем TAM позволяет объяснить от 15 до 60% использования.
3) Athenahealth с 17-го года используют опросник для concept validation - скоринга фич на этапе концептов. Опрос позволяет прореживать баклог и отсекать нерелевантные для пользователей функции.
4) Хотя все говорят, что спрашивать об использовании напрямую нельзя, во многих исследованиях attitude toward adoption (замеренный опросником) довольно здорово коррелирует с реальным adoption в будущем.
____
Другие забавные методы:
https://t.me/uxread/89 Как проводить Кано
https://t.me/uxread/130 UX curve как опыт исследования опыт в динамике, дешёвая замена дневников
https://t.me/uxread/57 Как Superhuman научились оценивать достижение product-market fit опросником
Больше методов исследований #Methods
Больше "околонаучных" заметок #Science
Medium
Technology acceptance model для проверки идей новых фич
Есть много моделей того, как люди выбирают, пользоваться им новой системой/продуктом, или нет. Часть моделей обладает прогностической…
Скоро дочитаю Ульвика и сделаю нормальный пост про desired outcomes и инновации, а пока вот заметка имени Деминга про то, как оценивать компетенции и нанимать https://bit.ly/3iNtTkh
Medium
Вы — не точка, а распределение.
Речь пойдёт о найме и развитии людей.
Вы наверняка знаете про "подталкивание" (nudge) - концепцию из поведенческой экономики о том, как влиять на решения людей с помощью позитивного подкрепления и непрямых указаний. Речь обычно о позитивных примерах вроде "если хранить здоровую еду на полках в супермаркете на уровне глаз, люди чаще покупают её и правильней питаются". И так в целом - когда пишут про nudge, чаще подразумевают "подталкивание во благо". В контексте UX термин используется редко.
Зато в UX часто используется другой термин - dark patterns. Концепции "nudge" и "dark UX patterns" очень схожи - мы стимулируем нужное поведение неявным образом, но в последнем случае скорее во вред пользователю, подразумевается "подталкивание во вред".
Концепция light UX patterns почти не встречается (пара статей на медиуме), хотя она очевидна, light UX patterns - уловки, которые стимулируют потенциально полезное для пользователя поведение - прочитать подробное описание продукта перед покупкой, использовать сложные пароли, потратить время на настройку сервиса под себя.
Тут можно порассуждать про звериный оскал капитализма (корпорациям не важно благо пользователей, только прибыль), или про то, что "вредные советы" часто виральней полезных (кроме случая с заповедями), но мы не будем.
Можно возразить, что при создании продукта почти все паттерны имплицитно light. Мы же в принципе создаём ценность для пользователя, все паттерны направлены на это.
Но на самом деле паттерны направлены на то, чтобы создать максимально продаваемый продукт, а не максимально полезный.
Польза и выручка могут конкурировать (у соцсетей высокий ретеншн но низкая полезность), могут коррелировать напрямую (в случае с utilitarian SaaS, ретеншн отчасти зависит от того, насколько продукт делает мою жизнь лучше), но редко совпадает.
Проблема ещё в том, что польза и воспринимаемая полезность тоже не всегда коррелируют. Высокие требования к паролю могут работать мне во благо, но они не увеличат НПС.
Зато в UX часто используется другой термин - dark patterns. Концепции "nudge" и "dark UX patterns" очень схожи - мы стимулируем нужное поведение неявным образом, но в последнем случае скорее во вред пользователю, подразумевается "подталкивание во вред".
Концепция light UX patterns почти не встречается (пара статей на медиуме), хотя она очевидна, light UX patterns - уловки, которые стимулируют потенциально полезное для пользователя поведение - прочитать подробное описание продукта перед покупкой, использовать сложные пароли, потратить время на настройку сервиса под себя.
Тут можно порассуждать про звериный оскал капитализма (корпорациям не важно благо пользователей, только прибыль), или про то, что "вредные советы" часто виральней полезных (кроме случая с заповедями), но мы не будем.
Можно возразить, что при создании продукта почти все паттерны имплицитно light. Мы же в принципе создаём ценность для пользователя, все паттерны направлены на это.
Но на самом деле паттерны направлены на то, чтобы создать максимально продаваемый продукт, а не максимально полезный.
Польза и выручка могут конкурировать (у соцсетей высокий ретеншн но низкая полезность), могут коррелировать напрямую (в случае с utilitarian SaaS, ретеншн отчасти зависит от того, насколько продукт делает мою жизнь лучше), но редко совпадает.
Проблема ещё в том, что польза и воспринимаемая полезность тоже не всегда коррелируют. Высокие требования к паролю могут работать мне во благо, но они не увеличат НПС.
❤1
Олег Якубенков на фейсбуке недавно просил поделиться примерами тестирования ценности без разработки продукта.
Откровений в комментариях нет, но есть много интересных и наглядных примеров, вынесу сюда основные (тем более, это довольно частый запрос от бизнеса к исследованиям) https://www.facebook.com/lohmatyi312/posts/4671315759576757
1) В целом можно выделить два способа тестировать ценность - продуктовый и маркетинговый. Продуктовый о том, как сделать MVP продукта дешевле, проверив ключевую гипотезу, маркетинговый - как можно проверить гипотезу о ценности и каналах продаж, без разработки продукта в принципе.
2) Идеи из продуктового подхода:
- можно запустить продукт на чужой площадке (MVP маркетплейса в виде группы в фейсбуке)
- Отказ от автоматизаций (вместо разработки бота делать всё вручную, вместо умного ассистента отвечает группа ассесоров)
- Создание упрощённой версии на no-code инструментах (сделать всё на airtable)
- Использовать части других сервисов ("Когда делали визуальный конструктор для голосовых приложений, вместо того, чтобы сходу делать свой конструктор, взяли сторонний mindmap сервис, и вставили его через iframe к нам на сайт").
3) Из sales-first продуктоа
- Общий подход "сначала продать, потом делать".
- "Cold sales e-mails are the best, по конверсии сразу видно та ли аудитория и есть ли painpoint".
- Давать объявление о продаже на Юле, Авито и других маркетплейсах, ещё до производства. "Получил фидбек, измеряли количество обращений. сколько готовы ждать товар, как готовы платить и как удобно получать. Сделали первый заказ товара, продали, снова заказали. Market_fit."
- Запускать лендинг для проверки интереса к продукту до производства (http://plum.ac/, также запускали Рокетбанк)
- Можно даже без лендинга - для несуществующего сервиса делали объявления - лидосборники в fb, потом обзванивали и проводили интервью
- "В нашем случае, у нас все сервисы запускаются на руках агентов в чате. Декларируешь что есть сервис и побежал на заднем фоне делать под видом AI"
Кажется, исторически продуктовые исследователи не очень связывают себя с таким подходом. Никто не говорит "я умею проводить problem research интервью, а ещё умею придумывать MVP сервисов на нокоде, чтобы быстро проверить продуктовую гипотезу", хотя задачи в обоих случаях могут решаться схожие.
Понятно, что у таких подходов ограниченная применимость. Вы, вероятно, не сможете проверить так ценность новой функции в зрелом/сложном продукте. Вы не сможете проверить детали реализации фичи. И, наконец, большие компании (Банки, Телеком, в принципе не всегда готовы принять концепцию "давайте запилим лендинг несуществующего продукта на тильде", потому что комплаенс, служба безопасности, итд, и там культура таких экспериментов развита слабее.
Но я всё равно ожидаю, что таких запросов будет всё больше, и от исследователей всё чаще будут требовать подобных навыков.
Но я всё равно думаю, что навык такой проверки становятся критичным, особенно, если вы работаете в b2c продуктах, в hedonic-продуктах, и других где задачи и ценности пользователей не очевидны. И особенно, если вы работаете в небольшой компании, которая не боится запускать такого рода эксперименты.
#Methods
Откровений в комментариях нет, но есть много интересных и наглядных примеров, вынесу сюда основные (тем более, это довольно частый запрос от бизнеса к исследованиям) https://www.facebook.com/lohmatyi312/posts/4671315759576757
1) В целом можно выделить два способа тестировать ценность - продуктовый и маркетинговый. Продуктовый о том, как сделать MVP продукта дешевле, проверив ключевую гипотезу, маркетинговый - как можно проверить гипотезу о ценности и каналах продаж, без разработки продукта в принципе.
2) Идеи из продуктового подхода:
- можно запустить продукт на чужой площадке (MVP маркетплейса в виде группы в фейсбуке)
- Отказ от автоматизаций (вместо разработки бота делать всё вручную, вместо умного ассистента отвечает группа ассесоров)
- Создание упрощённой версии на no-code инструментах (сделать всё на airtable)
- Использовать части других сервисов ("Когда делали визуальный конструктор для голосовых приложений, вместо того, чтобы сходу делать свой конструктор, взяли сторонний mindmap сервис, и вставили его через iframe к нам на сайт").
3) Из sales-first продуктоа
- Общий подход "сначала продать, потом делать".
- "Cold sales e-mails are the best, по конверсии сразу видно та ли аудитория и есть ли painpoint".
- Давать объявление о продаже на Юле, Авито и других маркетплейсах, ещё до производства. "Получил фидбек, измеряли количество обращений. сколько готовы ждать товар, как готовы платить и как удобно получать. Сделали первый заказ товара, продали, снова заказали. Market_fit."
- Запускать лендинг для проверки интереса к продукту до производства (http://plum.ac/, также запускали Рокетбанк)
- Можно даже без лендинга - для несуществующего сервиса делали объявления - лидосборники в fb, потом обзванивали и проводили интервью
- "В нашем случае, у нас все сервисы запускаются на руках агентов в чате. Декларируешь что есть сервис и побежал на заднем фоне делать под видом AI"
Кажется, исторически продуктовые исследователи не очень связывают себя с таким подходом. Никто не говорит "я умею проводить problem research интервью, а ещё умею придумывать MVP сервисов на нокоде, чтобы быстро проверить продуктовую гипотезу", хотя задачи в обоих случаях могут решаться схожие.
Понятно, что у таких подходов ограниченная применимость. Вы, вероятно, не сможете проверить так ценность новой функции в зрелом/сложном продукте. Вы не сможете проверить детали реализации фичи. И, наконец, большие компании (Банки, Телеком, в принципе не всегда готовы принять концепцию "давайте запилим лендинг несуществующего продукта на тильде", потому что комплаенс, служба безопасности, итд, и там культура таких экспериментов развита слабее.
Но я всё равно ожидаю, что таких запросов будет всё больше, и от исследователей всё чаще будут требовать подобных навыков.
Но я всё равно думаю, что навык такой проверки становятся критичным, особенно, если вы работаете в b2c продуктах, в hedonic-продуктах, и других где задачи и ценности пользователей не очевидны. И особенно, если вы работаете в небольшой компании, которая не боится запускать такого рода эксперименты.
#Methods
Facebook
Oleg Yakubenkov
Поделитесь яркими примерами тестирования ценности без разработки продукта (свои или известные кейсы)
Ребят, я сделал русскоязычный аналог UX Coffee Hours - проект для обмена опытом между исследователями.
По сути это страничка со списком исследователей из разных tech компаний, готовых делиться опытом с коллегами.
https://researchtalks.ru/
Сценарий использования простой: вам нужен совет по конкретной проблеме (как делать mixed research, как нанимать синьоров, или стать синьором, или провести Кано итд), вы находите релевантного специалиста (в профиле каждого описан опыт и интересы), записываетесь на созвон по ссылке, и вперёд. Консультации бесплатные, длятся от 30 до 60 минут.
Уточню пару моментов:
- Проект в первую очередь про обмен опытом и получение "второго мнения" по конкретным проблемам, и в меньшей степени про поиск постоянных менторов.
- Отсюда профиль участников и формат описаний - старались делать упор на специализацию и уникальный опыт каждого. Кто-то хорош в кросс-культурных исследованиях, кто-то запускал хардверные продукты, кто-то круто автоматизирует процессы с помощью no-code, выстраивает передачу знаний в компании, умеет делать исследования рынка для привлечения инвестиций, или знает, как растить сильных специалистов.
- Если у вас есть интересный опыт, которым вы хотели бы делиться, можете написать мне, и я вас добавлю. Пока всё в ручном режиме, поэтому медленно и неторополиво.
https://researchtalks.ru/
___
- На английском есть похожие проекты: UX Coffee Hours и ADPList. По описанию они больше про карьерное консультирование (portfolio review, interview tips и всё такое), но тоже интересно.
- Есть отличное русскоязычное сообщество research ops, там тоже часто можно найти совет по конкретным проблемам, но оно закрытое https://www.facebook.com/groups/reops/
По сути это страничка со списком исследователей из разных tech компаний, готовых делиться опытом с коллегами.
https://researchtalks.ru/
Сценарий использования простой: вам нужен совет по конкретной проблеме (как делать mixed research, как нанимать синьоров, или стать синьором, или провести Кано итд), вы находите релевантного специалиста (в профиле каждого описан опыт и интересы), записываетесь на созвон по ссылке, и вперёд. Консультации бесплатные, длятся от 30 до 60 минут.
Уточню пару моментов:
- Проект в первую очередь про обмен опытом и получение "второго мнения" по конкретным проблемам, и в меньшей степени про поиск постоянных менторов.
- Отсюда профиль участников и формат описаний - старались делать упор на специализацию и уникальный опыт каждого. Кто-то хорош в кросс-культурных исследованиях, кто-то запускал хардверные продукты, кто-то круто автоматизирует процессы с помощью no-code, выстраивает передачу знаний в компании, умеет делать исследования рынка для привлечения инвестиций, или знает, как растить сильных специалистов.
- Если у вас есть интересный опыт, которым вы хотели бы делиться, можете написать мне, и я вас добавлю. Пока всё в ручном режиме, поэтому медленно и неторополиво.
https://researchtalks.ru/
___
- На английском есть похожие проекты: UX Coffee Hours и ADPList. По описанию они больше про карьерное консультирование (portfolio review, interview tips и всё такое), но тоже интересно.
- Есть отличное русскоязычное сообщество research ops, там тоже часто можно найти совет по конкретным проблемам, но оно закрытое https://www.facebook.com/groups/reops/
Королёв про всё остальное (ex UX Research) pinned «Ребят, я сделал русскоязычный аналог UX Coffee Hours - проект для обмена опытом между исследователями. По сути это страничка со списком исследователей из разных tech компаний, готовых делиться опытом с коллегами. https://researchtalks.ru/ Сценарий использования…»