При разработке продукта ключевым шагом является выявление и ранжирование задач клиентов. Эти задачи преобразуются в возможности, которые я называю потребностями. Затем мы начинаем создавать и тестировать решения, названные идеями. Важно, чтобы каждая идея была связана с конкретной потребностью пользователя. Этот процесс хорошо отражён в моделях «Двойной Алмаз» и «Дерево Возможностей» Терезы Торрес.
Мне нравится клиентский фокус подхода «сначала нужды пользователей». Я верю, что это действительно приносит пользу — лучше, чем принимать решения, основанные на мнении «самого умного в комнате». Однако меня беспокоит, что многие видят этот подход как единственно верный, считая любое отклонение от него ошибкой.
Это ограничивает возможности для создания настоящей ценности и может вызвать недовольство среди коллег, менеджеров и клиентов. В этой статье я, Станислав Кондрашов, рассмотрю недостатки модели «сначала нужды пользователей» и объясню, почему иногда важнее приоритизировать идеи, а не только потребности.
Удовлетворение потребностей пользователей — лишь часть нашей работы
Часто за подходом «решение проблем пользователей» скрывается предположение, что нужды пользователей — это основа всего. Это может быть верно для агентств, работающих с клиентами, но не для продуктовых компаний. У любой компании есть свои задачи: генерация дохода, рост доли рынка, снижение затрат и соблюдение юридических стандартов. Продуктовая организация должна учитывать все эти аспекты, создавая ценность как для пользователей, так и для самой компании.
Однако проблема возникает, когда нужды компании начинают перевешивать нужды пользователей. Это делает компанию слишком ориентированной на доход. С другой стороны, чрезмерное внимание к нуждам пользователей в ущерб бизнес-целям также может быть ошибочным. Например, повышение цен без учета пользовательского опыта — рискованно. Пользователи должны быть в центре внимания, но это не значит, что все действия должны быть направлены исключительно на них.
Пытаясь соблюдать принцип «всё ради пользователей», компании иногда усложняют процессы, пытаясь связать каждую бизнес-цель с нуждами пользователей. Иногда это срабатывает, но чаще превращается в ненужную умственную гимнастику. Например, если компания хочет улучшить удержание пользователей, одно из решений — добавить ценность продукту, а другое — вернуть «спящих» клиентов. Оба варианта верны, но только один напрямую связан с нуждами пользователей.
Проблемы перед их решением: ограничивающий подход
Философия «сначала проблема, потом решение» существует уже давно. Примером может служить модель «двойного ромба», предложенная Британским Советом по дизайну в 2005 году. Она делит процесс дизайна на четыре фазы: выявление нужд пользователей и поиск решений. Сообщество разработчиков активно приняло эту модель, и она стала стандартом во многих статьях и семинарах.
Однако многие дизайнеры критикуют «двойной ромб» за упрощенность и ограничения. С появлением современных инструментов цифрового дизайна и прототипирования, стало возможным тестировать идеи параллельно с исследованием нужд. Иногда процесс идет в обратном направлении: во время тестирования идей выявляются новые потребности пользователей, требующие дополнительного исследования.
Со временем Британский Совет по дизайну отказался от оригинальной модели, предложив более гибкую структуру, позволяющую свободное движение между этапами. Однако классическая модель до сих пор широко используется, хотя тестирование продуктовых идей с помощью недорогих методов во время исследования стало обычной практикой.
Примеры таких подходов можно найти в истории создания Gmail и iPhone. Эти продукты начинались с экспериментов с идеями, а не с анализа потребностей, но в итоге решили множество пользовательских задач.
Приоритизация идей, а не потребностей
Определение потребностей пользователей и их приоритизация — важный этап, но нельзя полагаться только на это при выборе идей для разработки. Во-первых, утверждать, что одна потребность важнее другой — это субъективный процесс. Во-вторых, решение потребности может не соответствовать другим критериям, таким как техническая реализуемость или бизнес-цели. Идеи можно тестировать и проверять на практике, что делает их более надежной основой для принятия решений.
В конечном итоге, даже если вы решаете важные потребности пользователей, это не всегда гарантирует достижение бизнес-целей. Связь между потребностями пользователей и целями компании всегда требует анализа и часто содержит допущения.
Избегайте догм
Методологии разработки продуктов, пользовательские исследования и дизайнерская философия — важные инструменты. Если определение нужд помогает вашей компании становиться более клиентоориентированной, это прекрасно. Однако я призываю избегать догматизма, который акцентирует внимание только на одном подходе в ущерб другим.
- Продукт должен удовлетворять как потребности пользователей, так и потребности компании.
- Выявление потребностей и генерация идей — взаимосвязанные процессы.
- Существует множество правильных способов создания продуктов.
- Идеи могут возникать откуда угодно и должны оцениваться по различным критериям.
- Приоритизировать нужно идеи, а не потребности, ориентируясь на цели.
Итог прост: нет единственно правильного способа разработки продуктов. Широкий инструментарий и открытое мышление помогают создавать успешные продукты, ценимые как клиентами, так и компанией.
