Когда я руководил отделом продуктового менеджмента в компании-разработчике социальной сети Friendster, мне пришлось столкнуться с существованием иерархии потребностей на собственном горьком опыте. Friendster была первой популярной социальной сетью. Для сайтов социальных сетей (как и социальных проектов в целом) характерен взрывной рост популярности. Сеть Friendster столкнулась с настолько стремительным ростом числа пользователей, что количество интернет-запросов в определенный момент стало превышать пропускную способность серверов. Многим пользователям наш продукт понравился; однако они были недовольны тем, что сайт стал слишком медленно загружаться либо был и вовсе недоступен из-за технических проблем с производительностью. Чтобы помочь команде правильно расставить приоритеты в своей работе, я – со всем уважением к Маслоу – рискнул создать свой вариант иерархии потребностей наших онлайн-пользователей, представленный на Рисунке 4.2.
Рисунок 4.2. Иерархия потребностей онлайн-пользователей по Олсену
В левой части Рисунка 4.2 показана пятиуровневая иерархия потребностей с точки зрения пользователя. Справа от каждого уровня – что это означает для разработчика. Как предпринимателям, руководителям проектов, разработчикам и дизайнерам нам нравится тратить свое время на разработку новых интересных функций и создание отличного пользовательского опыта. Однако эти элементы находятся на двух верхних уровнях пирамиды потребностей пользователей. Прежде всего, продукт должен быть доступен тогда, когда пользователь захочет им воспользоваться. Затем время отклика должно быть достаточно быстрым, чтобы не раздражать пользователя ожиданием загрузки. Следующий уровень относится к качеству продукта: работает ли он так, как должен? Затем мы переходим на уровень функционала. На первом месте здесь находится качество разработки пользовательского опыта (UX), которое определяет, насколько простым и комфортным для пользователя будет ваш продукт. Как и в случае с иерархией Маслоу, потребности более высокого уровня обретут свое значение лишь после того, как будут удовлетворены потребности более низкого уровня.
Оценка того, как продукт соотносится с подобной иерархией потребностей, не является постоянной и может меняться с течением времени. Давайте предположим, что вам посчастливилось создать максимально работоспособный, быстрый и не содержащий ошибок продукт. Все перечисленные оценки приведены по состоянию на определенный момент времени. Затем вы добавляете новую функцию. Вполне вероятно, что с ее работой будут связаны какие-то ошибки, снижающие общее качество продукта. Новая функция может предъявлять более высокие требования к оборудованию, тем самым снижая производительность приложения. Или же она может стать настолько популярной, что количество пользовательских запросов резко возрастет, перегружая серверы и вызывая замедление работы. При работе над новым функционалом и UX-дизайном важно помнить об этой иерархии и без сомнений возвращаться к нижним уровням для устранения возникающих там проблем.
Соотношение важности и удовлетворенности
После того как вы изучили проблемное пространство и определили различные потребности потенциальных клиентов, необходимо решить, какие из них вы хотите удовлетворить. Иными словами, вам нужен хороший способ расставить приоритеты внутри набора потребностей. Лучше всего делать это, опираясь на степень потребительской ценности. Напрашивается вопрос: как определить степень важности той или иной потребности для клиента? Я столкнулся с этим вопросом, когда руководил проектом по разработке приложения Quicken. Мы ежегодно выпускали новую версию Quicken, и мне нужно было составить перспективный план для подготовки следующей версии продукта. В компании Intuit исследование потребителей всегда было на высоте, поэтому у меня была возможность получать результаты как количественных, так и качественных исследований. На основе этих данных я создал систему оценки, основанную на важности и удовлетворенности. Я обнаружил, что получившаяся система предлагает прекрасный способ проектирования потребительских ценностей, опираясь исключительно на аналитические методы. Мой фреймворк хорошо зарекомендовал себя в расстановке приоритетов потребностей при создании очередной версии Quicken, которая установила рекорды по объему продаж, выручке и прибыли. Воодушевленный этим успехом, я позднее разработал еще несколько подобных систем, также основанных на важности и удовлетворенности (о них я расскажу позже).