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

proudobstvo

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

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

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

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

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

Нажимал на кнопку «buy now”, но ничего не купил. Как так то?

Нажимал на кнопку «buy now”, но ничего не купил. Как так то?

Это НФТ и это дропы, тут кроме вас ещё желающих 1.4 млн. А актив в среднем 300 тысяч человек в день. Значит дропы ловят +- столько же человек.

А теперь подумайте сами. Тираж 30к комиксов за 7 гемов, как быстро его разнесут 300 тысяч человек, которые знают, что даже с коммонки идёт микроплюс. Моментом.

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

Довольно быстрое и самоочевидное определение 7 факторов, влияющих на опыт использования.

Довольно быстрое и самоочевидное определение 7 факторов, влияющих на опыт использования.

Если убрать все цитаты и сделать выжимку, то можно их коротенько изложить (позволю себе пересортировать их по субъективной важности)😉

1. Эффект. То, что вы делаете должно быть ценно для пользователя, решать его проблемы.

2. Эффективность. Отличие от прошлого пункта в том, что эффект — это «результат», а эффективность — с камими трудозатратами он достигается.

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

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

5. Удобным для поиска. То есть любая информация, должна быть и не только достойной доверия, но и возможным к нахождению. Сюда работа с вниманием и контрастом.

6. Желание. Люди должны хотеть пользоваться тем, что вы предлагаете.

7. Доступность. Всё, что вы делаете должно быть доступно любым пользователям с любых устройств.

Двигать метрики – это не стратегия

За последний год я пообщалась не с одним десятком стартапов на тему роадмапа и стратегии – а точнее, их отсутствия. В лучшем случае, было что-то вроде "+x% DAU" или "+x% conversion to y".

"А почему DAU, а не MAU? – спрашиваешь их. – Почему количество пользователей, а не частота использования? А что если мы нарастим DAU в России, а просядем в Китае, это ок?".

Ответа на эти вопросы, чаще всего, нет. Если у вас их тоже нет, хорошенько подумайте, а есть ли у вас продакт-менеджер, или это проджект/аналитик/разработчик с модным тайтлом. Он/она общается с пользователями, пишет PRD и бесконечно приоритезирует бэклог – и команда вполне логично недоумевает, зачем для этого нужен отдельный человек.

Продакт отвечает за стратегию развития продукта. Что значит "стратегия":

  • понимание текущего состояния продукта;
  • понимание трендов на рынке и текущих/потенциальных проблем;
  • понимание, куда мы хотим прийти через x лет;
  • артикуляция принципов и этических стандартов, которыми мы будем руководствоваться по пути;
  • артикуляция того, что мы делать НЕ будем.

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

  • Но что если мы, например, Avito – количество пользователей растет, но количество покупок не увеличивается;
  • Но что если цикл использования нашего продукта – месяц, а не день;
  • Но что если мы выходим на новый рынок;
  • Но что если мы, например, заспамим всех нотификациями – количество пользователей в краткосрочной перспективе вырастет, удовлетворение от продукта упадет.

Метрики помогают следить за прогрессом; стратегия помогает принимать решения – что, особенно в долгосрочной перспективе, намного важнее.

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

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

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

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

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

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

PHP Intl. Правильная транслитерация кириллицы

PHP Intl. Правильная транслитерация кириллицы

Современные фреймворки предоставляют готовый функционал в составе библиотек или хелперов для работы с библиотекой ICU (http://site.icu-project.org/home) через API Intl.

Такой функционал необходим для поддержки интернационализации разрабатываемого веб-сервиса. На основе указанной локали могут устанавливаться форматы отображения валют, времени и даты, а также подбираться настройки для инициализации транслитераторов (https://www.php.net/class.transliterator).

В разделе «Телеграм-каналы (https://chulakov.ru/notes)» сайта Студии во время автоматического импорта постов из наших каналов производится транслитерация названий заметок для формирования ЧПУ (https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%BC%D0%B0%D0%BD%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_URL).

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

Например, уникальная часть URL заметки (https://chulakov.ru/notes/development/php-8-pocti-novogodnij-podarok) про релиз PHP 8 после транслитерации имела вид php-8-pocti-novogodnij-podarok. Замена некоторых букв произошла некорректно.

Для того чтобы транслитерация кириллицы производилась по традиционным правилам, необходимо произвести конфигурацию объекта-транслитератора (https://www.php.net/manual/ru/transliterator.create.php), передав следующее значение параметра $id:

Russian-Latin/BGN; Any-Latin; Latin-ASCII; NFD; [:Nonspacing Mark:] Remove; NFC;

После такой конфигурации результат преобразования наименования заметки изменится на php-8-pochti-novogodniy-podarok.

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