UX Research

2022-08-13 16:30:36 Ну и оговорюсь, что хотя прошло почти полгода, я так и не придумал, как писать в канал, чтобы это ощущалось этичным и уместным на фоне происходящего. Извините Открыть/Комментировать

2022-08-13 16:30:30 Как считать окупаемость исследований
Обычно UX исследователя просят посчитать ROI не для того, чтобы получить точную выверенную модель (иногда да, но обычно нет), а чтобы проверить, что она/он не блаженные и мыслят с бизнес-заказчиком в одних категориях.

Формально верный ответ на просьбу оценить окупаемость ресерча такой: "давайте сделаем a/b тест, выпустим часть фичей с исследованием, часть без, по 100 на группу, только надо уравновесить фичи по всем параметрам", или "давайте сделаем регрессионный анализ и оценим влияние исследований и дизайна" или "давайте посмотрим на Service-Profit Chain model и посчитаем всё как там". Всё это прекрасно, правильно, и в среднем проекте нереализуемо. При формально верном ответе вы проваливаете тест на адекватность, вас запишут в категорию умниц-эрудитов, с которыми полезно посоветоваться, но каши не сваришь.

Ответ получше (повторюсь, не всегда так, иногда нужна "Service-Profit model" нужно уточнять контекст задачи итд итп, но часто именно так) - приблизительно прикинуть ценность исследований в деньгах. Она оценивается в рамках ценности всей доработки продукта, в том же кейсе. Сейчас объясню.

Когда продакт берёт в работу фичу, он делает мысленную или реальную прикидку по её рентабельности.
Примерно так:
Затраты: запилить блок рекомендаций стоит спринт продуктовой команды, это где-то 1.2млн, если считать по текущим ставкам.
Доходы: я предполагаю, что конверсия вырастет на 0.1% (из бенчмарков, из сравнения с похожими фичами, из опыта, ещё как-то). С учётом текущей конверсии, среднего чека, и маржи, это + 40к в день
Итог: 1.2 млн/40 тысяч - фича отобьётся за 30 дней. Неплохо.

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

Исследования можно посчитать по схожей схеме:
Расходы: время исследователя + время дизайнера на прототип + время команды на переделки + рекрут ~ 300к.
Доходы: мы на 10% увеличим эффективность фичи, будет не 0.1%, а 0.11%, ещё +4к в день.
Итог: 300/4 - окупится за 2.5 месяцев примерно

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

Дальше можно обсуждать и детализировать - а сколько стоит сдвиг фичи на неделю (ещё почти 300к), а есть ли ещё упущенная выгода от сдвига сроков, а как получили +10% эффективности и т.д. Ещё можно думать, можем ли мы сделать дешевле (немодерируемое тестирование сократит стоимость раза в два) или повлиять больше.
Это всё обсуждаемо, но важно, что вы в принципе попробовали прикинуть, за счёт чего исследования могут окупаться, в терминах, понятных для бизнес-заказчиков, и с вами можно иметь дело.

Со стратегическими исследованиями так работает хуже, они дороже и их сложнее обосновать. Тут важнее культура компании и ваше влияние.
Ну и понятно, что фундаментальные исследования по HCI и UX обосновываются иначе. Открыть/Комментировать

2021-10-06 09:48:01 Метрики продукта и рынок труда
На рынке сейчас не хватает курьеров, официантов, вообще работников из сфер сервиса и обслуживания, дефицит огромный. Как это повлияет на метрики продуктов в этой сфере?

Вернёмся на шаг назад - в b2b и внутренних продуктах метрики вроде LTV и оттока работают плохо. Они запаздывают и их нельзя измерить на маленькой выборке b2b клиентов.
Поэтому качество продукта пытаются измерить другими способами - через объективные показатели (время на операцию, кол-во кликов, GOMS), или субъективные (NPS, CSI, SUS, UMIX итд).
Если выбираете, фокусироваться на количестве кликов или на NPS, есть простая эвристика - чем важнее итоговый пользователь, тем важнее субъективные метрики.

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

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

Atlassian (Jira, Confluence) сделали ключевой метрикой NPS в том числе потому, что разработчиков на рынке настолько не хватает, что они (разработчики) могут навязывать работодателям удобную для них систему, даже более дорогую.
Salesforce с NPS не торопится, т.к. дефицит сейлзов на рынке меньше.
Системы IP телефонии торопятся ещё меньше. Они стараются, очевидно, делать удобные продукты, но это не так приоритетно для них, т.к. итоговые пользователи менее дефицитны и влиятельны.

Вернёмся к курьерам. Их не хватает, компании начинают повышать зарплаты, чтобы удержать людей. Повышать зарплаты дорого, чтобы удерживать не только зарплатой, улучшают условия труда и employee experience (EX, по аналогии с CX) - страховки, больничные, принимают людей в штат. Удобное приложение в этом же ряду, оно гораздо менее важно для курьера, чем программа страхования, но и стоит оно для компании потенциально десятки раз меньше, поэтому роль субъективных метрик в продуктах для сервисных работников, как я ожидаю, возрастёт.

Соотношение спроса/предложения на рынке труда для пользователей в вашей отрасли можно найти на https://stats.hh.ru/ (для США такого же удобного пока не нашёл).
___
Ещё по теме - роль hedonic qualities в b2b продуктах в целом растёт https://t.me/uxread/138. Открыть/Комментировать

2021-09-28 19:58:44 Придумался забавный критерий удобного продукта - его много используют не по назначению.

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

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

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

___
Сразу ещё хочется поспекулировать про способность инструментов (физических и цифровых) становиться частью нас, про условия, в которых это происходит, но это отдельно, потом) Открыть/Комментировать

2021-09-09 19:38:02 4 режима поиска информации, и как проектировать для них
https://boxesandarrows.com/four-modes-of-seeking-information-and-how-to-design-for-them/

Модель Донны Спенсер не устарела за 15 лет (статья написана в 2006-м), она простая и практичная, и я часто использую её, когда продумываю сценарии продукта или исследования. Даже разок где-то ссылался (а, вот здесь), сейчас расскажу:

Донна выделяет 4 ситуации, в которых находятся люди, когда ищут что-либо:
1. Я не знаю, чего именно хочу (Don’t know what you need to know), например, зашёл на медиум посмотреть, чего бы почитать про UX.
2. Знаю, чего хочу в целом, но без конкретного объекта (Exploratory), хочу статью про то, как лучше презентовать результаты, но не знаю, какую.
3. Точно знаю, какой объект, информация или операция мне нужна (Known-item), мне рекомендовали статью конкретного автора, ищу её.
4. Хочу найти что-то, что уже находил ранее (Re-finding), хочу найти то, что уже читал.

Для каждого паттерна поиска нужны свои интерфейсные паттерны:
- Поиск полезен known-item, но бесполезен для don’t know what you need to know.
- Exploratory и Don’t know what you need требуют витрины, пушей, рассылок, и других способов рассказать пользователю о том, чего он ещё не очень ищет.
- Для re-finding помогут закладки/недавно посещённые страницы.

Хотя изначально это список сценариев поиска информации, он легко адаптируется для проектирования интерфейсов. Вот 4 состояния пользователя относительно функции в продукте:
1. Пользователь не знает, что в вашем продукте есть функция, надо донести (продакт маркетинг и онбординг в широком смысле)
2. Знает про функцию, но не понимает, как именно ей пользоваться, надо объяснить (онбординг фичи, эмпти стейты, стартовые сценарии)
3. Знает, понимает, нужно, чтобы было удобно (ежедневное взаимодействие)
4. Пользуется часто, нужно, чтобы продукт можно было адаптировать, нужная конфигурация настраивалась и сохранялась (настройка под пользователя) Открыть/Комментировать

2021-07-27 10:14:49 А вот тред по книге continuous discovery habits, буду понемногу читать и закидывать сюда заметки (continuous discovery книги по continuous discovery, хаха).

Книга про то, как строить customer-centered продуктовый процесс (авторка часто ссылается на HCD (училась в Стэнфорде), и desired outcomes)*, основана на 12-недельной программе коучинга продуктовых команд.

Насколько я понял, книга не про "как сделать всё классно", а про "как сделать всё классно, с учётом того, что вы уже про это читали, но почему-то не получилось" т.е. учитывает то, как меняются команды на самом деле.
И книгу и программу очень рекомендует Марти Кэган (который Inspired), а ещё у авторки, Терезы Торрес, толковый блог https://www.producttalk.org/ (нравится не только за название)

* Двойные скобки unlocked**
** Сноска в посте unlocked***
*** Сноска на сноску unlocked****
**** Сноска на сноску на сноску (а это уже бесконечная шутка, во всех смыслах) Открыть/Комментировать

2021-07-23 12:12:07 Интересно, что части продукта, сервиса и бренда редко сравнивают в одном исследовании.
Сравнительные исследования обычно сфокусированы на чем-то одном за раз, их вопрос звучит как "что важнее, сделать гибкие фильтры, или обновленный календарь", или "мы позиционируемся как супер надёжные, или как супер инновационные"?
Но редко звучит вопрос "Что важнее, гибкие фильтры, или репутация инновационной компании, или вообще чтобы поддержка быстрее отвечала"?
Но клиент то сравнивает всё это в куче.

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

Следствие 1: делаете сравнительные исследования - конжоинты, внутренние бэттлкардс, анализ по Ульвику, строите Кано - учитывайте внепродуктовые качества тоже.
(Знаю, что Ульвик и Кано создавали свои фреймворки для оценки свойств продукта, но кажется, их можно использовать и шире. Требования к репутации нормально формулируются в виде desired outcome).

Звучит контринтуитивно - запихнуть в одну диаграмму Кано признак "у нас есть фича n" и признак "нашу рекламу крутят по ТВ", но кажется, чтоб выбор так и работает.
Да, в рамках классического продукта вы выбираете, на что потратить ресурсы разработки, поэтому взвешиваете продуктовые фичи, но в рамках компании вы уже выбираете, нанять ли вам вообще больше разработчиков, или влить деньги в рекламу, или вообще потратить их на лоббиста и войти в реестр импортозамещающего софта.
Или, если вы продаете контент (ЛитРес, Яндекс.Музыка), вы выбираете потратить вам деньги на машин лернинг спецов, чтобы улучшить длинный хвост рекомендаций, или купить прав на новые книги и треки.
Поэтому имеет смысл сравнивать качества разного рода в одном списке, или хотя бы понимать, что это сравнимые и сравниваемые вещи - и для бизнеса, и для пользователя/покупателя.

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

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

Кажется, что логика та же - есть рынок, есть сегменты которым важны разные аспекты, от "быстро развиваются и всё первыми внедряют", до "самые дешёвые", важно этот рынок понять, найти свой сегмент, сформулировать ценность и захватывать свой кусочек рынка.
Можете накидать мне на @Node_of_Ranvier примеров, где исследования помогали решить, на чём сфокусироваться не только в рамках продукта, а вообще? Открыть/Комментировать

2021-07-17 00:56:49 После перерыва сложно писать практичные посты, позволю себе поспекулировать про схожесть естественного и интерфейсного языков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Или это не так работает? Открыть/Комментировать

2021-03-30 14:57:21 Последнее время меня занимает, как можно улучшить качество дизайна (и исследований), вовлекая недизайнерские подразделения.

Вот 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 Открыть/Комментировать