Продукт менеджмент

Содержание

Введение. О чем эта статья
Цели и дисклеймеры
Часть 1. Хороший продукт
Часть 2. Пользовательский опыт (UX). Что это?
Часть 3. Архитектура выбора
Часть 4. Архитектор выбора
Часть 5. Когнитивные искажения и Пользовательский опыт
Ссылка на полную версию UX CORE (105 примеров использования когнитивных искажений в менеджменте команд и продуктов)
Часть 6. Наши дни
Часть 7. Не только искажения
Часть 8. Эпилог
Часть 9. Материал, качественно дополняющий эту статью

Введение. О чем эта статья

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

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

В какой-то момент своей жизни я перепрофилировался из технического специалиста в IT-сфере, коим я проработал около 6 лет (LAN/WAN/DevOps/InfoSec), в Product Manager-а. Моей основной деятельностью на этой должности является анализ ожиданий и принятых решений пользователей с целью создания более комфортного и желанного продукта.

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

Цели и дисклеймеры

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

• показать четкие доказательства важности глубоких знаний в психологии для работы в качестве менеджера по продукту;
• дать определение понятию UX (Пользовательский опыт) с позиции психологии и поделиться наиважнейшим источником знаний для создания качественного UX;
• показать механизм оценки грамотности продакт менеджеров (и не только);
• побудить инвесторов больше инвестировать в продукты, в основе которых лежит когнитивная психология и поведенческая экономика;
• предоставить продакт менеджерам дополнительные аргументы в поддержку их идей, которые, часто являясь верными, увы, блокируются техническими специалистами из-за непонимания полной картины и технического склада ума;
• показать с другого угла скучные исследования, которые пылятся на полках библиотек, акцентируя чрезвычайную важность этих материалов для будущего разработки ПО;
• побудить психологов и экономистов взглянуть в сторону продакт менеджмента как возможной опции смены карьерного направления. Мир IT нуждается в вас гораздо больше, чем в диванных аналитиках и псведо-менеджерах с MBA и PMP.

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

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

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

Часть 1. Хороший продукт

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

Итак, чуть выше я убрал вопросы про рынки, конкурентов и целесообразность продукта, потому что я исхожу из того, что качественный продукт это, прежде всего, продукт без внутренних противоречий. Такой продукт идеально связан как идеологическими его составляющими (история создания, его миссия, все использованные изображения, текстовые и печатные материалы используемые для его разработки и продвижения и прочее), так и техническими (back end, пользовательский интерфейс, элементы взаимодействия и дизайн, бизнес цвета, инструкции для работы службы поддержки клиентов, tone of voice of the company и много другого).

При всем при этом важно понимать, что качественный продукт может выйти на рынок, оказаться никому не нужным, стать историей и тем не менее быть качественным продуктом.
Причин неудачи может быть широкое множество, например:

• неудачный тайминг (изменилась коньюнктура на рынке, люди еще не осознали всю серьезность проблемы, решаемой продуктом и т.п.);
• человеческий фактор (утечки внутри компании, уборщица, опрокинувшая ведро рядом с серверами в день релиза и т.п.);
• слабые управленческие навыки руководства (основатели компании слишком поздно начали обсуждать распределение прибыли, что создало конфликты; чрезмерный нажим на команду разработчиков повлек массовые увольнения и сорвал переговоры об инвестировании и пр.)
• банальное невезение, важность которого повально игнорируется как новичками, так и экспертами в бизнесе (Черные Лебеди Н. Нассима Талеба).

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

Часть 2. Пользовательский Опыт (UX). Что это?

Так как на данный момент понятие UX гораздо чаще относят к UI дизайну, моим оппонентом в обсуждении данного вопроса будет Джо Натоли. Джо ветеран-дизайнер с опытом работы более 30 лет, один из самых популярных в мире IT экспертов по UXD (User Experience Design), автор ряда книг, а также самых популярных видео-курсов по UX на Udemy. Натоли провел более тридцати лет консультируя по вопросам дизайна пользовательского опыта (UXD) компании из списка Fortune 100, 500 и правительственные организации. На своем вебсайте он называет себя User Experience Evangelist, значит, я могу ссылаться на его утверждения, высказанные публично в его книгах и видеоуроках.

В одном из своих уроков, где господин Натоли объясняет понятие User Experience, он ссылается на Питера Мерхольца:

Питер Мерхольц, который является деловым партнером Джесси Джеймса Гарретта (автора термина Пользовательский опыт и книги Элементы пользовательского опыта Библии UX всех времен), говорит, что пользовательский интерфейс (UI) является компонентом пользовательского опыта. Но есть гораздо больше, и это гораздо большее включает в себя вещи, которые имеют отношение к когнитивной науке. Это связано с людьми: что они хотят, что им нужно, что они хотят использовать и почему они реагируют на вещи так, как они реагируют.

Другой UXD эксперт Билл ДэРушэ (Старший продакт менеджер / Workflow Experience Lead at Zendesk). В обсуждении UXD говорит следующее: Для UXD даже не нужен экран. UXD это любое взаимодействие с любым продуктом, любым элементом, любой системой .

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

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

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

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

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

Часть 3. Архитектура Выбора

Понятие архитектура выбора популяризировалось после совместного труда Ричарда Талера и Касса Санстейна над Теорией Подталкивания. Вместе они написали книгу Подталкивание (англ. Nudge Theory), которая позволила множеству разных специалистов, ответственных за создание выбора для пользователей, взглянуть на свою работу под новым углом. Чтобы читатель понимал значимость вышеуказанных персон, приведу здесь их краткое описание:

Касс Санстейн со-автор теории подталкивания. После выхода книги Подталкивание президент Обама предложил Санстейну место в Отделе информации и регуляторной политики. Это дало исследователю широкие возможности внедрять идеи психологии и поведенческой экономики в работу правительственных учреждений. 10 сентября 2009 года Санстейн был назначен на пост главы OIRA, которое является частью Административно-бюджетного управления Администрации президента. OIRA осуществляет надзор за реализацией государственной политики и рассматривает проекты нормативных актов. Пост главы OIRA считается одним из наиболее влиятельных, учитывая его возможность влиять на тексты принимаемых законов. СМИ неофициально называют этот пост regulatory czar. OIRA Санстейн возглавлял до 21 августа 2012 года.

В августе 2013 года Санстейн вошел в состав комиссии по надзору за АНБ (англ. Review Group on Intelligence and Communications Technology). Кроме него в комиссии еще два бывших работника Белого Дома: крупейший специалист по контртерроризму и кибервойнам Ричард Алан Кларк и бывший заместитель директора ЦРУ.

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

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

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

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



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

Часть 4. Архитектор Выбора

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

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

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

В такой компании несложно понять, кто является архитектором выбора. Это тот, кто занимается организацией контекста, в котором человек (пользователь) принимает решения в приложении, либо просто Product Manager.

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

Часть 5. Когнитивные Искажения и Пользовательский Опыт

Итак, мы дошли до основного материала статьи.

Далее я выложу ряд известных науке когнитивных искажений, которые были научно выведенны и задокументированны. Отдельной ссылкой я выложил онлайн инструмент, который я назвал UX CORE. В нем вы сможете найти 105 когнитивных искажений с примерами их использования в менеджменте и в разработке приложений.

Для структурирования материала я использовал Кодекс когнитивных искажений, категоризированный и структурированный Бастером Бэнсоном в 2016м году (по ссылке выше дизайн Джона Манукяна III). Помимо новой формы презентации искажений, к каждому из них я добавил пример использования в разработке программного обеспечения, а в некоторых случаях- в управлении командой. Были учтены самые современные практики по управлению командами и компаниями (PMP, PMI ACP), а также разработке продукта.

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

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

Итак, как верно заметил Бастер Бенсон, суть изложенных когнитивных искажений в том, чтобы помочь нам решить 4 проблемы:

• Работа с большим объемом данных. Когда много информации;
• Расплывчатость, недостаточность данных. Когда не хватает смысла;
• Недостаточно времени. Когда быстро реагируем;
• Разные приоритеты по информации. Когда запоминаем и вспоминаем.

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

#1 Эвристика доступности [P]
Процесс, при котором человек оценивает частоту или вероятность события по легкости, с которой примеры или случаи приходят на ум, т.е. легче вспоминаются.

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

Другой пример: биткоины и разного рода ICO. Тема криптовалют так часто негативно форсировалась в СМИ, что в какой-то момент инвесторы просто решили избегать всего, что с этим связано, не вдаваясь в детали. Простые же пользователи поняли, что их ослепленность повышенной волатилностью этих рынков не привела ни к чему хорошему. Хайп по этой теме сошел на нет, а множество действительно качественных блокчейн-проектов столкнулись с серъезными сложностями в развитии из-за сильно искаженной репутации всего, что ассоциируется с блокчейном, биткоином и крипто в целом.

Последний пример это то, что я выбрал тему проектирования ПО и блокчейн технологий для описания эвристики доступности. Первая тема очевидна для меня в силу моей профессии (product manager), вторая же тема просто с легкостью пришла мне на ум, когда я задал себе вопрос: Какое направление в IT было полно хайпа, а потом быстро сошло на нет?.

#4 Эффект знакомства с объектом [P]
Психологический феномен выражения симпатии к объекту только на основании имеющегося знакомства с ним. Чем чаще человек видит кого-то, тем приятнее и привлекательнее ему кажется этот человек.

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

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

#6 Забывание без подсказок [P]
Является неспособностью вспомнить воспоминание из-за отсутствия стимулов или сигналов, которые присутствовали во время кодирования памяти.

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

Приведу простой пример на онлайн тотализаторе, где множество пользователей делают ставки. Очевидно, что средний пользователь как выигрывает, так и проигрывает. В интересах бизнеса правильно будет поддержать такого пользователя в тот сложный момент, когда он все проиграл. Так как в сознании игрока, который пережил серию поражений одни поражения, система может напомнить ему о целом ряде побед по некоему паттерну, оживив в нем всю ту серию хороших воспоминаний, которые он испытал. Это может быть сделано ненавязчиво, сообщением типа Уважаемый %username%, мы просто хотели напомнить вам о невероятно успешной серии ваших побед, продлившейся три дня подряд на играх %game_names%. Навязчиво? Возможно. Изменим сообщение на Вы попали в топ 20% наших игроков, благодаря вашей серии побед в %game_name%!. Уже не так навязчиво, это уже статистика . Конечно, делать это не этично с точки зрения морали. Поэтому букмекерские конторы и казино, работающие под лицензиями Malta Gaming Authority (MGA), Кюрасао и других, заранее соглашаются, что не будут подталкивать игроков к острым азартным действиям. В любом случае, приведенный пример наглядно иллюстрирует как можно извлечь пользу для бизнеса, зная о такой простой ошибке нашего мозга.

#11 Ошибка базового процента [P]
Это ошибка в мышлении, когда сталкиваясь с общей информацией о частоте некоторого события (базовый процент) и специфической информацией об этом событии, человек имеет склонность игнорировать первое и фокусироваться на втором. Например: люди верят показаниям теста, сигнализирующем о наличии редкой болезни, сразу, не принимая во внимание, что редкая болезнь, вообще говоря, редкая. Либо другой пример: страх террористов и полетов на самолете. Суть в том, что наш мозг склонен преувеличивать частный случай в ущерб статистике.

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

Вы собираетесь запустить процесс дефрагментации диска. С вероятностью 99% операция пройдет успешно.

Вы собираетесь запустить процесс дефрагментации диска. Есть 1% вероятности, что жесткий диск будет уничтожен, а ваши данные безвозвратно потеряны.

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

Когда люди видят 15,800 хвалебных отзывов и 50 крайне негативных отзывов в перемешку с ними, они склонны считать продукт менее ценным, непропорционально тому факту, что негативных отзывов меньше 0.1%.

#13 Эффект юмора [P]
Смешные вещи легче запомнить, чем не юмористические, что может быть объяснено увеличенным временем когнитивной обработки, чтобы понять юмор, или эмоциональным возбуждением, вызванным юмором.

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

Здесь очень важно понять, что речь идет о запоминании юморных вещей, но не о позитивном отношении к ним. Так, если в процессе работы над важным действием (заполнение формы, сохранение данных), пользователь попадает на страницу ошибки (500 (Internal server error), 502 (Bad gateway), 503 (Service unavailable), 504 (Gateway timeout) ), то юмор типа Хо хо! Наши пираты работают над ошибкой и скоро все будет восстановлено! будет не к месту. В этом случае юмор будет замечен, запомнен, и, вероятнее всего, вызовет гнев пользователя так, что это событие запомнится лучше. Если подобное событие произойдет несколько раз за месяц, в соответствии с эвристикой доступности, в следующий раз подумав о качестве нашего продукта пользователь с высокой вероятностью даст негативную оценку. Даже если в 99% случаев приложение справлялось с задачей (ошибка базового процента).

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

#21 Ошибка различения [P]
Это тенденция рассматривать два варианта как более отличительные при оценке их одновременно, чем при оценке их отдельно.

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

#36 Пренебрежение вероятностью [P]
Когнитивное искажение, согласно которому человек склонен к игнорированию малых вероятностей при принятии решений в условиях неопределенности. Небольшие риски обычно либо полностью игнорируются, либо сильно недооцениваются. Континуум между крайностями игнорируется. Как объясняет Рольф Добелли, причина, по которой это происходит, заключается в том, что мы не обладаем интуитивным пониманием риска и поэтому плохо различаем разные угрозы. По сути, чем более серьезна угроза и эмоциональнее тема (напр. Радиоактивность), тем менее обнадеживающим представляется снижение риска.

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

К примеру, зная что наши пользователи игнорируют вероятность полной потери данных, мы можем подтолкнуть их к созданию бэкапов сообщением вида Уважаемый %user_name%, в последний раз вы создавали бэкап ваших данных 571 день назад. Мы настоятельно рекомендуем создать бэкап чтобы избежать риска полной безвозвратной потери ваших данных.. Здесь мы ничего не говорим о вероятности потери. Она могла постоянно быть равной 0.1%, но написав сообщение с призывом к эмоциям (полной безвозвратной потери ваших данных) и конвертируя условные 19 месяцев в 571 день, мы с большей вероятностью добьемся действия пользователя (бэкап системы).

---

Ссылка на полную версию UX CORE (105 примеров использования когнитивных искажений в менеджменте команд и продуктов)

---

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

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

В завершении, я бы хотел рассказать об ошибке GI JOE задокументированной профессором Лори Сантос буквально несколько лет назад. Ошибка касается широко распространенного утверждения, что знать это уже пол дела, что, однако, не имеет научных оснований и является ложным утверждением. На самом деле, одного лишь знания недостаточно, чтобы изменить модель нашего поведения. Настоящие перемены невозможны без наших целенаправленных действий. Вы можете выучить наизусть все когнитивные искажения и механизм их работы, но, если вы не меняете модель своего поведения под полученными знаниями, ценность ваших знаний снижается. Более того, подобное знание не будет крепким, вам придется регулярно возвращаться к таблице и повторять написанное, чтобы не забыть. Если же вы не только поймете, но и предпримите определенные действия для усвоения материала, изменения вашего образа мыслей, вашей жизни, тогда самые лучшие решения по продукту, удивительным образом станут для вас крайне очевидными.

Часть 6. Наши дни

К сожалению, нехватка хороших продакт менеджеров является главным препятствием для создания качественных продуктов на рынке. Ситуация усложняется тем, что большинство компаний еще не до конца понимают разницу между Product Manager-ом и Product Ownerом, иногда, даже, прописывая их в вакансиях через /.

На данный момент, взглянув на рынок и на требования к продакт менеджерам лучших компаний, можно обнаружить описания и опросники, на которые ответит почти каждый, кто прошел PMI-ACP. По сути, отсутствие четкого понимания роли Product Manager-а приводит к тому, что на них вваливаются обязанности Project Managerов, Scrum Master-ов, и других.

Оговорюсь, что речь идет в первую очередь о странах СНГ, хотя на европейском рынке абсолютной ясности по поводу продакт менеджеров; как их найти, как интервьюировать, и чего от них ожидать тоже нет.

Полагаю, с США дела обстоят лучше, т.к. развитие продакт менеджмента идет именно оттуда.

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

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

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

Часть 7. Не только искажения

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

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

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

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

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

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

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

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

Без внимания к деталям, невозможно добиться высокого качества.

Важность деталей и умение с ними работать в наше время гораздо более важны, чем общие идеи.

Часть 8. Эпилог

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

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

Попробую объяснить иначе. Вне зависимости от идеологической составляющей вашей жизни, вашего стиля и публичного образа, вы можете в любой момент записаться на курсы по SCRUM, изучить этот фреймворк, почитать о нескольких других, понять идеи Agile и устроиться работать проект менеджером в какую-то компанию. Вы также можете пройти пару онлайн курсов и подтянуть ваши знания по front-end и back-end программированию, понять принципы работы баз данных, и это займет у вас буквально месяц. Еще за месяц вы можете сами выучить HTML и CSS, поиграть с разметкой, собрать несколько макетов и понять общую идею работы Javascript.

По сути, вы можете месяца за три собрать достаточно знаний для понимания технической составляющей проекта, и этого более чем хватит для начинающего продакт менеджера. Для понимания трендов вы можете скачать самые последние приложения, пройти по списку самых популярных онлайн платформ, зарегистрироваться на producthunt, betalist, techcrunch и всегда быть в курсе происходящего. Новостной информационный пробел легко восполнить регулярно читая Google News и hackernoon.

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

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

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

Завершить статью я хочу провокационной мыслью.

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

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

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

Большое спасибо за проявленный интерес.

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

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

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

Часть 9. Материал, качественно дополняющий эту статью

• Даниел Канеман Думай медленно Решай быстро;
• Николас Нассим Талеб Черный Лебедь;
• Касс Санстейн и Ричард Талер Подталкивание;
• Ричард Дэвидсон Как эмоции управляют мозгом;
• Михай Чиксентмихайи Поток;
• Джим Коллинз От хорошего к великому;
• Jesse James Garrett The Elements of User Experience (2nd Edition);
• William Lidwell Universal Principles of Design;
• James Clear Atomic Habits;
• Erin Meyer The Culture Map;
• Joe Natoli UX Design Fundamentals Udemy Video;
• Joe Natoli UX & Web Design Master Course: Strategy, Design, Development Udemy Video;

Эта статья была написана в период объявленного карантина из-за пандемии коронавируса (COVID-19) в Армении, г. Ереван. Я очень рад, что статья оказалась полезна многим людям, которые успели ознакомиться с разными частями написанного материала в период моей работы над ней.

Оригинал статьи
Английская версия

По любым вопросам и предложениям пишите, буду рад помочь: alexanyanwolf@gmail.com / www.linkedin.com/in/alexanyan / www.facebook.com/AlexanyanWolf

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

Путь нашей компании

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

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

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

Как мы проверяем идеи?

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

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

Немного о самом CustDev

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

Член команды, ответственный за проведение интервью, записывает основную мысль в Гугл-таблицы, а после мы прослушиваем каждый разговор некоторое количество раз, чтобы не пропустить главную мысль при ответе на тот или иной вопрос. Важно! Мы выписываем ответы клиентов слово в слово. Стараемся не менять формулировок. После прописывания всех ответов, мы начинаем изучать слова, смыслы и так далее. Очень важно знать, чего хочет клиент и какие слова он использует. Это мы называем качественным исследованием.

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

Важно отметить, что завершенное CustDev-исследование это клондайк для многих департаментов/отделов внутри компании. Например, мы готовим презентацию результатов CustDev и рассылаем ее среди разных отделов. Если понимаем, что есть моменты, на которое 100% нужно уделить внимание, то непосредственно встречаемся с членами команды и говорим, что нужно протестировать.

Guide по CustDev из нашего опыта

• Не спрашивать о будущем. Почти 100%, что это не сбудется.
• Никогда не продавать продукт/услугу во время интервью. Если человек почувствует, что Вы пытаетесь продать ему что-то, то о ценных ответах можно забыть.
• Задавайте вопросы Почему?. Ответ да или нет не позволит Вам погрузиться в проблематику.
• Переспрашивайте и суммируйте все сказанное. Например, Правильно ли я понял, что....?

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

Привет, меня зовут Ксения, яисследователь вUXlab Авито. Некоторое время назад мызапустили стажёрскую программу сразу внесколько направлений: искали продуктовых дизайнеров идизайнеров коммуникаций, редакторов иисследователей.

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

Кого мыискали

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

Нужно знать, как подобрать метод подзадачу, сформулировать гипотезы исформировать выборку. Понимать, как задавать вопросы, чтобы неполучить искажённые данныеи, конечноже, как врезультате сделать корректные прикладные выводы.

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

Чтобы это случилось быстрее, мыискали вкоманду человека, вкотором сошлисьбы три основных фактора:

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

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

Тестовое задание

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

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

Неверный выбор метода исследования

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

Для решения второго задания состориз кандидаты выбирали:

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

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

Отсутствие гипотез или неверные формулировки гипотез

Сгипотезами был целый набор проблем.

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

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

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

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

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

Вторая гипотеза впримере грешит ещё итем, что сформулирована нечётко. Изнеё непонятно, оподаче какого материала речь.

Несколько гипотез водной. Важно, чтобы гипотеза была сформулирована ввиде одной законченной мысли. Тогда будет легко однозначно ответить, верна она или нет. Кроме того, всоставе сложной гипотезы могут оказаться предположения, которые нужно проверять разными методами.

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

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

Ещё пример гипотезы сподобной проблемой: есть положительная зависимость между уровнем знания (восприятия) функции ирешением опокупке автомобиля.

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

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

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

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

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

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

Бесполезные гипотезы. Взаданиях встречались гипотезы, оторванные отреалий изадач бизнеса. Такие предположения нет смысла проверять, потому что они непомогут развитию продукта. Можно легко придумать много таких гипотез, незная внутреннюю кухню компании. Но, если взять например, такую гипотезу: сториз вАвито теряются нафоне сториз вдругих сервисах, тостановится понятно, что:

• она сформулирована так, что неочевидно, как еёпроверить;
• поскольку Авито несоциальная сеть, товрядли убизнеса будет задача сделать лучшие вмире сториз.

Некорректное формирование выборки

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

Вэтих критериях самих посебе нет проблем, они могут быть дополнительными. Ноглавное для формирования выборки впервом задании опыт респондента виспользовании Авито иего текущая потребность впокупке авто.

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

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

Ошибки всценарии исследования

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

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

Посамим вопросам всценарии были такие ошибки:

• Закрытые вопросы. Например, замечалили выинформационные блоки санализом уровня цены иотметками хорошая цена или отличная цена?. Во-первых, натакой вопрос легко ответить просто да или нет, что малополезно вкачественном интервью. Во-вторых, онсодержит всебе подсказку, из-за которой мынеузнаем, сказалбы сам человек про эти отметки или нет.
• Вопросы или задания втесте сподсказкой. Например, кандидаты просили найти авто сценой ниже рыночной. Такая постановка вопроса уже фокусирует внимание респондента нацене ивсём, что сней связано.
• Сложные формулировки вопросов. Например, вопрос былили какие-либо аспекты системы, которые помогли выполнить задачи?. Для респондента исследование это беседа набытовые темы, вкоторой неместо сложным конструкциям ипрофессиональной терминологии. Если человек непоймёт ваш вопрос, тоонвлучшем случае почувствует неловкость, авхудшем непереспросит, ивынеполучите точный ответ. Намного лучше задавать простые вопросы, такие как ачто вам помогло при поиске?.

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

Чек-лист для самопроверки

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

1. Проверьте, что вашу работу легко посмотреть: желательно, чтобы она открывалась поссылке, ненужно было ничего скачивать или где-то регистрироваться. Помните, что задания смотрят нетолькоHR, ноиспециалисты повашему треку.
2. Подумайте отом, как оформить тестовое задание. Когда нужно проверить десятки работ, идеально, если работа каждого человека находится вотдельном файле, подписана его именем иаккуратно структурирована. Также, лучше неиспользовать для работы исследователя Фигму. Основной результат работы здесь текст. Его логичнее оформить вгугл-документе, Notion или любом другом инструменте для работы стекстом, аФигму оставить дизайнерам.
3. Старайтесь избегать ошибок, опечаток ислишком сложных предложений. Лучше перечитать работу насвежую голову, или показать другу, чтобы убрать лишнее ипереформулировать непонятное.
4. Стоит выполнять задания так, как указано втестовом. Если вырешили сделать по-другому, поясните, почему. Конечно, висследованиях зачастую нет единственного верного ответа, нонам важно понять, как вымыслите.
5. Описывая выполнение задачи, постарайтесь дать всю необходимую информацию для оценки работы: параметры выборки, гипотезы, сценарий, тоесть список вопросов креспондентам, расшифровки интервью итестов, результаты ивыводы.
6. Втоже время помните, что исследование для компании это некурсовая. Лучше опустить лишние подробности повыполнению заданий, например даты, объект ипредмет исследования. Добавляя информацию, спрашивайте себя, точноли она будет полезна или это просто следование стандартам.
7. Продумывая гипотезы, помните, что они должны быть сформулированы чётко, однозначно ипредполагать ответ да или нет. Они должны быть именно предположениями, требующими проверки, анеочевидными утверждениями. Отформулировки гипотезы зависит выбор метода иформирование выборки, поэтому перечитайте еёдважды испросите себя: ясмогу проверить это предположение тем методом, который указан втестовом? или какой метод лучше всего поможет проверить такую гипотезу?, если это задача отзаказчика. Также убедитесь, что результат проверки гипотезы будет полезен продукту ипоможет продвинуться вего улучшении.
8. При формировании выборки держите вголове тех людей, которые смогут лучше всего ответить наваши гипотезы, исходя изсвоего опыта ипотребностей. Кстати, когда яхотела понять, насколько хороша эта статья, япопросила еёпосмотреть людей сразным опытом изнашей команды: самого опытного эксперта, чтобы оценить верность выводов, инашего стажёра, как представителя ЦА.
9. Когда составляете сценарий, начинайте разговор изадания среального опыта респондента.
10. При составлении сценария фокусируйтесь наоткрытых вопросах, чтобы ненаводить человека наответы. Конкретизировать всегда успеете походу теста.
11. Помните, что всценарии неместо сложным конструкциям ипрофессиональному жаргону. Говорите среспондентом наего языке.

Вместо заключения

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

• Упоминание общения спродуктовой командой, которая ставит задачу.
• Анализ конкурентов перед исследованием.
• Кабинетный этап исследования. Например, некоторые изучили аудиторию нашего сервиса пооткрытым источникам ииспользовали это при обосновании выборки.
• Протоколы интервью итестов.
• Видеозаписи тестов.

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