Ловушка фичеризма: почему продукт страдает, когда мы зациклены на функциональности

Фичеризм – зацикленность на функциях приложения и склонность все происходящее на проекте измерять номинально фичами, а не их практичностью. С одной стороны это удобно: на основе задуманной функциональности и побрейнштормить можно, и требования удобно составлять, и итерации планировать – тоже. С другой – фичеристский подход часто игнорирует поведение и потребности пользователей. 

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

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

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

• «Какие функции важны для вас?»

• «Каких функций не хватает в вашем текущем решении?»

• «Какие функции нам нужно добавить, чтобы вы решили перейти от вашего существующего поставщика к нам?» 

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

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

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

Конечно, если вы хардкорный геймер с очень специфическими требованиями, то, возможно, вам и нужен телевизор с VRR, ALLM и eARC, HDMI2.1, G-Sync, FreeSync, Game Optimizer и HGiG. Но а если вы обычный человек, который просто хочет себе хороший телевизор? 

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

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

Совет: В следующий раз, когда начнете обсуждать придумку новых фич, а не улучшение пользовательского опыта на командном созвоне, попросите людей достать свои телефоны. Могу поспорить, что у подавляющего большинства людей в комнате будет iPhone, несмотря на то что в телефонах Samsung и Google есть и камеры получше, и экраны поярче, и памяти побольше. Одна из причин популярности яблока (если мы не будем обращать внимания на очевидную привязку к платформе) – несмотря на, возможно, не самый лучший набор функций на рынке, этой техникой очень приятно пользоваться.

Надо думать, каково будет пользователю 

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

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

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

• Понятно ли, какую пользу приносит этот продукт и как я могу получить эту пользу?

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

• Могу ли я легко построить мысленную модель того, где что находится и как работает продукт?

• Знаю ли я, что делать дальше?

• Как это впишется в мой существующий процесс?

• Что мне мешает?

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

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

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

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

Следующий человек приходит и испытывает то же самое. Команда воет: «Ну где вы нашли таких тупых пользователей?» Однако по мере того, как третий, четвертый и пятый человек сталкивается с той же проблемой, умные мысли начинают догонять:

«Может быть, пользователи все-таки не виноваты? Может быть, мы предполагали уровень знаний или мотивации, которого нет; может быть, дело в языке, который мы использовали для описания функции, или в том, как был разработан интерфейс, который вызывает эту путаницу?»

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

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

Решение для всех: внедрять и проверять

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

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

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

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

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

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

Время от времени старайтесь отойти от повседневной разработки и спросите себя: «Если бы я начал создавать свой продукт с нуля, какие 3 функции я бы включил в него сегодня?»