Немного про Ульвика, и про базу инсайтов на основе 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

Команда Авито вместе с ResearchOps сообществом запустили опрос про рынок UX исследований в России. Давайте мы все его пройдём.
Опрос занимает минут 7, заполнять его интересно, и лично мне он помог отрефлексировать процессы исследований в нашей команде (там есть классные вопросы-чеклисты про исследовательские практики)

Ну и на результаты интересно посмотреть, их опубликуют в открытом доступе https://anketolog.ru/e/13012968/zLZfahmE

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

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

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

https://scholar.princeton.edu/sites/default/files/jmummolo/files/demand_effects_9_2018.pdf

Признаюсь, мне очень нравится идея 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

Сотня тестовых заданий от продактов как тренажёр для исследователей-мидлов

Глеб Кудрявцев запустил "Карьерный цех" для продакт-менеджеров - опубликовал открытое тестовое задание для продактов, а потом составил открытый рейтинг продуктовых менеджеров из тех, кто прислал ответ, и выложил сделанные задания.

Нам это интересно, потому что этот рейтинг для нас - база из сотни сделанных тестовых заданий от менеджеров продукта, можно посмотреть, как продакты осмысляют свои задачи, подумать, где им не хватает данных для принятия решений, понять, где исследования могли бы снизить риски, и:
- нарезать это всё на ресерч брифы для новичков, которые должны подобрать оптимальный метод в нужной ситуации, и сделать план исследования
- не нарезать на ресерч брифы, и дать более опытному исследователю, чтобы нашёл допущения и точки принятия решений сам и инициировал гипотетический ресерч

Без пяти минут тренажёр для исследователя, короче (особенно задания 2 и 3), хоть симулятор делай (или карьерный цех для ресечеров).

Выступлю в формате дайджеста, слишком многого не успеваю рассказать (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

Наткнулся на манифест онтологического дизайна.
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" - каскадируется в более применимое "используемые инструменты влияют на ментальную модель пользователя и то, как он воспринимает интерфейсы", и мы можем учитывать при проектировании и исследованиях, какими ещё интерфейсами пользуются наши конкуренты -> какие паттерны им знакомы (немного тривиально, сори)

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


Напоследок вверну цитату из Лотмана:
"Дело в том, что предметы старинного быта производились вручную, форма их отрабатывалась десятилетиями, а иногда и веками, секреты производства передавались от мастера к мастеру. Это не только вырабатывало наиболее удобную форму, но и неизбежно превращало вещь в историю вещи, в память о связанных с нею жестах. Вещь, с одной стороны, придавала телу человека новые возможности, а с другой – включала человека в традицию, то есть и развивала, и ограничивала его индивидуальность."

Последнее время меня занимает, как можно улучшить качество дизайна (и исследований), вовлекая недизайнерские подразделения.

Вот 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

Umux-lite, Supr-q, NPS это, конечно, хорошо, но давайте поговорим про кроссовочность, круглоту и вопросы на основе эмодзи.

Речь о чём: когда мы говорим об измерении субъективных характеристик - удобстве, красоте, инновационности (я мешаю тут в кучу метрики удовлетворённости и бренд дискрипторы), мы:
- либо делаем это, подразумевая, что эти субъективные характеристики влияют на поведение пользователей: отток, количество рефералов, количество саппорт кейсов (метрики удовлетворённости обычно рассматриваются как предикторы лояльности и LTV)
- либо хотим быть консистентными в том, какие эмоции мы вызываем, и транслировать, что мы инновационные/семейные/дерзкие во всех каналах и продуктах.

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

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

И могу измерять эту характеристику вопросами типа "оцените, насколько новый сайт похож на 🧜‍♀️ по семибалльной шкале.
Или "насколько комфортно было бы нашему продукту жить в воде" от "абсолютно некомфортно" до "абсолютно комфортно".

Даже можно не заморачиваться с валидностью опроса: раз русалочность я придумал только, что, значит она, по определению, идеально измеряется придуманным мной же и единственным существующим опросником русалочности, всё как с NPS. Ну а надёжность можно быстро проверить, прогнав опрос.

Или это не так работает?

После перерыва сложно писать практичные посты, позволю себе поспекулировать про схожесть естественного и интерфейсного языков.

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

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

Развивается он похоже на обычную письменность.
Письмо началось с картинок и пиктограмм, похожих на реальные объекты.
Скевоморфические иконки, интерфейсные текстуры в первом айфоне, метафоры папки, файла и рабочего стола тоже максимально повторяют физический мир.

Современные иероглифы на реальные объекты похожи уже меньше, современные поколения иконок и паттернов тоже более схематичны, прямой смысл старых иконок выветривается.
Иконка дискеты для части пользователей - абстрактная морфема сохранения, не связанная с реальным объектом (тут вообще подходит слово "морфема"? Слишком увлекся, чтобы проверять).

Наконец, уже есть иероглифы для абстрактных понятий, у которых нет физической оболочки. Паттерны такие тоже появились - ничего, похожего на сториз в физическом мире нет - это не папка, и не лента/свиток контента.
Интерфейсный паттерн без соответствия в реальном мире ~ иероглиф абстрактного понятия.
Станут ли интерфейсные обозначения атомарными, как буквы, будут ли у нас свои финикийцы? Не понятно.

Дальше, и у языков, и у интерфейсов есть региональная специфика. Азиатские интернет-магазины выглядят непривычно для нас - несмотря на глобализацию, визуальный язык уже успел разделиться на разные визуальные диалекты. Нам сложно работать с китайским визуальным диалектом и сложно понимать его. Поэтому копировать WeChat 1в1 для аудитории США нельзя, хотя заимствовать отдельные слова можно.

В моделях распространения языков и интерфейсов тоже много общего.
И в языках и в интерфейсах распространение визуального/разговорного диалекта чаще всего зависит не от удобства/качества, а от дистрибуции и маркетинга.
Эсперанто создавали супер юзабельным, но на нём говорит в 500 раз меньше людей, чем на английском или китайском.
Ранний захват рынка и влиятельные последователи решают всё, простота и виральность - не всегда.
В интерфейсах все переиспользуют паттерны faang, не потому что они удобней всего, а потому что они на виду/под рукой для дизайнера, и потому что у них автоматически много носителей, они быстро становятся общепринятыми.

Интересно, что в некоторых случаях язык распространяется по модели b2c - когда толпа влиятельных последователей постепенно переводит всех своих друзей и детей на ваш язык, а иногда по b2b, когда новый язык внедряется в колониях сверху и централизованно, как сап.

А ещё иногда официальный язык для богослужений и официальных отчётов один (Скайп для бизнеса), а дома и в неформальной обстановке все говорят на втором (Телеграм удобней). А иногда комплаенс преследует использование "домашнего" языка и искореняет его.

Но интересно, что у языков прирост происходит в основном за счёт детей последователей, а в продуктах - за счёт пока ещё бессловесных. Почему мы не закладываем в модели роста продукта коэффициенты рождаемости наших клиентов? Бессмысленный вопрос.

Немного трендвотчинга напоследок: массовое распространение VR ненадолго откатит нас к нативным/консервативным интерфейсам (но уже привычные сториз никуда не денутся), но лет через 5 там тоже начнут появляться метафоры, которых в реальном мире нет.