Самое впечатляющее: если турбозарядить второй, выдуманный бренд, всеми шестью искажениями. Вы не поверите, что произошло потом — в некоторых категориях он забирал 90% выбора по сравнению с оригинальным. Такая вот рациональность. Только хлопья для завтрака позиции не сдают!

Почему всем нужен дневник исследований. Через три года можно открыть и живо вспомнить всё, что тогда волновало: шпаргалка по методам на синем фоне, рядом ответы на вечное «сколько людей надо набрать?», цели и план первого самостоятельного проекта в технологической корпорации по шагам.

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

Общий бюджет £1600: интервью по £50 и дневники по £145 суммарно, первые конструкты опроса на фиолетовой карточке, напоминание не забыть про случайный сэмплинг, а также посмотреть, как google набирают участников.

Сейчас я всё веду в Roam, но думаю возродить блокноты, писать рукой полезно.

Та самая шпаргалка по методам исследований из блокнота в расширенном и полезном для всех виде в Dropbox Paper. Если чего-то не хватило, пишите, добавлю.

У меня сегодня день рождения и лучшим подарком будет рассказать о канале кому-то подходящему или запостить ссылку у себя.

Спасибо, что читаете и общаетесь. Я тоже пишу потихоньку.

И сразу небольшой подарок — проект UX coffee hours.

Реально можно бесплатно получить получасовую консультацию у рисечеров, дизайнеров, менеджеров и ux-писателей из всех известных тех-компаний (Google, Facebook, WhatsApp, Airbnb, you name them). Ждут и начинающих, и постарше, калибр крутой и возможность очень ценная, особенно если нет своего круга старших коллег.

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

https://storage.googleapis.com/uxcoffeehours.com/site/index.html

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

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

Значит надо сделать новую для них уже нашу общую линзу и цель.⬇️

Если бы я писала тексты формата «десять вещей о людях, которые надо знать UX-исследователю», этот стоял бы на первом месте: уверенность запускает принятие решений.

- Люди принимают решение, когда чувствуют себя уверенными для него. [1]

- Это ещё и бессознательный процесс, запускающий нейронное возбуждение. [2]

- А ещё, есть участок мозга, мониторящий время с логикой: «Что-то решение принимается долго => Я не должна быть уверена => Решение не принимается» [3]

Закончила предложением вместе оценить, какие качества нашего продукта влияют на уверенность и решение купить или не купить билет у нас на сайте. Так нейрофизиология победила политику, инерцию — сами предложили всё переделать, вагончик тронулся.

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

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

https://telegra.ph/Do-pervogo-issledovaniya-kak-osoznat-podelit-i-poschitat-samyh-raznyh-polzovatelej-i-zaodno-splotit-komandu-11-10

Интересное метанаблюдение по работе за эти полгода: люди находятся в состоянии стресса с переработками, но одновременно с этим не хотят «бездельничать». Поэтому напрягают себя дополнительно, в основном когнитивно: Netflix/Twitch и одним глазом в какую-нибудь игру или паззл, домашние дела под аудиокнигу.

Эта тема всплывает сама примерно с середины первых локдаунов в июне на разных аудиториях и далёких друг от друга ислледованиях.

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

C кем ни заговорю, все либо уже выгорели, либо на пути туда.

Коллеги заняты без просветов, клиенты довольны, но результаты внутренних опросов про самочувствие пугают даже HR. Так в нашей experience design команде образовался еженедельный flow day в календаре (тупо не дёргают весь день), а потом добавились среды без встреч для всех в компании. Сильно ситуацию это не улучшило.

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

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

Он описывает состояние выгорания как последствие целеустремлённости или рвения человека, которое множится на внутренние высокие требования к себе и внешние организационные рабочие факторы. Другими словами, от угорания к выгоранию.

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

Судя по этому треду, всё могло быть намного хуже — человек довёл себя до ПТСР умственным перенапряжением и мозг просто временно схлопнулся

Напряжение я сбрасывала, печатая по паре предложений по интересам в Roam Research, и вот они выросли в цикл заметок про рост ux-исследователя вместе с прикладными приёмами, которые мне дико помогли не утонуть. Это ещё и вопросы, которые я чаще всего слышу через researchtalks и менторство nfng: учёба, управление сложными изменениями, как работать с разными данными, прототипы для исследований, структурная коммуникация, влияние в команде и как и никого не поубивать в процессе.

Если вы из новых читателей, добро пожаловать, я всё буду публиковать постепенно. Если вы из старых — спасибо за терпение!

Вот только я напрочь забыла всё про каналы в Tegeram, и как тут нормально сделать. Помогите понять, как мне публиковать тексты, если они довольно большие?

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

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

Сложные системы и управление изменениями в них, будь то команды, бизнесы, общества всегда многослойные и требуют деликатности в обращении. Поэтому мне лично очень помогла эта модель, чтобы примерно раскидать точки преткновения и понять ментальные модели влияния на систему. Её относят к книжке 1987 года, но первоисточник я так и не нашла и случайно перевела на русский.

На практике я успела обкатать эту модель под пять проектов: крупный редизайн на последние деньги нетехнологической компании (которая пытается догнать tech-конкурента), создание и проведение курса по коммуникации и визуализации данных для аналитиков, product-market fit для видео шоппинг b2b стартапа, и большой problem space research о мерчандайзерах Tesco. Модель работала безотказно даже на фоне беспросветных сомнений в своих мышлении, методах, знаниях и ценности для команды.

Особенно хочу отметить один проект из списка, где иногда казалось, что все квадраты на схеме — чёрные, причём одновременно. Просто выставка раннего Малевича: сервис без продуктовой стратегии (беспорядок), аутсорс-команда разработчиков (сопротивление), минимум аналитики, не самая удачная техническая миграция (паника), недоверие к исследованиям и отсутствие ресурсов внедрять заказанный редизайн. Отсюда я вынесла, что все эти пять критериев на схеме не обязательно должны быть «глобальными», чтобы успешно работать. Например, план действий не обязательно должен быть большим и всеобъемлющим, часто конкретных первых осязаемых шагов достаточно.

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

Я обожаю манифесты, особенно когда есть повод.

После прошлого поста поучаствовала в паре обсуждений с недопониманием роли ux-исследователя через симплификацию до юзабилити или «кастдева» и имела время и вдохновение описать, как я вижу из своего опыта роль ux-исследователя в продуктовых командах через понятную аналогию.

Эдвард Де Боно придумал технику шести мыслительных шляп, где каждая шляпа — отдельный и самостоятельный стиль принятия решений через разные перспективы, которые мы «надеваем» по очереди и смотрим на ситуацию. Посмотрела на нашу работу через несколько шляп, где нужны все, а иногда сразу.

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

2. Стратег
Мы даём командам осязаемые возможности принимать хорошие решения и прояснять текущую и будущую работу, помогаем обнаруживать новые направления для всего бизнеса и частей.

3. Ботан-учёный
Эта часть двойная: как про личную ответственность проведения этических и инклюзивных исследований, так и про надёжные и точные результаты, строгое соблюдение методологии, статистические методы. Уверенность, что и стратегические и тактические процессы исследований (выбор правильных методов и максимально безупречное проведение) соблюдаются на высоком уровне. Сюда же идёт нейтральная позиция при работе с данными и презентации, работа с когнитивными искажениями.

4. People's advocate
«Співець горя народного». По долгу службы приходится держать бубки инсайтов в голове, быстро вспоминать о пользовательских привычках посреди митинга и рассказывать убедительные истории и всё время помнить, что итерация бессмысленных продуктов — путь в никуда, чем бесить всех, принимающих решения бизнеса на следующий квартал.

5. Дипломат
Это ещё одна коммуникационная шляпа для исследователей, без которой никак не обойтись для маневрирования через минное поле внутренней политики, хотя при этом, саму работу тоже никто не отменял. Спектр действий — от простой медиации личных трений до сложных миротворческих операций.

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

7. Детектив
«Ничего не понимаю! Или что-то случилось, или одно из двух!». Наш процесс часто начинается с вопроса, который аж печёт и включает в себя процесс сбора улик через организацию и подозрительные вопросы пользователям.

8. Технарь
Всё, что связано с владением софтом, скриптами, хоткеями, бэкапами, техникой и аппаратурой для исследований и всяким таким. Куда ж без ящиков этих дурацких.

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

10. Учитель
Последняя в списке, но точно не последняя по весу шляпа. Мы учим другие команды и части бизнеса ценности нашего подхода (так иногда утомляет, сил нет), осмысленности принятия решений и помогаем коллегам (PM, продуктовые дизайнеры, PO's) делать какие-то простые исследования самостоятельно.

Если вдруг спросят про роль исследователя в команде, только так и буду отвечать теперь.

Прототипы для ux-исследований

Я никогда не упускаю случая дружелюбно сунуть нос в чужие прототипы для исследований. У большинства есть один недостаток — выглядят они хорошо, а вот для исследований не подобраны правильно, потому что не учитывают происходящее на сессии, человеческое поведение и соответствие задачам.

Прототип — это всегда репрезентация дизайна или некоторых его аспектов. Это переход от концептуальной модели к деталям имплементации. Они помогают нам быстро получать обратную связь и нащупывать unknown unknowns. Мы используем прототипы для тестирования с пользователями (формативной оценки) и обкатывания новых гипотез, поиска идей или чтобы нагляднее продать концепт или продукт. В каждом из этих случаев «прототип» будет значит что-то отдельное, поэтому я хочу описать подход для исследовательских прототипов.

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

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

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

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

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

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

С чего начинаются прототипы

1. Процесс прототипирования начинается с идей, а уже из них происходит переход к экранам (как кино начинается написанием сценария, а не со спецэффектов). На сессиях тоже тестируйте сценарии, а не экраны.

2. Используйте только максимально близкий к настоящему контент: текст, заголовки, картинки, уведомления. Никакого Lorem Ipsum или шуток, особенно для экспертных аудиторий. Модель данных прототипа всегда влияет на контекст пользователя и результаты. Никогда не забуду, как дизайнер вбил в продукт для спортсменов Эрдогана и героинь взрослых фильмов, люди просто сдувались на сессии.

3. До сборки прототипа, поймите его роль после тестирования: одноразовый, эволюционный или инкрементальный.

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

In praise of trade-offs

Прямого аналога слова trade-off в русском языке как будто бы нет, а ведь мы только в них и работаем. Каждый проект — набор совместных компромиссов и уступок. Мыслить ими помогает строить точку зрения и принципы принятия решений.

Это мышление неплохо работает и в коммуникации, внешней и внутренней. Допустим, один старый клиент любит оспаривать утверждённые детали и выкатывать внезапные правки. Беда в том, что даже самый вежливый восточноевропейский отказ в этом случае воспринимается как приглашение к конфликту (а это смертный грех номер ноль здесь 🇬🇧). Так я впервые в жизни перестала говорить «нет» и стала заходить с согласия и перечислять последствия и картины мрачного будущего с ошеломительным успехом.

«Да, конечно, мы можем внезапно поменять состав участников исследования и добавить ещё пару пенсионеров за счёт остальных групп. Правда, это ухудшит надёжность, будет стоить дополнительных денег и рискует перекосить результаты, но этот trade-off я готова принять и сделать, если он для вас важен. Кстати, расскажите, почему».

Или вот при попытках добавить в начале, середине и конце проекта работы сверх запланированной я уже механически спрашиваю «Правильно ли я понимаю, что X больше не приоритет?», открываю календарь и мы вместе смотрим, что оттуда можно выбросить, чтобы сделать все эти новые и интересные вещи.

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

"We would like you to focus on your process, trade-offs and impact more than specific insights that you may have generated."

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

А ещё начала собирать новую навязчивую идею: описать пять препятствий современной UX-практики, опираясь на опыт, классический подход к HCI и собственный характер. Три уже есть: игнорирование информационной архитектуры и моделей поведения, практики менеджеров продуктов и перекос в предпочтительных методах исследований, ещё два препятствия пока под вопросом. Обычно я фокусируюсь на прикладных моментах и решениях, но сейчас хочется расширить масштаб от «как это делать» до «зачем это всё надо».

Препятствие 1: игнорирование информационной архитектуры и моделей поведения

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

Информационная архитектура лежит в ДНК любого сильного продукта и системное мышление невозможно без её понимания. А мы, кстати, только системы и разрабатываем.

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

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

Так растёт UX-долг и технический долг, так мы получаем (и сами делаем) хаотичные роадмапы без ключевых структур, которые просто упустить с драматическими последствиями.