Фокусировка и определение проблемы (Define) — вторая стадия Design Thinking (Stanford d.school). Синтезирует разрозненные наблюдения стадии Empathize в единую формулировку точки зрения (Point of View, POV) — «[Пользователь] нуждается в [потребности], потому что [неожиданный инсайт]» — и переводит её в вопросы «How Might We?» («Как нам…?»), открывающие пространство для генерации идей на следующей стадии.
Происхождение и исследовательская база
Стадия Define и формула POV разработаны в Stanford d.school как способ избежать двух типичных провалов дизайн-процесса: перескакивания от наблюдений сразу к решениям без ясной формулировки проблемы, и формулировки проблемы слишком широко, что не даёт направления для генерации идей. Техника «How Might We?» происходит из практики компании Procter & Gamble 1970-х годов, позже популяризирована IDEO.
«Хорошо сформулированная проблема — половина решения» — принцип стадии Define в Design Thinking.
Ключевые идеи и принципы
Принцип: POV-формула из трёх частей.
Пользователь (конкретный, а не «пользователи вообще») + потребность (выражена глаголом действия, а не готовым решением) + инсайт (неожиданная причина, обнаруженная в наблюдениях, а не очевидный факт) — все три части обязательны для сфокусированной, но небанальной формулировки.
Принцип: потребность формулируется как глагол, а не как решение.
«Нуждается в способе быстро найти нужный файл» — потребность (открывает пространство решений), а не «нуждается в кнопке поиска» — уже готовое решение, ограничивающее последующую генерацию идей.
Принцип: How Might We переводит проблему в генеративный вопрос.
«Как нам…?» — формулировка достаточно узкая, чтобы дать направление, но достаточно широкая, чтобы не подсказывать единственный ответ. Слишком узкий HMW («Как нам добавить кнопку X?») сужает творческое пространство, слишком широкий («Как нам улучшить продукт?») не даёт фокуса.
Ограничения, слепые зоны и критика
Качество формулировки POV полностью зависит от качества наблюдений предыдущей стадии — слабые исходные данные дают поверхностный или ошибочный POV. Формулировка одного «правильного» POV может преждевременно сузить проблемное поле — иногда полезнее держать несколько альтернативных POV параллельно. Метод требует навыка формулирования инсайтов, который приходит с практикой — новички часто путают инсайт с простым фактом наблюдения.
Типовые ошибки
Ошибка 1: формулируют потребность как готовое решение.
POV сразу содержит конкретное решение («нуждается в мобильном приложении»), что закрывает пространство для генерации альтернативных идей на следующей стадии.
Как избежать: проверять формулировку потребности вопросом «это действие/цель или уже готовое решение?» и переформулировать при необходимости.
Ошибка 2: инсайт заменяют очевидным фактом наблюдения.
Вместо неожиданной, объясняющей поведение причины записывают банальное наблюдение («пользователи заняты»), не добавляющее понимания.
Как избежать: искать инсайт через вопрос «почему это происходит именно так, вопреки ожиданиям?».
Ошибка 3: формулируют How Might We слишком узко или слишком широко.
HMW либо содержит скрытое решение, ограничивающее идеи, либо настолько абстрактен, что не даёт команде опоры для брейнсторма.
Как избежать: формулировать несколько вариантов HMW разного уровня абстракции и выбирать наиболее продуктивный для генерации идей.
Главное, что нужно знать
Стадия Define переводит богатый, но неструктурированный материал наблюдений в сфокусированную формулировку проблемы через POV и открывающие вопросы How Might We — качество этой стадии определяет, насколько продуктивной будет последующая генерация идей.
План внедрения
Неделя 1: систематизировать наблюдения предыдущей стадии, выделить повторяющиеся паттерны.
Неделя 2: сформулировать один или несколько POV из трёх частей — пользователь, потребность, инсайт.
Неделя 3: перевести каждый POV в несколько формулировок How Might We разного уровня абстракции.
Неделя 4: выбрать наиболее продуктивные HMW для перехода к стадии Ideate.
Книги по теме
Т. Браун — «Change by Design» (2009). Описание процесса Design Thinking, включая стадию Define.