UX Research

Последнее время меня занимает, как можно улучшить качество дизайна (и исследований), вовлекая недизайнерские подразделения. Вот Iris Sprague (сейчас product designer в Google, но в статье описан опыт работы в абстрактном "fast growing startup") рассказывает, как работа с другими подразделениями помогла ей улучшить качество дизайна: https://uxplanet.org/ux-team-of-one-building-relationships-with-other-departments-to-ensure-your-success-105cce510d15 - Заманила разработчиков на ежемесячные дизайн-ретроспективы с помощью домашних печенек и расспрашивала о возможных улучшениях продукта. После 4-5 встреч все привыкли, разработчики стали засыпать ценным фидбеком, особенно про микровзаимодействия в дизайне, про которые они, в ходе создания кода, много думают. - В первую очередь важно вовлечь фронтенд разработку, но вот при создании API важно и бекенд тоже, потому что "Your mental models of the product and corresponding APIs need to match.". Очевидно, но не думал об этом так. - Организовала публичные демо дизайна для ребят из сейлз и customer care команд, чтобы собрать с них обратную связь. Первые несколько сессий прошли болезненно для обеих сторон, потом пошло легче - сейлзы лучше поняли, информация какого рода важна. - Вовлекала customer success team для рекрута участников на исследования и для ведения заметок на самом интервью. Для сustomer success и команды поддержки задача дизайнера очень понятна и близка - сделать продукт понятней для пользователей и снизить нагрузку на сustomer success, поэтому обычно они охотно помогают. Поделюсь своим личным опытом по теме: - Полезно делиться с сейлзами и аккаунт-менеджерами результатами исследований. Мы довольно давно привлекаем их для рекрута клиентов и сбора обратной связи по макетам, но только недавно я додумался присылать в конце проекта результаты исследований. Формат очень сжатый: "Ребята, спасибо, что помогли с интервью. Вот о каких проблемах мы узнали, часть поправим в ближайшем релизе, а другие попозже, пока они лежат в бэклоге в таком-то эпике". Стало работать лучше - всем понятней, что мы делаем, и зачем нам клиенты. - Саппорт подразделения всегда очень, очень сильно помогают в исследованиях - делятся аналитикой, помогают рекрутировать клиентов, готовы настроить нужные отчёты и морально поддерживают, так было везде, где я работал. Более того, из customer care и support специалистов получаются хорошие исследователи - всю часть про диджитал и HCD приходится объяснять с нуля, зато модерируют они почти сразу очень хорошо. - С данными от фронт подразделений (сейлз, аккаунты, саппорт) можно работать как с данными исследований и аналитики. Их можно использовать для поиска и проверки гипотез, для триангуляции данных от других методов, замешивать в mixed research вместе с данными аналитики и интервью, обогащать ими job stories и CJM. CRM с деревом тематик для кейсов помогает с количественными данными, полнотекстовый поиск (в случае поддержки по чату, или автотранскрибаторов для расшифровки разговоров) с поиском узких кейсов в конкретных сценариях. - Фронт подразделения - часть клиентского сценария. Если думать в терминах клиентского пути, то питчи и презентации сейлзов, такая же часть опыта, как лендинг, пуши и цепочка писем. Их тоже можно тестировать, компенсировать ими временные недоработки интерфейсов, или, как минимум, учитывать при описании контекста на тестировании. ___ Ещё по теме: https://t.me/uxread/50 - как Света Ратнер из контура вовлекла сейлз менеджеров в исследования https://medium.com/acronis-design/how-to-improve-the-ux-research-process-in-b2b-12b7475ef2cf - чуть подробней о том, как мы вовлекаем саппорт и аккаунт-менеджеров в Акронисе. #b2bResearch #Process

Наткнулся на манифест онтологического дизайна. https://medium.datadriveninvestor.com/the-manifesto-of-ontological-design-7fdb19169107 Давайте сразу признаюсь, что он тут не ради пользы, а потому что в нём встречаются подлинно поэтические куски вроде: "Chairs deny certain possibilities for how bodies exist in space, and enable others". "Стул отсекает некоторые способы существования тела в пространстве", ну не чудо ли, а? Чистое искусство. Всё-таки вытащу два вида тезисов - поэтические/философские (для души), и условно-практические (в качестве оправдания) Для души: - tools as prothesis - орудия труда можно воспринимать как расширения тела и сознания (extended mind и extended cognition, хорошо гуглится). Это известные красивые идеи - мы можем воспринимать ручку с бумагой, Figma, Miro и Obsidian как протезы/расширения нашей памяти и мышления -> создавая инструменты мы создаём человека - создание новых нотаций, фреймворков и вообще способов мыслить продвигает человечество к светлому будущему наравне с техническими достижениями. - we design our tools, and then they design us in return - инструменты, которыми мы пользуемся, влияют на нас самих (we design our tools, and then they design us in return). Стул, на которым вы сидите, влияет на осанку, а используемые вами инструменты - на то, как вы мыслите, на ваши ментальные модели итд, формируют вас. Т.е. инструменты не только являются "внешними расширеними" сознания, но и влияют на него в ответ. - Т.е. проектируя внешние объекты, мы конструируем это "расширенное" сознание. Через создание предметов быта и инструментов и проектируем сознание, mindware. Письмо сформировало нового человека, интернет - следующего, IDE формирует разработчиков, фигма - дизайнеров, музыкальные инструменты (и музыкальные традиции, лады) - музыкантов итд. Условно-практические: - "we design our tools, and then they design us in return" - каскадируется в более применимое "используемые инструменты влияют на ментальную модель пользователя и то, как он воспринимает интерфейсы", и мы можем учитывать при проектировании и исследованиях, какими ещё интерфейсами пользуются наши конкуренты -> какие паттерны им знакомы (немного тривиально, сори) - Внешние инструменты влияют на то, как мы мыслим -> граница между внешними инструментами и привычными схемами мышления размывается -> можно воспринимать эти схемы мышления как части продукта и "проектировать" их через внешние коммуникации/вебинары/обучающие материалы сейлзов/рассылки/транслируемые ценности в принципе. Напоследок вверну цитату из Лотмана: "Дело в том, что предметы старинного быта производились вручную, форма их отрабатывалась десятилетиями, а иногда и веками, секреты производства передавались от мастера к мастеру. Это не только вырабатывало наиболее удобную форму, но и неизбежно превращало вещь в историю вещи, в память о связанных с нею жестах. Вещь, с одной стороны, придавала телу человека новые возможности, а с другой – включала человека в традицию, то есть и развивала, и ограничивала его индивидуальность."

Выступлю в формате дайджеста, слишком многого не успеваю рассказать (UX horn прости, я разочек, потом вернусь к простыням своим занудным) Gender HCI, Feminist HCI, Post-Colonial Computing, Anti-Oppressive Design, and Design Justice https://medium.com/a-change-is-coming/gender-hci-feminist-hci-and-post-colonial-computing-f955a4054c89 Обзорная статья с кучей ссылок по совершенно незнакомой для меня теме Diversity-friendly software. Есть ссылки и на обоснования-манифесты о том, почему это важно (этические и утилитарные), и на конкретные методы/предложения (например, набор diversity персон с разными стилями мотивации, обработки информации, приверженности к риску итд). Портфолио начинающей UX исследовательницы на основе стажировки в Illumina Овервью, конкретный кейс Примечательно, что - оно простое, но чётенькое, хороший пример того, как можно упаковать свой опыт - даже если в овервью замазать все детали ярлычком NDA, всё равно будет хорошее портфолио Модель для обоснования ROI UX в b2b продуктах Оказывается, есть The Service-Profit Chain model, описывающая зависимость выручки от качества сервиса через customer loyalty (NPS итд). Опубликована в HBR в 2008 году, с тех пор происследована кучу раз (вот метаанализ) На основе неё Aaron Powers собрал UX-Profic Chain model, в той же логике, но с акцентом на product quality, usability и UX (проверил регрессионным анализом на двух разных продуктах, что от чего зависит и в какой степени). Вот рассказывает, как делал: https://medium.com/athenahealth-design/measuring-the-financial-impact-of-ux-in-two-enterprise-organizations-221f6c9ad9a3 Как качества продукта превращаются в пользовательский опыт https://www.researchgate.net/publication/226420570_The_Thing_and_I_Understanding_the_Relationship_Between_User_and_Product Старая (2001 год) и классическая статья Marc Hassenzahl, где во-первых, классная картинка, которая всё объясняет (она на второй странице, долистайте и вдохновитесь, плиз), во-вторых, про разницу между pragmatic и hedonic attributes продукта (мне его именно объяснение не очень нравится, но, кажется, именно он сделал разделение популярным). #b2bResearch, #Science

Сотня тестовых заданий от продактов как тренажёр для исследователей-мидлов Глеб Кудрявцев запустил "Карьерный цех" для продакт-менеджеров - опубликовал открытое тестовое задание для продактов, а потом составил открытый рейтинг продуктовых менеджеров из тех, кто прислал ответ, и выложил сделанные задания. Нам это интересно, потому что этот рейтинг для нас - база из сотни сделанных тестовых заданий от менеджеров продукта, можно посмотреть, как продакты осмысляют свои задачи, подумать, где им не хватает данных для принятия решений, понять, где исследования могли бы снизить риски, и: - нарезать это всё на ресерч брифы для новичков, которые должны подобрать оптимальный метод в нужной ситуации, и сделать план исследования - не нарезать на ресерч брифы, и дать более опытному исследователю, чтобы нашёл допущения и точки принятия решений сам и инициировал гипотетический ресерч Без пяти минут тренажёр для исследователя, короче (особенно задания 2 и 3), хоть симулятор делай (или карьерный цех для ресечеров).

Признаюсь, мне очень нравится идея open annotation тулов, и я хочу сделать с вами общий асинхронный ридинг клаб на основе hypothes.is. Нас там будет три с половиной гика, но я всё равно хочу попробовать (проще было бы комментарии открыть, но это не так интересно). Если всё уже понятно, то вот ссылка https://hypothes.is/groups/br3MN36A/ux-research, а если нет, сейчас объясню. Что за open-annotation тулы? Это инструменты (браузерные плагины, или подменялки ссылок на мобильных), которые позволяют оставлять заметки к тексту на любой странице. Эти заметки могут быть приватными (тогда это работает как личные пометки на полях, но для веб страниц), или публичными, видимыми для всех пользователей инструмента, или участников отдельной группы (тогда это работает как общий виджет комментариев или форум поверх любой страницы). По сути, они создают метаслой для комментариев (это предложение избыточно, очень хотелось использовать слово метаслой), выглядит вот так (ниже ещё картинка есть). У этого несколько забавных применений: - можно использовать как инструмент для обсуждения контента на сайте, не надо ничего в почту копировать - можно сделать странненькое метамедиа в формате "колумнист медузы комментирует ежедневные новости на царьград.тв", - можно использовать в образовании (инструмент встраивается в LMS, говорят, что помогает вовлекать студентов) И можно сделать reading club. Я читаю статьи, вы читаете статьи, Джефф Сауро (чем чёрт не шутит) читает статьи, все оставляют пометочки на полях, все могут оставлять пометочки к этим пометочкам, ну вы поняли. Я вот уже сделал группу на основе hypothes.is (он опенсорсный, работает на мобильных, поддерживает веб-стандарты для open annotation, не знаю, что это значит, но наверное хорошо). Приходите https://hypothes.is/groups/br3MN36A/ux-research #Methods

Статья, показывающая, что demand effects - искажения результатов исследования из-за того, что испытуемые знают гиптезу исследования (Хоторнский эффект, например) – не наблюдаются, по крайней мере, в онлайн опросах. Авторы варьировали информацию о гипотезе, которая даётся респондентам, и не нашли влияния этого фактора на результаты (исключение: когда соответствие гипотезе приводила к более высокому вознаграждению за участие в исследовании). https://scholar.princeton.edu/sites/default/files/jmummolo/files/demand_effects_9_2018.pdf

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

А вот ребята из Акрониса (то есть я:) написали здоровенную статью про разные ресерч опс штуки - рекрут, вовлечение команды, и хранение инсайтов. Особенно полезно, если вы занимаетесь b2b исследованиями, но и для b2c ок) Супер открытий там нет, но есть очень практичные рекомендации об инструментах и процессах, которые мне очень помогли бы, узнай я о них пару лет назад. https://medium.com/acronis-design/how-to-improve-the-ux-research-process-in-b2b-12b7475ef2cf По традиции перескажу некоторые детали (но вы всё равно зайдите и похлопайте) - Описал забавную пятиступенчатую схему вовлечения дизайнеров в исследования. Просто обучалки "как модерировать" не работают, важно вовлекать через активное наблюдение - чтобы участники команды на нескольких проектах вели протокол интервью или тестирования, наблюдая за исследователем. Это помогает имлицитно научиться основам модерации и плавно начать вести исследования самим. - Мы много рекрутим через фронт офис. Во-первых, находим клиентов с нужными сценариями через саппорт кейсы и связываемся с ними, во-вторых, часто подцепляемся с интервью на созвоны к аккаунт-менеджерам. Это работает очень хорошо для проверки точечных гипотез, хотя такие сессии нужно жёстко модерировать. - Мы много работали с конверсий рекрутинговых писем. В статье есть чеклист рекомендаций, например, обнаружили, что ссылки на calendly иногда воспринимаются как фишинговые, поэтому важно писать, что договориться о времени можно и письмом + ссылаться на какой-то опыт взаимодействия с клиентом в прошлом, чтобы повысить доверие (например, на недавно закрытый саппортный кейс) - Вместо базы инсайтов - база полнотекстовых транскриптов интервью, по которой можно искать и цитаты для быстрой сборки ad-hoc отчётов, и специфических клиентов для исследований. Мы делаем с помощью otter, но если вы на русском, можете использовать транскрибатор от Кирилла Улитина (https://t.me/ulitin_ru/13, вообще его канал отл, подпишитесь). ____ Про процессы в других компаниях https://t.me/uxread/104 - Спотифай https://t.me/uxread/123 - Ableton Ещё несколько по тегу #Companies #Recruitment

Команда Авито вместе с ResearchOps сообществом запустили опрос про рынок UX исследований в России. Давайте мы все его пройдём. Опрос занимает минут 7, заполнять его интересно, и лично мне он помог отрефлексировать процессы исследований в нашей команде (там есть классные вопросы-чеклисты про исследовательские практики) Ну и на результаты интересно посмотреть, их опубликуют в открытом доступе https://anketolog.ru/e/13012968/zLZfahmE

Ну что, у меня отпуск, а ещё пора бы уже до 1000 подписчиков добить, чтобы Ветров про меня написал, а Фабуза пришла за рекламой, поэтому вот вам парочка снобских мемов про исследования А в следующий раз напишу про подход к оценке ROI исследований в энтерпрайз продуктах, нашёл интересную модель (но ей я 1000 подписчиков, конечно, не наберу))

Немного про Ульвика, и про базу инсайтов на основе User Needs Подход Ульвика к JTBD - трудоёмкий, но очень последовательный. Он говорит, что обычные jobs слишком верхнеуровневые, и на основе них продукт улучшать нельзя, поэтому предлагает дробить их на desired outcomes - более атомарные потребности (он подробно описывает, как это делать). В одном из канонических примеров, у медсестёр в госпитале при использовании ранозаживляющего средства есть job "залечить рану", но внутри есть разные desired outcomes: "чтобы рана быстрее заросла" и "чтобы рана не стала хуже, не воспалилась". Это две разные потребности, за них отвечают разные качества продукта, и их можно маркетировать по-отдельности. Ульвик в исследовании обнаружил, что вторая потребность недообслужена - медсёстрам в первую очередь важно, чтобы рана не становилась хуже, а все производители продвигаются через "быстрее заживёт". Производитель поменял маркетинговую коммуникацию и в несколько раз увеличил долю рынка. Подход Ульвика: 1. С помощью интервью найти и сделать полный список этих гранулярных outcomes для какой-то деятельности (в примерах Ульвика их порядка 100-200 на одну большую задачу, он проводит от 30 до 80 интервью) 2. с помощью опросов приоритезировать эти outcomes по важности и тому, насколько они хорошо закрыты (опрос на 3. разделить всё это по сегментам, выделить opportunity segment - т.е. сегмент клиентов с недообслуженными outcomes 4. выпустить продукт под эти outcomes, заточить маркетинг под них. Вся последовательность действий (у него это не четыре шага, а, кажется 22) подробно и пошагово описана у него в статьях и книгах, большинство из которых бесплатны. И вот статья, которая немного вернула мне веру в базу инсайтов - автор сделал для своего продукта полный список user needs, и группирует инсайты в базе по ним. https://medium.com/researchops-community/user-needs-refinement-why-and-how-to-do-it-2ca4d28ade0d Чем это круто: - Сам по себе список needs/outcomes (об этом говорит и сам Ульвик) позволяет всей компании говорить на одном языке, и планировать и маркетинговые компании и продуктовые улучшения, отталкиваясь от общего списка конкретных микросценариев/needs. Сокращается разрыв между маркетингом, продуктом и исследованиями, когда продакты пилят фичи, маркетологи промоутируют уникальные технологии, а исследователи изучают поведенческие паттерны, и все почти понимают друг друга, но не до конца. - Список outcomes конечный и более-менее фиксированный. Если вы пробовали делать базу инсайтов, то, возможно, знаете, что таксономия очень быстро расползается, становится сложно искать и ориентироваться, тут проблема отчасти решена. Сама статья очень хороша и в ней куча примеров - куча скринов, примеры формулировок needs, и даже ссылки на драфтовую версию базы. ____ Ещё по теме: - https://jobs-to-be-done.com/outcome-driven-innovation-odi-is-jobs-to-be-done-theory-in-practice-2944c6ebc40e - обширная статья Ульвика с описанием подхода - https://strategyn.com/outcome-driven-innovation-process/ - бесплатная книга Ульвика по теме (там расписаны детали - как формулировать outcomes и искать сегменты) - http://strategyn.com/wp-content/uploads/2019/10/Bosch-Case-Study-Strategyn.pdf - как Ульвик помог сделать лучшие на рынке США циркулярные пилы - https://www.youtube.com/watch?v=ArpKdFH5HO8&t=0s - честный и классный рассказ ребят из Wrike о том, как они проводили исследование по Ульвику, но ничего не вышло - https://medium.com/athenahealth-design/scaling-user-research-in-an-agile-r-d-organization-71f9be1097e2 мои любимчики, athenahealth, тоже делали исследование, и довольно удачно #Methods, #Bases

Года два назад писал про хороший способ тестировать интерфейсные тексты - highlighter testing, с тех пор несколько раз провёл, и выяснил, что тестировать так можно не только тексты, но и макеты, и даже список требований к продукту. Напомню суть - вы даёте респонденту текст и просите разметить слова и фразы в нём разными цветами, в зависимости от того, какие эмоции эти слова вызывают: "выделите в тексте зелёным всё то, что вызывает доверие, а красным - всё то, что пугает". Проводить можно на распечатке, в ворде, в SurveyGizmo или Oprosso (в обоих есть такой вид вопроса). На выходе получается что-то вроде тепловой карты, отражающей удачные и проблемные места в тексте. Поделюсь своим опытом: Тестировать можно не только текст - Способ хорошо сработал для быстрой черновой приоритезации требований. Нам нужно было быстро понять, какие из 50 возможных функций полезны, а какие - нет. Оказалось, что разметить 50 опций нужными цветами не так занудно, как заполнить 50 шкал Ликерта, или даже отмечать 50 чекбоксов, механика меньше приелась (сделать более короткий опросник с помощью рандомизации вопросов мы не могли, это b2b, респондентов мало). - Вот тут автор заходит дальше, и предлагает использовать highlighter не только на текстах, а на макетах в целом, и давать подчёркивать любые элементы интерфейса. Выглядит неплохо (и правда, почему нет?), но сам не проводил. Можно тестировать сайт в реальном контексте с помощью сервисов для комментирования страниц Опросные инструменты позволяют тестировать чистый текст, загнанный в опросник. Если важен контекст, и вы хотите, чтобы текст размечали на живом сайте, можно использовать сервисы для комментирования на веб-страницах. Я люблю такие сервисы, и перебрал с десяток (FactualNote, Diigo, Hypothesis, и другие), для наших целей Hypothesis самый адекватный, и всё равно подходит не идеально. Он позволяет каждому из пользователей оставить комментарии к странице и разметить текст, но сводить результаты по нескольким людям всё равно надо вручную, очень неудобно. Как проводить, сколько времени закладывать - Всё происходит очень быстро - пару дней от запроса до результатов. Как я писал выше highlighter testing есть в виде встроенного вопроса в Oprosso и SurveyGizmo, интерпретируется он так же просто, как first click. Я делал через гизмо, потому что мы пользуемся им в Акронисе исторически. - Можно давать больше двух дескрипторов/маркеров за раз (до 4-х норм), но никогда не назначайте на один маркер две смешанные характеристики, вроде "отметьте красным то, что кажется глупым или непонятным, а зелёным то, что кажется умным и понятным, будет очень сложно потом анализировать. Да, это очевидно, но кто не делал глупых ошибок, верно? - Важны комментарии к разметке. В SurveyGizmo есть возможность комментировать каждое подчёркивание маркером, и эти комментарии - самое ценное (в Oprosso, думаю, тоже есть такое). Пользователи обычно оставляют комментарии только к небольшой части пометок, лучше специально об этом просить в тексте задания. - Исследование такого рода можно более-менее легко отдавать начинающим исследователям или смежным подразделенями, которых вы начали вовлекать в общение с клиентами. Структурированный формат позволит им меньше волноваться, а вам - получить надёжные данные данные. #Methods

Очень смешная статья, на живую тему "can mess-loving UX researchers win over metrics-loving executives?", т.е. "как своими пятью респондентами и горой стикеров убедить менеджеров, которые любят цифры" (ёкнуло сердечко, а?). Супер инсайтов не будет, но это своё, родное, ресечерское, не могу не опубликовать. https://uxdesign.cc/ux-researchers-win-over-metrics-loving-executives-b1b22104ea7c Автор описывает знакомую нам проблему: вы проводите исследование на шести людях. Трое из них справились отлично, а трое вели себя странненько, не заметили здоровенный call to action на главной странице (как? Ну каак?), и начали хаотично гулять по сайту. Вы приносите результаты вице-президенту, и он говорит “This was only 3 people from a sample of 6 — in a research study. Are we really going to change the site based on this? I’d like to see some bigger numbers …”. В ответ исследователь выбирает один из 4 типичных ответов (ребята знают жизнь): - "The Nielsen" (5 человек достаточно) - "The More-of-the-Same" (ну ок, давайте ещё 5 интервью проведём) - “The Buck Pass” (за количественной валидацией идите к аналитикам, это не к нам) - "The Dismissal” (они ничего не понимают, давайте забьем, поищем заказчиков поумнее) Дальше прогон про эмпатию - они постарались отойти от типичной реакции и глубже разобраться, почему заказчику нужны большие цифры, какие опасения у менеджеров, как они презентуют информацию руководителям, и какие опасения у руководителей. Это неплохо - мне кажется, исследователи часто работают отдельно как внутреннее агентство, и забывают про корпоративный контекст, в котором варятся заказчики. Ну и счастливая развязка - всем помог mixed research. В данном кейсе они сделали доп. анализ и увидели, что данные из гугл аналитики подтверждают результаты интервью, это убедило менеджеров, сайт переделали, всё стало хорошо. Про нарративную роль смешанных исследований (упс, немного высокопарно, извините) недавно здорово писали Spotify - интервью в чистом виде не вызывают достаточно доверия, чистые аналитические отчёты суховаты, а вот истории из смешанных данных полнокровны и убедительны: вот мы увидели паттерн на интервью, вот цитата респондентов про него, вот данные по двум тысячам людей, которые позволяют предположить этот паттерн у 40% пользователей такого типа. ___ А вообще толковей всех про mixed research рассказывает Антон Марцен. Можно подписаться на его канал, можно погуглить видео с кейсами, а можно пойти на researchtalks и записаться с ним поговорить) #Cases

Ребят, я сделал русскоязычный аналог 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/

Олег Якубенков на фейсбуке недавно просил поделиться примерами тестирования ценности без разработки продукта. Откровений в комментариях нет, но есть много интересных и наглядных примеров, вынесу сюда основные (тем более, это довольно частый запрос от бизнеса к исследованиям) 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

Вы наверняка знаете про "подталкивание" (nudge) - концепцию из поведенческой экономики о том, как влиять на решения людей с помощью позитивного подкрепления и непрямых указаний. Речь обычно о позитивных примерах вроде "если хранить здоровую еду на полках в супермаркете на уровне глаз, люди чаще покупают её и правильней питаются". И так в целом - когда пишут про nudge, чаще подразумевают "подталкивание во благо". В контексте UX термин используется редко. Зато в UX часто используется другой термин - dark patterns. Концепции "nudge" и "dark UX patterns" очень схожи - мы стимулируем нужное поведение неявным образом, но в последнем случае скорее во вред пользователю, подразумевается "подталкивание во вред". Концепция light UX patterns почти не встречается (пара статей на медиуме), хотя она очевидна, light UX patterns - уловки, которые стимулируют потенциально полезное для пользователя поведение - прочитать подробное описание продукта перед покупкой, использовать сложные пароли, потратить время на настройку сервиса под себя. Тут можно порассуждать про звериный оскал капитализма (корпорациям не важно благо пользователей, только прибыль), или про то, что "вредные советы" часто виральней полезных (кроме случая с заповедями), но мы не будем. Можно возразить, что при создании продукта почти все паттерны имплицитно light. Мы же в принципе создаём ценность для пользователя, все паттерны направлены на это. Но на самом деле паттерны направлены на то, чтобы создать максимально продаваемый продукт, а не максимально полезный. Польза и выручка могут конкурировать (у соцсетей высокий ретеншн но низкая полезность), могут коррелировать напрямую (в случае с utilitarian SaaS, ретеншн отчасти зависит от того, насколько продукт делает мою жизнь лучше), но редко совпадает. Проблема ещё в том, что польза и воспринимаемая полезность тоже не всегда коррелируют. Высокие требования к паролю могут работать мне во благо, но они не увеличат НПС.

Скоро дочитаю Ульвика и сделаю нормальный пост про desired outcomes и инновации, а пока вот заметка имени Деминга про то, как оценивать компетенции и нанимать https://bit.ly/3iNtTkh