LJTimes как повод для размышления

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

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

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

Я сейчас совсем не собираюсь обсуждать и осуждать сотрудников СУПа — у меня давно имеется подозрение, что Брэд Фитцпатрик заложил куда-то глубоко в исходники Livejournal что-то такое, что заставляет сервис максимально публично позориться при любых попытках «сделать как лучше». Как в том анекдоте про Мерседесы на месте ВАЗа — «место проклятое». Поэтому , за очевидной бессмысленностью, никакого обсуждения кровавости и прочего я устраивать не буду. Просто использую этот случай в качестве отправной точки.

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

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

А пользователи редко хотят изменений. Вы же помните — если бы Генри Форд спрашивал у людей, что им надо, вместо автомобилей мы бы сейчас ездили на суперлошадях. Поэтому любое изменение в привычном интерфейсе — это повод для недовольства. Выражаемого публично, а как же. А создателям изменения обидно — они ж ночи не спали, о пользователях думали. Возникает конфликт — авторы сервиса ввязываются в дискуссию, считают себя непонятыми Стивами Джобсами, пользователи, которым сломали привычное поведение и заставили куда-то сходить в настройки и что-то перенастроить, выражают сомнения в наличии мозгов у создателей и пошло-поехало.

А между тем избежать по крайней мере радикализации конфликта несложно. Надо лишь выполнить несколько несложных правил.

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

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

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

В-третьих, тестируйте. Сплит-тесты придуманы давно. Зачем раздражать 100% своих пользователей, если можно быстро проверить, как изменение будет воспринято 10%? В случае с ЖЖ можно было бы обойтись даже меньшей долей аудитории.

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

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

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

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

И, наконец, если вы выкатили изменение, работайте с аудиторией. Объясните, зачем ей это изменение надо, как от него волосы становятся густыми, сколько миллионов минут сэкономит аудитория сервиса, если вдруг он просуществует еще лет 20 и так далее. Реагируйте на отрицательную реакцию, это часть работы по PR, сдержанно и вежливо объясняйте все мелочи, которые вам кажутся уместными. И на всякий случай, если аудитория агрессивно реагирует, будьте готовы наступить на горло песне авторов проекта и придумать компромиссный вариант.

Как легко увидеть, абсолютно по каждому пункту СУП поступил наоборот. Я ж говорю — место проклятое 🙂 …