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

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

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

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

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

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

Самое тонкое место в UX

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

А где самое тонкое место в UX?
Чаще всего самое тонкое место в UX — место, в котором пользователь соприкасается с человеком, представляющим продукт.
Для b2c продуктов узкое место в UX, как правило, поддержка.
Для b2b продуктов таких мест много: продажник, внедренец, поддерживатель.

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

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

Я решил уйти от МТС в Теле2 с сохранением номера.
На сайте Теле2 заполнил форму перехода, указал данные паспорта, чтобы, как написано на сайте: обработка запроса прошла быстрее в точке выдачи. Отправил запрос. Мне дали два дня, чтобы прийти в точку продаж, а после заказ протухнет.
Через день я пришёл в офис, а он закрыт, хотя время его работы уже давно наступило. А телефон менеджера офиса выключен или вне доступа. Подождал 15 минут и ушёл. Так меня Теле2 "выгнал" первый раз.

Я не сдался и написал сразу же красочное письмо в поддержку: пришёл, закрыто, как я могу вам доверять и что делать?
Мне не ответили в течение суток, как обещано на сайте Теле2. Я написал напоминание — сутки прошли, жду ответ.
Мне ответили и "не пустили" меня в продукт снова. Сапортница сказала: "Очень жаль. Заполните заявление на другой офис."
Другой офис, к слову сказать, в 10 км от меня. А новое заявление — это снова все поля и паспортные данные.

Что я подумал про такой сервис? Ничего хорошего. Заполнять я больше ничего не стал.

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

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

Думай как Билл Гейтс

Смотрю сейчас на Netflix документальный сериал про Гейтса. Очень увлекательно! В последней серии зацепил диалог следующего содержания:
— Билл, как ты думаешь, Microsoft монополист?
— Если монополия это большая доля рынка и краткосрочная власть над ним, то ответ да. Если вы подразумеваете, что у нас непобедимая позиция и никакой более удобный и эффективный продукт не может её пошатнуть, ответ нет.

И ведь правда. У слова монополия очень сильная негативная составляющая. Но разве это плохо? На свободном рынке, если не рассматривать государственные и прочие нечестные монополии, большая доля рынка говорит о том ,что продукт хорошо решает проблемы пользователя. Да, он может быть кривой и показывать вам периодически "синий экран сметри". Но он, чёрт побери, работает! В сериале есть вставки из хрорники, где народ расхватывает коробки с Windows 95, буквально сметает её с полок :)

Сейчас модно ругать Windows. Но ведь именно эта ОС сделала революцию на рынке персональных компьютеров. Сначала её, конечно, сделал Apple в сфере железа. Именно два Стива сделали компьютер персональным (Джобс и Возняк). Но они были нацелены на определенную ЦА. А вот Майкрософт сделал ПК по-настоящему массовым.

Сейчас Гейтс много времени уделяет проблемам энергетики и климата. Они с женой потратили кучу денег (28 миллиардов долларов) на стартапы и инициативы, которые пытаются сделать жизнь лучше в масштабах планеты. Крутой сериал про крутого бизнесмена и просто очень умного человека. Советую!

Core Protocols 2

На прошлой неделе я начал писать про Core Protocols и мы посмотрели на список Core Commitments. Если вы пропустили пост и не понимаете, о чем вообще речь, можете вернуться вот к этому посту — https://t.me/designgest/377.

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

И первый протокол, о котором хочется поговорить — Check In.

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

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

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

GLAD (радость)
SAD (грусть)
MAD (бешенство)
AFRAID (испуг).

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

Плюс комбинацией этих базовых эмоций можно получать описание более сложных эмоций. Так например, EXCITEMENT = GLAD + AFRAID.

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

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

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

Стакан UX-писателя всегда наполовину полон.

Не «Информация исчезнет через 5 дней», а «Информация будет доступна ещё 5 дней».

Не «Договор расторгнут», а «Нужен новый договор».

Не «Заплатите, иначе услуга будет приостановлена», а «Чтобы продолжать пользоваться, заплатите до 7 марта».

Не «Услуга доступна не чаще 2 раз в год», а «Можно пользоваться 2 раза в год».

В мире и так много негатива и коронавируса, зачем ещё в приложениях нагнетать?

Про адаптацию стажеров и младших специалистов

Наш руководитель веб-направления Таня Аладина интересно написала про адаптацию стажеров и младших специалистов:

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

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