Всем привет! Я Антон Телицын, продакт-менеджер в AI-центре Тинькофф, до этого работал в Miro над движком доски. В обеих компаниях сталкивался с вопросами управления скоростью реакции продуктов в разных ситуациях.

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

Добро пожаловать под кат!

Биология и психология рулят

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

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

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

В книге Usability Engineering Якоба Нельсона приводится несколько важных констант:

• До 100 мс — немедленная реакция. В такой лимит должны укладываться все действия, где не ожидается раздумий и вычислений со стороны системы. Согласно исследованиям, в большинстве случаев человеческий глаз реагирует на изменения, длящиеся чуть больше 100 мс.

• До 1 с — быстрая реакция. В лимит должны укладываться действия, где для человека естественно ожидать какой-то небольшой паузы для простых раздумий на обработку информации. Если время ожидания составляет от 0,1 до 1 с, то человек замечает задержку, но поток его мыслей остается непрерванным.

• До 8—10 с — объем или предел внимания человека. Если действие в лимит не укладывается, пользователь переключит свое внимание и мысли на что-то другое. Важно давать пользователю какой-то фидбэк в процессе выполнения операции, если она занимает больше секунды, но даже с фидбэком удержать внимание дольше 10 секунд будет очень проблематично.

• 42 мс — время генерации одного фрейма для анимации (это дает «стандартные» 24 кадра в секунду).

Рассмотрим несколько примеров.

Доска Miro со стикерами похожа на физическую белую доску, а у стикеров даже есть объемная тень. Ожидания в плане отзывчивости будут такие:

• перемещение объекта должно быть таким же плавным, как перемещение физического объекта — стикера;

• напечатанный текст должен появляться мгновенно.

Мгновенно для единичного действия — это то, что меньше 100 мс. Но некоторые действия не единичные, например перемещение стикера или анимации. К ним другие требования. Плавно — когда обновление изображения происходит с частотой больше 24 кадров в секунду. Тогда обновление всего экрана должно укладываться в 1/24 с или в 42 мс.

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

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

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

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

Мы остановились на секунде в качестве цели для идеальной скорости реакции Секретаря Олега. На это есть несколько причин: 

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

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

• Нашли исследования о том, что чем меньше скорость реакции, тем более честным воспринимается ответ собеседника и лучше чувствуется связь с собеседником. А это именно то, что нам нужно.

Копирование файла на флешку или в облако — это как переместить тяжелый объект на новое место. Мы ожидаем, что перемещение займет время. Точнее определить сложно, потому что каждый субъективно соотносит время и тяжесть — сравнивает размер файла со своим опытом. Если скопируется за долю секунды, даже может возникнуть подозрение, а точно ли скопировалось? :) Этот пример классно обыграли в сериале «Кремниевая долина».

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

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

Лучшие друзья продакт-менеджера — перцентили

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

На скорость и отзывчивость продукта влияют разные факторы:

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

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

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

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

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

Например, 90% всех измеренных событий может уложиться в 100 мс, но оставшиеся 10% могут растянуться до 2 с — это и есть длинный хвост.

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

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

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

Лучшие друзья продакт-менеджера, управляющего скоростью продукта, — перцентили.

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

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

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

Текущие метрики и цели могут выглядеть, например, так:

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

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

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

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