Раздувание функций убивает продукт
Продукты с множеством функций, как правило, ухудшают пользовательский опыт для большинства людей. Несмотря на это, множество продуктов (особенно корпоративных) в конечном итоге заканчиваются «раздуванием функций».
Хотя чрезмерное количество функций не обязательно ведет к потере основных корпоративных клиентов (в любом случае именно они запрашивают все эти функции), оно отталкивает подавляющее большинство ваших обычных, неопытных пользователей. Это может создать вакуум инноваций, которым могут воспользоваться новые конкуренты (например, Atlassian против Trello, что в конечном итоге привело к покупке).
Пользователи и заинтересованные стороны всегда выступают за новые функции, но редко говорят вам об их удалении. Это не означает, что удаление функций не улучшит продукт.
Боль от потери функции возникает сразу же, но преимущества не станут очевидными до тех пор, пока не появятся новые возможности. В этой статье я объясню, почему раздувание функций — это плохо и как удалять функции, не раздражая пользователей.
Дизайнер знает, что он достиг совершенства не тогда, когда нечего добавить, а когда нечего убирать. — Антуан де Сент-Экзюпери
Больше функций может быть плохо
Избыточные функции часто приводят к плохой информационной архитектуре (IA), из-за чего новым пользователям становится труднее испытать свой первый «aha момент». Это, в конечном итоге, увеличивает время осознания ценности (time to value, TTV) и влияет на удержание пользователей.
IA можно понимать как иерархические отношения и связи между частями вашего продукта. Хорошая информационная архитектура имеет решающее значение, поскольку она делает навигацию по продукту простой и интуитивно понятной. К сожалению, многие продуктовые команды безрассудно добавляют новые функции в свои IA, не принимая во внимание влияние, которое они оказывают на непрерывный опыт.
«Aha момент» — это момент, когда ваши пользователи впервые ощущают истинную ценность продукта; TTV — это то, сколько времени им потребуется, чтобы достичь этой точки. Это очень важно, так как пользователи, которые переживают ««aha момент», имеют гораздо более высокий уровень удержания.
Эти три взаимосвязанные концепции могут повлиять на удержание новых пользователей вашего продукта. Пользователи, у которых момент «aha» наступил раньше, как правило, имеют гораздо более высокий уровень удержания.
Пример TTV кофемашины
В качестве примера рассмотрим кофемашины. TTV — это время между распаковкой машины и первым глотком кофе («aha момент»).
Традиционные кофемашины поставляются с толстыми инструкциями по эксплуатации, множеством датчиков, кнопок, переключателей и рычагов. Большинство новых клиентов будут разочарованы количеством времени и усилий, необходимых для получения простой чашки кофе.
С другой стороны, у Keurig есть всего пара интуитивно понятных шагов: открыть слот для капсулы, вставить ее, закрыть слот и нажать кнопку.
Даже если другие кофеварки производят более качественный кофе, для большинства пользователей это излишне сложно, и им требуется целая вечность, чтобы испытать «aha момент» (если вообще добраться до него).
Хорошие продукты придерживаются аналогичного мышления. Пользователи, которые используют ваш продукт, покупают его для определенной «работы» (согласно JTBD). Большинство из этих пользователей довольны (мы часто ошибочно полагаем, что наши пользователи максималисты) — пока работа выполняется на «достаточно хорошем» уровне, они довольны.
По мере роста вашего продукта часто добавляются функции для выполнения второстепенных и даже третьестепенных целей, которые могут быть у некоторых из ваших пользователей (или для помощи опытным пользователям). Хотя это может восприниматься как «улучшение продукта», обычно это дает противоположный результат. Вместо этого сосредоточьтесь на других, более продуктивных областях продукта, над которыми нужно работать. Мне нравится использовать для этого модель Кано.
Это не значит, что мы должны просто безжалостно убрать все функции, не связанные с ядром JTBD. Но нам необходимо подумать о том, как удаление функций повлияет на некоторых наших пользователей. Введите: «Закон Хайрама» или «Закон неявных зависимостей».
Закон Хайрама
Инженер Google Хайрам Райт однажды сказал:
При достаточном количестве пользователей API не имеет значения, что вы обещаете в контракте: все наблюдаемое поведение вашей системы будет зависеть от кого-то.
Хотя он конкретно упомянул дизайн API, мы можем экстраполировать его мысль на продуктовый дизайн. Перефразируя «закон Хайрама», можно сказать, что «в определенном масштабе все, что предлагает ваш продукт, будет (правильно или неправильно) кем-то использовано».
Пример FeedbackPanda для закона Хайрам
Интересный пример этого случился у FeedbackPanda, инструмента для создания отзывов студентов. Команда попыталась отказаться от лишнего неиспользуемого поля ввода, которое позволяло пользователям вводить определенный идентификатор, связанный с их учениками.
В течение нескольких минут они получили несколько гневных жалоб клиентов. Оказывается, многие учителя использовали поле идентификатора как личную заметку о каждом ученике, например, какой был их любимый цвет, а теперь этого не стало.
Вместо резкой реакции с обратным добавлением функции, вам следует подробно оценить эту функцию, используя следующее дерево решений.
Оценка удаления функций
Я принимаю во внимание три фактора, когда обсуждаем с моей командой, следует ли нам удалять (необязательную или основную) функцию. Функции, которые следует удалить, не соответствуют установленному вашей командой порогу «минимального использования» или не соответствуют более высоким показателям удержания.
Блок-схема факторов, которые следует учитывать при удалении функции: 1) минимальное использование, 2) корреляция с более высокими показателями удержания и 3) функция, используемая по назначению.
В примере FeedbackPanda эта функция соответствует использованию и коррелирует с более высоким удержанием; однако функция не используется по назначению. Поэтому команде следует изменить дизайн функции в соответствии с ее вариантом использования. При перепроектировании функций вы должны быть осторожны с изменением IA, поскольку использование и ценность функции тесно связаны с ее местоположением.
Поле студенческого идентификатора используется не по назначению. Пользователи не вводят ID студенческого билета, а скорее используют эту область для заметок произвольной формы. Поэтому очевидным решением было бы реализовать функцию заметок.
Если ваша команда все же решит изменить функцию, которую вы планировали удалить, обязательно внедрите отслеживание, чтобы измерить ее использование и подумать, влияет ли это негативно на TTV. Кроме того, измененная функция находится на том же экране (в идеале в аналогичном месте). В этом примере экран заметок потеряет свою ценность, если переместить его в другую часть продукта.
Удаление функций против невозвратных затрат
Иногда удаление функции вызывает некоторый отпор со стороны заинтересованных сторон. В большинстве случаев отдел маркетинга или продаж сопротивляется удалению функций, потому что это может помешать им привлекать новых клиентов (больше функций = большая воспринимаемая ценность).
Хотя отдел продаж оценивается по объему продаж, бизнес — нет. Состояние бизнеса часто измеряется с помощью ARPU (средний годовой регулярный доход на пользователя, average annual recurring revenue per user). «Ежегодная» и «повторяющаяся» части подразумевают важность наличия здорового удержания (что связано со всеми концепциями, которые я обсуждал ранее).
С другой стороны, некоторые заинтересованные стороны считают, что ресурсы, потраченные на добавление этой функции, — это невозвратные затраты, но мы не должны позволять заблуждению невозвратных затрат затуманивать наше мышление.
Ошибка невозвратных затрат — это тенденция довести дело до конца, если мы уже вложили в него время, усилия или деньги, независимо от того, перевешивают ли текущие затраты выгоды. Учтите, что большая часть затрат на функцию приходится не на начальную разработку, а на длительный период времени после ее запуска (обслуживание, поддержка клиентов, документация и т.д.)
Отзывчивый и простой продукт с временно недовольным клиентом лучше, чем медленный и сложный гигант, который позволяет каждому клиенту делать все. Не бойтесь отстаивать удаление определенных функций перед внедрением новых.
Если вы разрабатываете для всех, вы не радуете никого. Это приводит к посредственным продуктам. — Алан Купер.