Про изучение пользователей

230 млн лет назад (230! млн. лет назад) по Земле ходили Герреразавры — картинка внизу поста.
Это были относительно легкие двуногие хищные динозавры. У них был длинный хвост и довольно маленькая голова. Длина тела примерно 6 метров, а весили порядка 650 кг.

Строение их тела говорит о том, что они довольно быстро бегали. Стопа герреразавров имела пять пальцев, однако полностью развиты были только три средних (II, III и IV). Два остальных (I и V) не несли на себе нагрузку от тела — они были сбоку и имели только коготь. Хвост был укреплен отростками позвонков и играл роль балансира при ходьбе и беге. На первых трёх пальцах передних лап были крупные загнутые когти ими герреразавры хватали и удерживали добычу. Догнал, схватил и съел.

О зверюге, которая жила на Земле 230 миллионов лет назад (аж в голове не укладывается цифра), известно больше, чем многим известно о пользователях, для которых создаётся продукт. Если вы не знаете досконально проблемы или мотивации пользователя, то создать классный продукт меньше шансов. Зачастую команда фокусируется на дизайне и функциях, которые в дальнейшем оказываются абсолютно бесполезными.
Если делать продукты для физлиц, то там вероятность "попасть" в потребность выше, так как команда ближе к проблемам физлиц — сами же люди.
Если делать продукты для бизнеса или государства — то лучшие продукты получаются, как правило, у тех, кто либо сам в этом же бизнесе поработал, либо много времени провёл внутри бизнеса, изучая процессы.

В 2015 году, работая в заказной разработке, я был в составе большой группы, которая делала продукт регионального уровня: муниципальные услуги, сервисы для жителей, мониторинг инвестиционных проектов.
И вот мы пошли на приём к мэру одного из региональных городов — приветливый и умный дядька.
Начали обсуждать сервисы для жителей. Один из сервисов был про активных горожан — отметил место на карте, приложил фотку и отписал, что не так. Все видят, голосуют за самые острые дела, а власть расторопно всё исправляет. У жителей, вероятно спрос был бы, если бы власть реагировала на запросы. Но на деле схема оказалась неработоспособной для небогатых городов (а это почти все). Приветливый и умный дядька нам сказал: "Мы уже знаем о таком количестве проблем, на которые не хватает городского бюджета. Зачем же мы будем давать людям ложную надежду и собирать их ещё больше — мы можем реагировать только на самые острые проблемы". Сервис не зашёл.

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

А тем временем, уже прошло 3 занятия

На второй лекции нам рассказали про дорожную карту, по которой будет проходить наша работа над проектом. Построена она по принципам дизайн мышления (ДМ).

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

По сути ДМ — это решение проблемы, запрос на которую указал пользовать. Есть мнение, что проводить ДМ нужно в первую очередь для бизнеса (заказчика), чтобы обосновать ему, почему нужно делать удобно, решая проблемы пользователей, а не только бизнеса.

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

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

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

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

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

Сколько нужно протестировать пользователей, чтобы обеспечить достаточную для большинства случаев точность исследования?

Сколько нужно протестировать пользователей, чтобы обеспечить достаточную для большинства случаев точность исследования?

Немного матана! Совсем недавно, на интервью я столкнулся с интересным вопросом: «Сколько нужно протестировать пользователей, чтобы обеспечить достаточную для большинства случаев точность исследования?»

И казалось бы, ответ довольно очевидный: мол Нильсен говорит 5. Но почему 5? Откуда это магическое число? Без математики не обошлось.

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

Если прорезюмировать, то можно сказать, что Нильсен не был не прав 🙂 Однако стоит приводить полный ответ:

—————————————————————————

Если во время тестирования эксперименты будут независимыми, а выборка по крайней мере квазислучайной, то мы можем предположить, что при тестировании 5 пользователей мы обнаружим 85% ошибок, с которыми сталкиваются не менее 31% пользователей.

—————————————————————————

Последняя часть, вообще интересная, не правда-ли? ) «Не менее 31% пользователей», то есть в самом неудачном случае 59% пользующихся так и не столкнуться с проблемами. Но это не слишком страшно.

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

http://bit.ly/2UqfhOs

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

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

Вылезаю, озираюсь по сторонам и понимаю, что забыла про то, что у меня есть я, а значит что-то кроме работы и профразвития.

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

А ещё знаете, вот это, когда у тебя в жизни (да какой там жизни, я про работу конечно) все изменилось до неузнаваемости, а ты ещё полгода рассказать ничего не можешь.
Ибо ну как же рассказать — а вдруг ничего в результате не получится? Или то что ты рассказываешь «как делаю», окажется ошибкой?
Надо историю сложить, осознать и отрефлексировать опыт, а потом рассказывать.


6 лет назад я начала свою карьеру как UX-исследователь. Саня называл это вагиней глубокой UX-аналитики.

С тех пор всё изменилось несколько раз. И всё имеет цикличность.
Только сейчас, спустя 6 лет, пришло осознание, почему роль одинокого(!) начинающего UX-исследователя в большой айтишной компании так сложна и часто обречена на провал.
Об этом подробно расскажу в следующий раз 😉

Инсайты

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

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

Вторая часть занятия была посвящена лекции аналитика из redmadrobot — Сергея Ковтунова. Он рассказал про то, как устроен процесс сбора требований и формирование фич в роботах.

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

В итоге наш фичерлист принял такой вид:

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

Проблема:
Новичкам сложно адаптироваться, в сервисе огромная конкуренция.
Решение:
-Бесплатный безлимит на сутки для новых пользователей;
-Тарифные планы для специалистов, в том числе и безлимитные;
-Функциональный личный кабинет специалиста — показывать ачивки навыков и полученных достижений (пройденные тесты, курсы и т.д.);

Проблема:
Обман от мастеров, обман клиентов.
Решение:
-Оплата при помощи безопасной сделки (через сервис);
-При отклике мастер имеет возможность задать время действия своего предложения.

Экскурсия в офис авито

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

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

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

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

____________

Сейчас авито на взлёте, но взлет этот такой же, как и у нокиа в своё время, и их персональный «айфон» уже на подходе — в виде sharing economy. То есть модели, построенной не на владении, чем либо, а на временном пользовании. Уже сейчас модель совместного потребления можно увидеть на примере Airbnb, городского каршеринга и велопроката. И когда подобные сервисы закроют большинство потребностей — авито станет не нужен.