Фокусировка и определение проблемы (Define)

Фокусировка и определение проблемы (Define) — вторая стадия процесса Design Thinking, принятого в Институте дизайна Хассо Платтнера при Стэнфордском университете (d.school): Empathize → Define → Ideate → Prototype → Test. На этой стадии команда превращает разрозненные наблюдения стадии Empathize в единую формулировку задачи — точку зрения (Point of View, POV): «Пользователь] нуждается в [потребности], потому что [неожиданный инсайт]» — и затем в вопросы «Как нам…?» (How Might We, HMW), которые открывают пространство для генерации идей на стадии [Ideate.

Команды редко ошибаются в том, как решать задачу, — чаще они уверенно решают не ту. Стадия Define — способ сначала убедиться, какую именно задачу стоит решать.

Материал разбирает: откуда пришли формула POV и вопрос «Как нам…?»; что показывают исследования постановки проблем (обзор Ведел-Веделльсборга, 2017); документированные примеры (Airbnb 2009, поиск проблем в P&G); как отличить потребность от решения, инсайт от факта и хороший HMW от слишком узкого или слишком широкого; метрики; типовые ошибки; и как устроен фрейм OrgDevTools.

Происхождение и исследовательская база

Стадию Define и формулу POV описали в материалах d.school (в частности, «Bootcamp Bootleg», 2010) и в книге Тима Брауна «Change by Design» (2009). Формулировка POV должна быть осмысленной и пригодной для действия: она называет пользователя, его потребность и инсайт — понимание, которое объясняет, почему потребность существует именно такой, и которое не лежит на поверхности. Идея — не пересказать наблюдения, а синтезировать их: выбрать один ракурс, который задаёт направление и одновременно оставляет команде свободу искать решения. В британской модели «Двойной алмаз» (Design Council, 2005) эта стадия — сужение первого «алмаза»: после расширения и исследования («Discover») команда «определяет» проблему («Define») и лишь затем расширяет поиск решений (двойной алмаз).

Формула «How Might We» связана с практикой Проктер энд Гэмбл 1970-х годов: канадский исследователь креативности Мин Баседур в 1971 году прошёл обучение в Институте творческого решения проблем (Creative Problem Solving Institute), где Сидней Парнс и Алекс Осборн развивали процесс постановки проблем в виде вопросов, и внедрил его в P&G; фраза «How might we…?» помогала превращать жалобы и негативные формулировки в позитивные вопросы, открытые для ответов. Позже приём подхватили консалтинговые компании и IDEO (через Чарльза Уоррена и Тима Брауна), а затем и d.school. Оговорка: история распространения приёма пересказывается по-разному; общепринято, что корни — в практике Баседура в P&G, а популяризация — в дизайн-консалтинге.

Научная рамка: Хорст Риттель и Мелвин Веббер (1973) описали «злокачественные» (wicked) проблемы, у которых нет окончательной формулировки и правильного решения: постановка проблемы и поиск решения идут вместе. Кис Дорст и Найджел Кросс (Design Studies, 2001) показали, что у опытных дизайнеров проблема и решение «ко-эволюционируют»: формулировка меняется по мере пробных решений. Дорст (2015, «Frame Innovation») развил идею «фрейма» — угла зрения на ситуацию, меняющего то, что считается проблемой. Практический вывод: формулировка POV — гипотеза, которую нужно проверять и пересматривать на следующих стадиях; см. также Prototype и Test.

Томас Ведел-Веделльсборг в статье «Are You Solving the Right Problems?» (Harvard Business Review, январь–февраль 2017) описал опрос 106 руководителей высшего звена из 91 компании в 17 странах: 85 % согласились, что их организации плохо диагностируют проблемы, а 87 % — что это приводит к значительным издержкам. Автор предлагает приёмы «переформулирования» (reframing): искать то, что выпадает из рамки, выяснять, кто ещё влияет на ситуацию, и рассматривать положительные исключения. Оговорка: это опрос руководителей и взгляд консультанта, а не измерение потерь; он показывает распространённое восприятие проблемы, а не её масштаб.

Документированные кейсы

Кейс 1. Airbnb (2009): проблема была не в спросе, а в фотографиях

Летом 2009 года выручка Airbnb стояла на уровне около 200 долларов в неделю. Основатели, по их же рассказам и публикациям о компании, предполагали проблему в маркетинге, но, вслед за советом Пола Грэма (Y Combinator) поехать к пользователям в Нью-Йорк, Брайан Чески и Джо Гебия лично посмотрели объявления хозяев. Они увидели, что фотографии квартир сделаны на дешёвые камеры и выглядят непривлекательно, — и это, а не отсутствие интереса, мешало гостям бронировать. Они лично сфотографировали квартиры около двух десятков хозяев, и, по описаниям, недельная выручка в течение недели выросла вдвое, до примерно 400 долларов. Позднее компания создала программу профессиональной съёмки.

Как читать через Define. Это пример смены формулировки: «как привлечь больше гостей?» превратилось в наблюдение о конкретном препятствии: «хозяева нуждаются в способе показать своё жильё привлекательно, потому что гости решают по фотографиям». Инсайт получен наблюдением за реальным поведением, а не обсуждением в офисе. Оговорка: история пересказывается в нескольких версиях, а цифры (200 и 400 долларов, число хозяев) — по рассказам основателей и публикациям; рост объясняется и другими факторами, поэтому её нужно воспринимать как иллюстрацию подхода, а не как доказательство эффекта.

Кейс 2. Оценка «плохой диагностики проблем» в организациях (Ведел-Веделльсборг, 2017)

Опрос 106 руководителей показал, что подавляющее большинство считает свои организации слабыми в определении проблем, а не в поиске решений. Автор описал типичные ловушки: команды быстро соглашаются с первой формулировкой, работают в рамке одной функции, недооценивают влияние контекста. Приём переформулирования — превращать проблему в вопросы с разных точек зрения (кто, где, когда), выбирать наиболее продуктивную. Этот подход совпадает с идеей нескольких HMW разного уровня абстракции. Оговорка: исследование не измеряет улучшение решений после применения приёмов; это рекомендации автора.

Кейс 3. Поиск и определение проблем в обучении (Баседур, Грэн и Грин, 1982)

Мин Баседур, Джордж Грэн и Стивен Грин в статье «Training in Creative Problem Solving: Effects on Ideation and Problem Finding and Solving in an Industrial Research Organization» (Organizational Behavior and Human Performance, 1982) проверяли, как обучение процессу творческого решения проблем, включающему поиск и определение проблемы, влияет на генерацию идей и решения в промышленной исследовательской организации. По описанию исследования, обученные сотрудники показывали улучшения в идеях и в определении проблем по сравнению с контрольной группой. Оговорка: это одно исследование 1980-х годов в конкретной организации; оно подтверждает, что навык постановки проблем поддаётся обучению, но не даёт универсальной оценки эффекта.

Ключевые идеи и принципы

1. Принцип: POV из трёх частей

   Пользователь + потребность + инсайт. Пользователь — конкретный человек или узкий сегмент («медсестра ночной смены в отделении хирургии»), а не «пользователи вообще»; потребность — то, что человек пытается сделать или получить; инсайт — неожиданная причина, объясняющая, почему потребность существует и почему её не удовлетворяют существующие решения. Все три части обязательны: без инсайта получается банальный факт, без потребности — описание, без конкретного пользователя — общие слова.

2. Принцип: потребность — глагол, а не решение

   «Нуждается в способе быстро найти нужный файл» — потребность (открывает пространство решений); «нуждается в кнопке поиска» — уже решение, закрывающее творческий поиск. Проверка: можно ли представить хотя бы три существенно разных способа удовлетворить это? Если нет — это решение. Потребность лучше выражать через результат и контекст (см. также Jobs To Be Done).

3. Принцип: инсайт — не факт наблюдения

   «Пользователи заняты» — факт; «потому что он не может оторваться от пациента, а любое действие вне палаты воспринимает как риск» — инсайт: он объясняет и неожиданно связывает наблюдения. Приёмы: искать противоречия («говорят одно, делают другое»), обходные пути, эмоции, сильные реакции; спрашивать «почему именно так, вопреки ожиданиям?»; использовать карту эмпатии и углублённую карту эмпатии для структурирования наблюдений.

4. Принцип: «Как нам…?» — открытый, но направленный вопрос

   Три слова — «как», «может быть», «мы» — задают тон: «как» — решения существуют, «могли бы» — допускаются варианты и ошибки, «мы» — работаем вместе. Хороший HMW достаточно узок, чтобы направлять, и достаточно широк, чтобы допускать разные ответы. Слишком узкий («Как нам добавить кнопку X?») содержит решение; слишком широкий («Как нам улучшить продукт?») не даёт опоры. Практика: для каждого POV сформулировать 5–10 HMW на разных уровнях абстракции, затем выбрать 2–3 наиболее продуктивных.

5. Принцип: несколько POV параллельно

   Один POV может преждевременно сузить поле. Полезно держать 2–3 альтернативных POV, отвечающих на разные сегменты и инсайты, и проверять их на следующих стадиях. Выбор между ними делают по критериям: значимость для пользователя, неожиданность инсайта, возможность влиять, соответствие стратегии.

6. Принцип: качество определяется качеством наблюдений

   Слабые данные Empathize дадут поверхностный POV. Перед Define проверьте: достаточно ли наблюдений в реальном контексте, есть ли разные пользователи и экстремальные случаи, отделены ли факты от интерпретаций, сохранены ли цитаты и фото. При нехватке данных лучше вернуться к наблюдениям (см. также выявление скрытых возражений и проблем).

7. Принцип: метрики стадии

   Метрики качества Define: доля POV, в которых все три части заполнены и проверены по чек-листу (пользователь конкретен, потребность — не решение, инсайт — не очевидный факт); число разных решений, которые команда смогла придумать за короткую сессию по выбранному HMW (тест открытости вопроса); доля HMW, содержащих скрытое решение; число вариантов HMW на один POV; оценка заказчиком и пользователями (узнаёт ли пользователь себя в POV); доля POV, пересмотренных после прототипирования и тестов (нормальный признак обучения); время от наблюдений до выбранного HMW. Метрики нужны, чтобы стадия не превращалась в формальное заполнение шаблона.

8. Принцип: применение в организации (аналогия)

   Метод годится не только для продуктов: внутренние сервисы, процессы, обслуживание клиентов, организационные изменения. Порядок: собрать наблюдения и цитаты; сгруппировать по темам; выделить противоречия и сильные эмоции; сформулировать несколько POV; проверить их вопросами (конкретный ли пользователь? потребность — глагол? инсайт неочевиден?); переформулировать в HMW; выбрать 2–3 вопроса для генерации идей; согласовать с заказчиком; вернуться к POV после тестов. Это практические рекомендации, а не универсальный стандарт.

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: потребность формулируют как готовое решение.

   POV сразу содержит решение («нуждается в мобильном приложении»), что закрывает пространство альтернатив на следующей стадии.

   Как избежать

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

2. Ошибка 2: инсайт заменяют очевидным фактом.

   Вместо неожиданной причины записывают банальное наблюдение («пользователи заняты»), которое не добавляет понимания.

   Как избежать

   искать инсайт через вопросы «почему именно так, вопреки ожиданиям?», через противоречия между словами и поведением и сильные эмоции.

3. Ошибка 3: HMW слишком узкий или слишком широкий.

   Вопрос содержит скрытое решение либо настолько абстрактен, что не даёт опоры для генерации идей.

   Как избежать

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

4. Ошибка 4: «пользователи вообще».

   POV описывает всех сразу, поэтому потребность размыта, а решения общие.

   Как избежать

   выбирать конкретный сегмент или человека с именем, ролью и контекстом; при нескольких сегментах писать несколько POV.

5. Ошибка 5: определяют проблему в офисе, не вернувшись к пользователям.

   Формулировка выводится из совещаний и мнений руководителей, а не из наблюдений.

   Как избежать

   подкреплять POV цитатами, наблюдениями и фото; при нехватке данных возвращаться к Empathize (как в истории Airbnb).

6. Ошибка 6: считают POV окончательным.

   Команда держится за первую формулировку, даже когда прототипы и тесты показывают другую проблему.

   Как избежать

   воспринимать POV как гипотезу и планировать пересмотр после тестов.

7. Ошибка 7: HMW без выбора и приоритетов.

   Команда составляет длинный список вопросов и берётся за все сразу; энергия распыляется.

   Как избежать

   выбрать 2–3 наиболее продуктивных HMW по заранее названным критериям (значимость, неожиданность, возможность влиять).

План внедрения

1. Неделя 1: систематизировать наблюдения

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

2. Неделя 2: сформулировать POV

   Написать один или несколько POV в формате «пользователь + потребность + инсайт»; проверить каждый по чек-листу (конкретный пользователь, потребность не решение, инсайт неочевиден); показать POV пользователям или коллегам.

3. Неделя 3: перевести POV в HMW

   Для каждого POV сформулировать 5–10 вопросов «Как нам…?» на разных уровнях абстракции; проверить пробной короткой сессией идей, не слишком ли узок или широк вопрос.

4. Неделя 4: выбрать HMW и перейти к Ideate

   Выбрать 2–3 наиболее продуктивных HMW по критериям, согласовать с заказчиком и командой, зафиксировать POV и HMW как исходные гипотезы для Ideate, Prototype и Test.

Как реализовать этот план с помощью фрейма «POV и How Might We (Define)» в OrgDevTools

Фрейм «POV и How Might We» (короткое название — Define) в OrgDevTools — не сетка карточек, а форма POV и список вопросов с двумя вкладками: «POV» и «Итоги».

• Вкладка «POV» — блок «POV · Point of View» с тремя многострочными полями: «Пользователь» (подсказка «Кто конкретно»), «Нуждается в…» (подсказка «Глагол действия, не решение») и «Потому что (инсайт)» (подсказка «Неожиданная причина из наблюдений»); ниже — стрелка «переформулировать в вопросы» и блок «How Might We? · Как нам…?» со списком вопросов: вопрос добавляется кнопкой «+ добавить» и удаляется крестиком (последний вопрос удалить нельзя).

• Вкладка «Итоги» — вердикт и кнопка «Создать задачу →» с задачей «Провести брейншторм по вопросу How Might We»; в описание задачи подставляется первый заполненный вопрос.

• Вердикт: если поле «Пользователь» пусто — предлагает начать с пользователя; если пользователь заполнен, но не заполнены все три поля POV — предупреждает, что POV сформулирован частично; если POV заполнен, а вопросов «Как нам…?» нет — предупреждает, что пространство для идей не открыто; иначе — сообщает число вопросов и что всё готово к стадии Ideate.

• Чего фрейм не делает — не проверяет качество формулировок (запись любого текста в поле «Нуждается в…» будет принята, даже если это готовое решение, а «инсайтом» можно назвать очевидный факт), не сравнивает несколько POV (форма рассчитана на один POV и список вопросов; альтернативные POV записывайте в отдельных экземплярах фрейма), не оценивает уровень абстракции HMW и не хранит наблюдения, на которых основан POV. Для проверки используйте чек-лист качества и обсуждение с пользователями.

Книги по теме

Тим Браун — «Change by Design» (2009). Описание процесса Design Thinking, включая стадию Define.

Stanford d.school — «An Introduction to Design Thinking: Process Guide» / «Bootcamp Bootleg» (2010). Материалы института о режимах Empathize, Define, Ideate, Prototype, Test и формуле POV.

Томас Ведел-Веделльсборг — «Are You Solving the Right Problems?» (Harvard Business Review, 2017). Опрос руководителей о слабой диагностике проблем и приёмы переформулирования.

Кис Дорст — «Frame Innovation: Create New Thinking by Design» (2015). Как «фреймы» — способы видеть ситуацию — определяют, что считается проблемой.