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

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

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

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

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

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

История одного дня пользователя

Еще один метод, способный проиллюстрировать флоу взаимодействия пользователя с будущим продуктом с учетом контекста. Этот метод помогает понять мотивы и примерный бэкграунд в котором находится пользователь — что было до того как у него возникла потребность в продукте? Что он делал после, почему поступил так, а не иначе?

Итак, история про Алексея:
«Алексей офисный работник, который проводит на работе с 9 до 19. У него нет свободного времени. Алексей женат, но жена, также, все время проводит на работе. Они живут в старой квартире, которая досталась от бабушки. Жена, периодически пилит Алексея, что он никак не может сделать хотя бы косметический ремонт. В конце концов, Алексей накопил денег и решил для начала поменять старый паркет. Он задумался над тем, что ему нужен хороший специалист, который выполнит конкретную работу. Но он не знал как отобрать нужного кандидата, чтобы и по цене не обманули и по качеству не кинули. На работе Алексей поделился проблемой со своим коллегой Леонидом, и тот посоветовал сервис профи.ру.

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

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

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

-сделана ли работа полностью?
-производились ли дополнительные работы?
Приложение просит оценить специалиста и его работу, он ставит 5 звезд.
После чего Алексей видит, что заказ закрыт и деньги за работу списаны.
В этот вечер у Алексея был секс».

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

Олег Большаков написал о проектировании системы уведомлений.

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

2. Создайте каркас: первый столбец таблицы — для событий, остальные столбцы — для уведомлений для каждой пары «задействованная роль и канал связи» (пуш-уведомления, письма, персональная лента). Например: «Персональная лента: Исполнитель».

3. Выпишите события, которые могут произойти в рамках процесса. События группируйте по ролям, которые их создают.

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

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

— Старайтесь переиспользовать формулировки;
— Выделяйте переменные среди основного текста;
— Не забывайте о правилах хороших уведомлений: краткость, максимум полезной информации, тон соответствует бренду.

6. Доработайте события. Добавьте формулировки:

— Для массовых событий. Например: «ПОЛЬЗОВАТЕЛЬ: Добавил в утверждение N файлов»;
— Для последовательностей действий. Например: если пользователь удалил одного утверждающего и добавил другого, пишите «Заменил утверждающего с УТВЕРЖДАЮЩИЙ на УТВЕРЖДАЮЩИЙ».

Гигиена здорового коллектива

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

Необходимы процедуры, которые будут поддерживать здоровье коллектива:

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

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

После получения брифа и первичного общения с заказчиком мы отправились пробовать сервис на зуб.

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

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

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

И у нас не получилось.

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

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

Но и это еще не все!

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

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

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

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

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

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

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

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

Наблюдения

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

Обучение наблюдателей отличается тем, что помимо вводной о проекте к обучению подключается картограф, который подробно объясняет методику наблюдения и принципы работы с картой. Так же, полевиков обучают работе в специальной программе — QGIS.
QGIS — это масштабная открытая геоинформационная система (ГИС), данные которой может использовать любой желающий.

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

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

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

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