Zbs Research


Гео и язык канала: Весь мир, Русский
Категория: Дизайн


делает подборки про UX / постит всякое / Research Lead в Wildberries
@zbs_alex

Связанные каналы

Гео и язык канала
Весь мир, Русский
Категория
Дизайн
Статистика
Фильтр публикаций


🔤🔤

💎 О триангуляции в UX-исследованиях на одном примере

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

👀 Кому будет полезно: продуктовым исследователям

✔️ Основные мысли:
• Одного UX-метода часто недостаточно для понимания проблемы. Комбинация интервью, юзабилити-тестов, айтрекинга, анализа эмоций и количественных данных позволяет не только увидеть поведение пользователей, но и понять причины этого поведения, подтверждая выводы сразу из нескольких источников.
• В кейсе с «Нетмонетом» исследование показало, что некоторые элементы пользователи замечали, но не использовали из-за нелогичного сценария взаимодействия. Это позволило исправить не визуальные детали, а саму логику пользовательского пути и сделать сервис проще.
• Авторы показывают, что триангуляция — это не обязательно дорогое исследование с большим количеством инструментов. Даже при сжатых сроках можно проводить работу итерациями, сочетать качественные и количественные методы и постепенно подтверждать гипотезы, получая более надёжные результаты, чем при использовании одного метода.

📌 Что внутри статьи:
• Что такое триангуляция?
• Задача, которая подталкивает к триангуляции
• Первый подход к снаряду
• Второй подход
• Сводим данные
• Как применять триангуляции при разных вводных

➡️ Ссылка на статью

@ZbsResearch


👍 Возможно, я дурак… Как делать эффективные продукты в ситуации, когда никто ничего не понимает

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

👀 Кому будет полезно: продуктовым исследователям и продактам

✔️ Основные мысли:
• Большинство пользовательских ошибок вызвано не недостатком способностей, а когнитивной перегрузкой. Рабочая память человека ограничена, а стресс ещё сильнее снижает способность учиться и принимать решения. Если интерфейс требует одновременно удерживать слишком много информации или постоянно переключать внимание, вероятность ошибок резко возрастает.
• Хороший интерфейс должен не только быть понятным, но и создавать ощущение контроля. Предсказуемое поведение элементов, сохранение контекста, видимый прогресс, возможность безопасно отменить действие и своевременные подсказки снижают стресс пользователя и помогают ему увереннее выполнять задачи.
• Когнитивную нагрузку можно проектировать и измерять. Автор предлагает рассматривать когнитивный комфорт как полноценную UX-метрику: оценивать нейроиздержки интерфейса, выявлять сценарии с высокой когнитивной нагрузкой и устранять их, превращая психологические знания в практические принципы проектирования цифровых продуктов.

📌 Что внутри статьи:
• Почему пользователям сложно работать с продуктами
• Что происходит в мозге при освоении нового интерфейса
• Как проектировать интерфейсы, снижающие стресс
• Как оценивать когнитивную нагрузку продукта

➡️ Ссылка на статью

@ZbsResearch


🔤🔤🔤

📈 Метрики UX — как измерить пользовательский опыт

Софья Каневская, руководитель проектов Fastuna, объяснила, что такое UX-метрики, какие аспекты пользовательского опыта они помогают измерять и как правильно выбирать и сочетать разные показатели, чтобы объективно оценивать удобство продукта и принимать обоснованные продуктовые решения.

👀 Кому будет полезно: продуктовым исследователям

✔️ Основные мысли:
• Одна UX-метрика никогда не даёт полной картины пользовательского опыта. Поведенческие показатели (Task Success Rate, Time on Task, User Error Rate) показывают, что делает пользователь, а отношенческие (CSAT, CES, SEQ, NPS и другие) помогают понять, как он это воспринимает. Только их комбинация позволяет корректно оценить качество интерфейса и найти причины проблем.
• Метрики должны отвечать на конкретный исследовательский вопрос, а не собираться «на всякий случай». Выбор показателей зависит от цели исследования: для оценки успешности сценария подойдут TSR, ToT и UER, для оценки удобства — SEQ, CES, SUS или UMUX, а для анализа удовлетворённости и лояльности — CSAT, CSI и NPS. Каждая метрика должна помогать принять конкретное продуктовое решение.
• Цифры сами по себе не объясняют причины поведения пользователей. Даже если метрика показывает низкую успешность выполнения задачи, большое время или высокий уровень ошибок, она лишь фиксирует наличие проблемы. Чтобы понять её источник и определить, что именно нужно изменить в продукте, количественные метрики необходимо дополнять качественными исследованиями, такими как юзабилити-тесты, интервью или наблюдения.

📌 Что внутри статьи:
• Карта метрик
• Отношенческие метрики
• Поведенческие метрики
• Как выбрать UX-метрику под задачу
• Шпаргалка по всем метрикам

➡️ Ссылка на статью

@ZbsResearch


🔤🔤

🔜 Как команда перестала полировать макеты и начала отдавать дизайн итерациями

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

👀 Кому будет полезно: продуктовым дизайнерам, исследователям и продактам

✔️ Основные мысли:
• Итеративный дизайн — это подход к разработке продукта, а не только способ проектирования интерфейсов. Он вовлекает дизайнеров, разработчиков, продактов и пользователей в единый процесс, позволяя быстрее проверять гипотезы, учитывать обратную связь и принимать решения на основе результатов каждой итерации.
• Ранний запуск прототипов позволяет снизить стоимость ошибок. Вместо длительной проработки идеального дизайна команда последовательно развивает решение небольшими шагами, тестирует каждую версию и отправляет в разработку только проверенные идеи. Это ускоряет разработку и уменьшает риск создания невостребованного функционала.
• Итеративный подход эффективен не во всех проектах. Он лучше всего подходит для MVP, R&D и задач с высокой неопределённостью, где нужно искать решение и быстро адаптироваться. Для зрелых продуктов с устоявшейся дизайн-системой или небольших доработок его преимущества могут быть менее заметны.

📌 Что внутри статьи:
• Почему команда перешла на итеративный дизайн
• Как устроен итеративный процесс разработки
• Практика применения: спринты, прототипы и совместная работа
• Когда итеративный подход наиболее эффективен

➡️ Ссылка на статью

@ZbsResearch


🔤🔤

🎤 Спросили дизайнеров из бигтеха, как изменилась их работа за год: инструменты и результаты, границы и переоценённый хайп

Екатерина Тимофеева, лид дизайна, подготовила цикл из двух статей на основе интервью со специалистами Сбера, Яндекса, VK, AvitoTech, ВТБ и 2ГИС о практическом использовании искусственного интеллекта в работе. В первой части эксперты делятся тем, как применяют ИИ в ежедневных задачах и какие инструменты используют, а во второй рассказывают, какие задачи по-прежнему выполняют самостоятельно, где проходят границы использования нейросетей и какие ожидания от технологии не оправдались.

👀 Кому будет полезно: продуктовым дизайнерам

✔️ Основные мысли двух частей:
• ИИ уже стал рабочим инструментом, а не экспериментом. Специалисты из бигтеха ежедневно используют нейросети для поиска информации, анализа данных, написания текстов, генерации кода и создания визуального контента, освобождая время для более сложных задач.
• Качество результата зависит не столько от модели, сколько от подхода к работе с ней. Лучшие результаты достигаются при поэтапной проработке задачи, хорошем контексте и использовании разных инструментов под разные сценарии, а не одной универсальной нейросети.
• Универсального ИИ не существует. Для текстов и анализа подходят одни модели (ChatGPT, Perplexity, DeepSeek, Grok), для изображений, видео и 3D — другие (Nano Banana, Krea, Kling, Veo, Freepik, Tripo3D). Эффективная работа строится на комбинации специализированных инструментов.

➡️ Ссылка на 1-ую часть

➡️ Ссылка на 2-ую часть

@ZbsResearch


🔤🔤

📍 Красный подождёт. Как 2ГИС запускали «зелёную волну» в навигаторе 2ГИС

Даня, продуктовый дизайнер команды Транспорт, рассказал, как в навигаторе 2ГИС появилась функция «зелёной волны», которая помогает водителям проезжать последовательность светофоров без остановок. Он поделился процессом создания решения: от проверки популярной городской идеи и поиска пользовательской ценности до проектирования интерфейса, работы с данными о светофорах и запуска функции в реальном продукте.

👀 Кому будет полезно: продуктовым дизайнерам и исследователям

✔️ Основные мысли:
• «Зелёная волна» появилась не как отдельная функция, а как логичное развитие таймеров светофоров в навигаторе. Команда увидела, что пользователям уже доступна информация о фазах светофоров, и превратила её в рекомендацию к действию. Это хороший пример того, как новые возможности возникают не из генерации идей с нуля, а из развития существующих пользовательских сценариев и данных.
• Самым сложным оказался вопрос не расчёта оптимальной скорости, а её безопасной передачи водителю. Любое решение должно было считываться за доли секунды и не отвлекать от дороги. В итоге команда отказалась от более сложных визуализаций в пользу простого диапазона скорости рядом со спидометром, дополнив его аналоговой шкалой для быстрого восприятия. Это показывает важный принцип продуктового дизайна: даже точная технология бесполезна, если её невозможно быстро понять в реальном контексте использования.
• Проект не ограничился отображением диапазона скорости. Анимации, зелёная зона на спидометре, контуры и подсветка экрана создают ощущение попадания в поток и усиливают удовольствие от использования функции. Статья хорошо показывает, что успешный продукт решает не только практическую задачу, но и создаёт эмоциональное подкрепление, благодаря которому пользователь чувствует, что система помогает ему двигаться по городу более плавно и уверенно.

📌 Что внутри статьи:
• Главный дизайнерский вызов
• Поиск визуального образа
• Техническая реализация
• Что дальше

➡️ Ссылка на статью

@ZbsResearch


🔤🔤🔤

💡 Какие типы продуктовых задач решает продуктовый исследователь

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

1️⃣ Понимание пользователей

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

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

2️⃣ Поиск и проверка гипотез

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

3️⃣ Оценка решений до разработки

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

4️⃣ Поиск причин продуктовых проблем

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

5️⃣ Оценка изменений после релиза

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

6️⃣ Объединение данных из разных источников

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

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


🔤🔤

⭐️ Почему пользователи врут на интервью и что увидели исследователи, когда начали за ними наблюдать

Кирилл Улитин и Стася Кабанова из МойОфис рассказали, почему традиционные глубинные интервью не всегда помогают понять реальное поведение пользователей. Авторы показывают, как люди непроизвольно искажают описание своих действий, упрощают сценарии и забывают важные детали, а также делятся опытом перехода от изучения пользовательских рассказов к наблюдению за фактической работой с продуктом. Такой подход позволил обнаружить скрытые паттерны поведения и инсайты, которые невозможно получить только через интервью и самоотчёты пользователей.

👀 Кому будет полезно: продуктовым исследователям

✔️ Основные мысли:
• Пользователи не являются надёжным источником информации о собственном поведении. Проблема не в том, что они намеренно обманывают исследователя, а в особенностях человеческой памяти и восприятия. Люди забывают рутинные действия, не замечают автоматических привычек и задним числом выстраивают более логичную версию происходящего. Поэтому интервью часто дают правдоподобный рассказ о работе, а не саму работу.
• Контекстное интервью позволяет увидеть слой данных, который недоступен большинству классических исследовательских методов. Когда человек показывает реальные задачи в привычной среде, исследователь начинает замечать неожиданные обходные сценарии, самодельные инструменты и рабочие практики, о которых пользователь никогда бы не рассказал самостоятельно. Именно такие наблюдения часто становятся источником самых сильных продуктовых инсайтов и помогают понять не только проблемы интерфейса, но и устройство всей рабочей среды пользователя.
• Статья хорошо показывает, что наблюдение за поведением зачастую важнее сбора мнений. Необычные кейсы вроде использования инструментов разработчика для скачивания изображений или превращения набора окон в персональный рабочий дашборд выглядят как исключения, но именно они раскрывают реальные потребности и ограничения пользователей. Такие находки редко появляются в ответах на вопросы, зато становятся заметны при наблюдении за тем, как люди решают свои задачи в естественном контексте. Именно поэтому контекстное интервью особенно полезно в сложных B2B-продуктах и сценариях регулярной работы.

📌 Что внутри статьи:
• Почему пользователи не могут рассказать о своём опыте
• Что такое контекстное интервью и зачем оно нужно
• Как проводить контекстные интервью на практике
• Когда метод работает, а когда нет

➡️ Ссылка на статью

@ZbsResearch


🔤🔤🔤

💬 Синтетические респонденты против синтетических данных: чем они реально отличаются и кому верить

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

👀 Кому будет полезно: продуктовым исследователям

✔️ Основные мысли:
• Главный вывод статьи — синтетические данные и синтетические респонденты нельзя смешивать в одну категорию. Простые «опросы в ChatGPT» — это генерация убедительно звучащего текста без устойчивой модели поведения и связанного контекста. Синтетические респонденты пытаются воспроизводить более сложную структуру: постоянные профили, ограничения, историю ответов и взаимосвязи внутри панели. Именно путаница между этими подходами создаёт недоверие к технологии и мешает её адекватной оценке.
• Авторы неожиданно сходятся в том, что синтетика уже может быть полезным инструментом, но только в строго ограниченных сценариях. Она подходит для быстрых проверок гипотез, тестирования анкет, учебных задач и массовых тем с большим историческим массивом данных. При этом обе стороны признают, что в чувствительных, дорогих или плохо изученных сегментах риск «галлюцинаций» модели слишком высок. Чем меньше у системы реальной эмпирики, тем сильнее ИИ начинает достраивать реальность вместо её моделирования.
• Самый важный методологический вывод — синтетические респонденты не отменяют исследователя и не снимают с него ответственность. Даже самые убедительные AI-ответы остаются инструментом, который зависит от качества обучающих данных, дизайна исследования и интерпретации результатов. Статья хорошо показывает, что главная опасность здесь не в самом ИИ, а в иллюзии достоверности: синтетические ответы выглядят правдоподобно настолько, что исследователь может перестать замечать границу между моделированием поведения и реальными данными о людях.

📌 Что внутри статьи:
• Синтетические данные vs синтетические респонденты по‑взрослому
• Что такое синтетические респонденты
• На чём сошлись: когда синтетика уместна
• Болевые точки, которые вскрыла встреча
• Что это всё значит для практикующих исследователей

➡️ Ссылка на статью

@ZbsResearch


🔤🔤🔤

👍 All you need is VoC. Как работать с «хотелками» и нуждами клиентов

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

👀 Кому будет полезно: продуктовым исследователям и продактам

✔️ Основные мысли:
• Пользователи почти никогда не формулируют проблему напрямую. Они предлагают своё решение проблемы, исходя из собственного опыта и ограниченного понимания продукта. Если команда начинает реализовывать каждую «хотелку» буквально, продукт быстро превращается в набор несвязанных компромиссов. Ценность появляется только тогда, когда команда умеет докапываться до настоящей потребности, стоящей за запросом.
• Обратная связь сама по себе бесполезна без интерпретации и исследования. Статья хорошо показывает, что фидбэк — это не список задач для бэклога, а источник сигналов о барьерах, неудобствах и незакрытых сценариях пользователя. Именно поэтому методы вроде VoC помогают не просто собирать комментарии, а системно анализировать ожидания, контекст и повторяющиеся проблемы, чтобы принимать более осмысленные продуктовые решения.
• Один из самых практичных выводов — смотреть нужно не на конкретные формулировки пользователей, а на повторяющиеся паттерны поведения и неудовлетворённости. Пользователь может просить «сделать кнопку красной», но настоящая проблема может быть в том, что сценарий незаметен, сложен или вызывает недоверие. Такой подход помогает командам перестать спорить о частных решениях и начать работать с причинами проблем, а не с их поверхностными проявлениями.

📌 Что внутри статьи:
• «Хотелки» и реальные нужды — в чём разница
• Как проверить, действительно ли есть нужда
• Курс от «хотелок» к нуждам
• Заключение


➡️ Ссылка на статью

@ZbsResearch


⭐️ Personas и JTBD: разные этажи одного здания

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

👀 Кому будет полезно: продуктовым исследователям и продактам

✔️ Основные мысли:
• Главная мысль статьи — JTBD и Personas работают на разных уровнях понимания пользователя, поэтому противопоставлять их бессмысленно. JTBD помогает понять, какую задачу и ради какого прогресса человек пытается решить, а Personas добавляют реальный контекст: ограничения, страхи, мотивацию, влияние среды и особенности поведения. Без этой связки команда либо уходит в абстрактные потребности, либо проектирует функции без понимания, зачем они нужны.
• Проблема большинства продуктовых команд заключается не в выборе «правильной» методологии, а в смешении разных уровней логики. Потребность, роль пользователя, механика интерфейса и бизнес-результат часто сваливаются в одну кучу. Из-за этого User Stories начинают описывать только действия в интерфейсе, а не причины, по которым пользователь вообще приходит в продукт.
• Самый практичный вывод — продуктовую работу полезно строить как цепочку связей. Сначала выявлять напряжение и потребность пользователя, затем формулировать Job Story, после этого определять акторов и ограничения через Personas, и только потом переходить к User Stories и проектированию механик. Такой подход позволяет проверять, зачем существует каждая функция, как она влияет на результат пользователя и какие метрики действительно подтверждают её ценность.

📌 Что внутри статьи:
• Кажется, что JTBD отменяет Personas
• На каком уровне работает JTBD
• Причём здесь иерархия Пауэрса
• Почему персоны всё-таки нужны
• Где конфликт на самом деле
• Как они помогают друг другу
• Практическая рамка

➡️ Ссылка на статью

@ZbsResearch


🔤🔤

👍 Как СберЗдоровье обновили экран «Вы записаны» и выросли по ключевым метрикам

Глеб Бобыльков, ведущий дизайнер в СберЗдоровье, рассказал, как команда переосмыслила финальный экран после записи к врачу и превратила его из простого подтверждения в гибкий сценарий «что дальше». В статье он показывает, как с помощью UX-подхода, системы кросс-офферов и универсального компонента для дизайн-команды удалось добавить бизнес-ценность, не нарушив доверие пользователя на одном из самых чувствительных этапов пользовательского пути.

👀 Кому будет полезно: продуктовым исследователям и дизайнерам

✔️ Основные мысли:
• Финальный экран после целевого действия — это не «конец сценария», а важная точка продолжения взаимодействия с продуктом. Команда СберЗдоровья превратила обычное подтверждение записи в инструмент удержания и маршрутизации пользователей: добавила полезные действия, кросс-офферы и понятные сценарии «что дальше». При этом ключевым фактором успеха стало сохранение ощущения заботы и спокойствия, особенно в чувствительном медицинском контексте.
• Баланс между бизнес-целями и пользовательским опытом достигается не количеством офферов, а качеством их интеграции. Исследования показали, что пользователи нормально воспринимают дополнительные предложения, если они логично встроены в сценарий, не мешают основному действию и объясняют свою пользу. Благодаря этому удалось одновременно увеличить кросс-переходы, установки приложения и сохранить доверие к сервису.
• Отдельное продуктовое решение становится особенно ценным, когда превращается в системный инструмент для всей компании. Вместо единичного редизайна команда создала универсальный модульный компонент для дизайн-системы, который помогает быстро собирать консистентные финальные экраны в разных продуктах. Такой подход масштабирует не только интерфейс, но и саму продуктовую логику работы с пользователем после завершения сценария.

📌 Что внутри статьи:
• Что есть сейчас и зачем понадобился редизайн?
• Итоги запуска
• Компонент в дизайн-системе и масштабирование на другие продукты
• Что получилось в итоге

➡️ Ссылка на статью

@ZbsResearch


🔤🔤🔤

💬 Как Контур проверяет тестовые задания у кандидатов на роль UX-исследователя

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

👀 Кому будет полезно: продуктовым исследователям

✔️ Основные мысли:
• Масштабируемая проверка тестовых заданий требует не одного сильного проверяющего, а прозрачной системы с очередью, шаблонами оценки, куратором и коллегиальным ревью. Именно процесс, а не отдельные люди, позволяет сохранять качество при росте количества кандидатов.
• Качественная обратная связь важна не только для найма, но и для репутации компании и развития кандидатов. Проверяющие фиксируют сильные стороны и зоны роста, благодаря чему даже отказ становится полезным опытом для соискателя.
• Использование нейросетей в тестовых заданиях само по себе не считается проблемой. Ключевым критерием остаётся способность кандидата объяснить логику решений, показать ход рассуждений и адаптировать инструменты под задачу, а не просто сгенерировать готовый текст.

📌 Что внутри статьи:
• Общие договоренности и процесс
• Пополнение команды проверяющих тестовые
• Тестовые и нейросети
• Завершение проверки

➡️ Ссылка на статью

@ZbsResearch


🔤🔤🔤🔤🔤

⭐️ Почему вредно сразу начинать рисовать макеты

Илья Макаренко, продуктовый дизайнер Альфа-Инвестиций рассказал, почему редизайн онбординга сам по себе не решает проблему низкой активации подписки и как продуктовым командам важно сначала разобраться в восприятии ценности продукта пользователем, а уже потом менять интерфейсы, тексты и визуальные решения.

👀 Кому будет полезно: продуктовым дизайнерам

✔️ Основные мысли:
• Главная ошибка продуктовых команд — начинать с редизайна интерфейса, не разобравшись в реальной проблеме пользователя и ограничениях продукта. Красивые экраны не влияют на метрики, если узкое место находится в другом этапе сценария или в самой ценности продукта.
• Теория ограничений помогает смотреть на продукт как на единую систему, где итоговая эффективность определяется самым слабым звеном. Поэтому задача дизайнера — не просто улучшать отдельные экраны, а находить ключевое ограничение в пользовательском пути и работать именно с ним.
• Продуктовый дизайнер отвечает не только за макеты, но и за бизнес-результат всей воронки. Для этого важно говорить с командами на языке метрик, понимать влияние решений на деньги и совместно анализировать сценарии целиком, а не локально внутри своей зоны ответственности.

📌 Что внутри статьи?
• Почему продукт нельзя улучшить только макетами
• Как теория ограничений помогает находить узкие места
• Пошаговый подход к поиску и исправлению ограничений
• Где заканчивается зона ответственности продуктового дизайнера

➡️ Ссылка на статью

@ZbsResearch


🔤🔤

Не рискуй конверсией: как исследовать витрину цифрового продукта до запуска

Таня Лескова, ведущий UX-исследователь в магазине приложений RuStore, рассказала, как команда проверяет эффективность витрин и рекомендательных сценариев ещё до запуска продукта, смещая фокус с прогнозирования конверсии на более ранние сигналы пользовательского интереса — заметил ли пользователь предложение, понял ли его ценность и захотел ли продолжить взаимодействие.

👀 Кому будет полезно: продуктовым исследователям

✔️ Основные мысли:
• Для витрин и рекомендаций важнее исследовать не будущую конверсию, а ранние сигналы интереса пользователя. Команда RuStore показывает, что до запуска продукта полезнее анализировать цепочку «заметил → понял → поверил → захотел разобраться», потому что именно она определяет, сможет ли витрина вообще стать рабочим сценарием выбора.
• Классические продуктовые метрики и методы плохо работают для оценки витрин на раннем этапе. Клики, вопросы о гипотетическом использовании или сравнение с поиском не объясняют реальное поведение пользователя, потому что у аудитории ещё нет привычки взаимодействия с новой механикой и сформированного запроса.
• Исследование витрины помогает выявить неочевидные UX-риски ещё до запуска. Например, пользователи могут воспринимать витрину как рекламный блок, не различать разделы между собой или игнорировать крупные баннеры. Такой подход позволяет обсуждать результаты не абстрактно, а через конкретные продуктовые решения и потенциальное влияние на метрики.

📌 Что внутри статьи?
• Не поиск, а сценарий без готового запроса
• Какие решения пользователь принимает за секунды
• Как мы это проверяем в исследовании
• Как переводить это в разговор с командой
• Соберём главное

➡️ Ссылка на статью

@ZbsResearch


🔤🔤

💡 Внедрить нельзя отсеять: как МТС придумали методику для быстрой оценки инноваций

Команда маркетинговых и UX-исследований МТС рассказала, как столкнулась с ограничениями классических методов приоритизации при оценке инновационных продуктов и разработала собственный подход для проверки гипотез и отбора перспективных инициатив ещё на этапе Discovery.

👀 Кому будет полезно: продуктовым и маркетинговым исследователям

✔️ Основные мысли:
- Классические методы приоритизации плохо работают с инновациями, потому что пользователи не могут оценить то, с чем ещё не сталкивались. Вместо оценки самих фич эффективнее исследовать реальные жизненные ситуации и проблемы, в которых такие решения могут быть полезны.
- Метод Колмакова предлагает практичный способ оценки инноваций через частоту и значимость пользовательских сценариев. Такой подход помогает выявлять действительно востребованные идеи ещё на этапе Discovery и принимать решения не на интуиции, а на данных.
- Ключевая сила метода — простота и масштабируемость. Его можно адаптировать под разные продуктовые задачи, от проверки AI-функций до оценки решений в безопасности, а визуализация результатов через карту приоритетов делает выводы понятными для продуктовых команд и бизнеса.

📌 Что внутри статьи:
- Как мы поняли, что «классика» не справляется с инновациями
- MaxDiff
- Что придумали для оценки инноваций
- Как работает Метод Колмакова
- Итог

➡️ Ссылка на статью

@ZbsResearch


🔤🔤

Не гадайте на кофейной гуще: как понять, что редизайн действительно работает — кейс сайта «Халвы»

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

👀 Кому будет полезно: продуктовым исследователям, продактам и дизайнерам

✔️ Основные мысли:
• Измерение UX нельзя сводить к бизнес-метрикам или визуальной оценке: конверсия показывает результат, но не объясняет причины, поэтому реальную картину дают только комбинация количественных и качественных методов, особенно встроенные опросы с корректным контекстом показа.
• Качество данных в UX-исследованиях напрямую зависит от дизайна опроса. Формулировки вопросов, сегментация аудитории, частота показа и длина анкеты критически влияют на достоверность результатов и могут как прояснить, так и полностью исказить выводы.
• Грамотно настроенные UX-метрики позволяют зафиксировать реальный эффект редизайна — в кейсе рост SUPR-Q и отдельных параметров (доверие, удобство сценариев) показал, что изменения улучшили не только визуальное восприятие, но и пользовательский опыт на уровне задач и поведения.

📌 Что внутри статьи:
• Почему редизайн часто оценивают неправильно: три главных ловушки
• Основные ошибки при запуске UX-опросов (и как их избежать)
• Что показали результаты до редизайна
• Что изменилось после редизайна

➡️ Ссылка на статью

@ZbsResearch


🔤🔤🔤

🥇 Как разработать матрицу компетенций и процесс ревью своей команды

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

👀 Кому будет полезно: продуктовым исследователям

✔️ Основные мысли:
• Матрица компетенций, грейды и ревью начинают приносить реальную пользу только тогда, когда связаны с мотивацией сотрудников и целями бизнеса, в противном случае они превращаются в формальную процедуру без влияния на развитие команды.
• Эффективная система оценки не создаётся сразу, она требует итеративной доработки, опоры на обратную связь и адаптации под контекст команды, поскольку универсальной модели не существует.
• Даже при наличии формализованных инструментов ключевую роль играет человеческий фактор: качество оценок зависит от вовлечённости участников, а сами ревью не заменяют диалог, а лишь задают структуру для осмысленного обсуждения развития.

📌 Что внутри статьи:
• Шаг 1. Понять, что мотивирует человека работать
• Шаг 2. Ответить на вопрос «зачем это бизнесу?»
• Шаг 3. Проанализировать имеющуюся информацию
• Шаг 4. Сделать первую версию
• Шаг 5. Итеративно внедрять правки и прийти к итоговой версии
• Шаг 6. Внедрить процесс ревью
• Шаг 7. Внедрить грейды

➡️ Ссылка на статью

@ZbsResearch


🔤🔤

⭐️ Немодерируемые UX-тесты в B2B — нужны? Опыт команды Контура с Pathway

Катя Халитова, исследователь в Контур.Фокусе, поделилась опытом проведения немодерируемых UX-тестов в B2B и разобрала распространённый миф о том, что этот метод неприменим в сложных профессиональных продуктах, показывая, как его можно использовать для проверки гипотез и дополнения качественных исследований.

👀 Кому будет полезно: продуктовым исследователям

✔️ Основные мысли:
• Немодерируемые UX-тесты в B2B часто недооцениваются из-за ошибочного восприятия метода, хотя при корректном применении они позволяют получать количественные данные и дополнять качественные исследования.
• Эффективность метода напрямую зависит от качества проектирования: чётко сформулированный контекст, декомпозиция сценариев и заранее определённые метрики делают возможной работу даже со сложными профессиональными интерфейсами.
• Ограничения метода, включая отсутствие возможности уточнять поведение пользователей и снижение реалистичности сценариев, требуют осознанного использования немодерируемых тестов как инструмента для проверки гипотез на широкой выборке, а не как замены глубинным исследованиям.

📌 Что внутри статьи:
• В каких случаях немодерируемые UX-тесты применимы в B2B?
• Как проектировать задания для немодерируемых тестов в сложных интерфейсах?
• Ограничения немодерируемых тестов
• Вывод

➡️ Ссылка на статью

@ZbsResearch


🔤🔤🔤

💡 Портреты разных грейдов UX-исследователей

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

👀 Кому будет полезно: продуктовым исследователям

✔️ Основные мысли:
- Ключевым фактором роста в карьере UX-исследователя является наставничество. На каждом уровне специалист не только получает поддержку от более опытных коллег, но и постепенно сам становится наставником для младших сотрудников.
- Переход между грейдами определяется не только техническими навыками, но и способностью влиять на продукт и команду: от простых исследований на уровне джуна до формирования стратегии компании на позиции лида.
- Системное развитие в профессии происходит через постепенное расширение зоны ответственности: от работы с конкретными задачами до влияния на процессы всей компании и даже выхода за её пределы в роли эксперта отрасли.

📌 Что внутри статьи?
- Стажёр
- Junior Researcher
- Middle Researcher
- Senior Researcher
- Lead Researcher

➡️ Ссылка на статью

@ZbsResearch

Показано 20 последних публикаций.