Команда получает задачу и сразу бросается придумывать решение — новую фичу, новый дизайн, новый процесс. Решение получается технически хорошим, но не решает реальную проблему пользователя, потому что саму проблему толком не исследовали. Спешка на этапе понимания проблемы почти гарантированно приводит к красивому, но бесполезному решению.
Самая быстрая команда, решающая неправильную проблему, приходит к результату быстрее всех — но результат никому не нужен.
Происхождение и исследовательская база
Модель разработана британским Design Council и опубликована в 2005 году по итогам исследования процессов проектирования одиннадцати ведущих мировых компаний (включая Sony, Nike, LEGO). Название "двойной алмаз" отражает форму диаграммы — два ромба, каждый из которых сначала расширяется (дивергенция, генерация вариантов), затем сужается (конвергенция, фокусировка на одном варианте).
Задокументированный реальный кейс применения Double Diamond самим Design Council: в 2008 году совместно с Министерством здравоохранения Великобритании и Агентством закупок NHS был запущен проект «Design Bugs Out» для борьбы с внутрибольничными инфекциями через переосмысление больничной мебели и оборудования. Discover: команда дизайнеров, эргономистов и исследователей провела месяц интервью с пациентами и персоналом в больницах NHS в Хаддерсфилде, Манчестере и Саутгемптоне, наблюдая, как реально происходит уборка и распространение бактерий в палатах. Define: широкое исследование сузилось до конкретной, чётко сформулированной проблемы — конструкция стандартной больничной мебели (кресла для пациентов, прикроватные тумбочки, столики) физически затрудняла качественную очистку и создавала скрытые зоны накопления патогенов. Develop и Deliver: команда разработала и протестировала на восьми показательных больницах Англии четыре новых изделия — легко очищаемое кресло-туалет, кресло пациента, прикроватную тумбочку и надкроватный столик, каждое из которых прошло проверку на реальную эффективность очистки по сравнению со стандартной заражённой больничной мебелью. Это прямая иллюстрация принципа «не переходить ко второму алмазу, пока не определена проблема»: только после месяца полевых интервью в реальных больницах команда перешла от исследования к генерации конкретных дизайнерских решений, а не начала проектировать мебель на основе предположений.
Ключевые идеи и принципы
Принцип: Первый алмаз — понять правильную проблему (Discover → Define)
Discover (открытие) — широкое исследование контекста, пользователей, рынка без предварительных гипотез о решении. Define (определение) — сужение множества наблюдений до одной чётко сформулированной проблемы, которую стоит решать.
Принцип: Второй алмаз — найти правильное решение (Develop → Deliver)
Develop (разработка) — генерация широкого спектра возможных решений найденной проблемы, включая нестандартные варианты. Deliver (поставка) — тестирование, доработка и вывод в жизнь одного выбранного решения.
Принцип: Дивергенция перед конвергенцией на каждом этапе
На каждом из двух ромбов сначала намеренно расширяется пространство вариантов (не сужать преждевременно), и только потом происходит осознанный выбор — преждевременная фокусировка на одном варианте (проблемы или решения) — главный риск, который модель призвана предотвратить.
Принцип: Не переходить ко второму алмазу, пока не определена проблема
Переход от Define к Develop должен происходить только после того, как проблема чётко сформулирована и согласована — попытка одновременно исследовать проблему и придумывать решение размывает оба процесса.
Ограничения, слепые зоны и критика
Модель описывает идеализированную линейную последовательность, тогда как реальный процесс часто требует возврата к предыдущим этапам при получении новой информации — жёсткое следование линейности без итераций противоречит духу самого дизайн-мышления. Модель не даёт конкретных инструментов внутри каждого этапа (какими методами исследовать, как генерировать идеи) — это скорее рамка процесса, требующая наполнения конкретными техниками (интервью, карта эмпатии, прототипирование). Полный цикл двойного алмаза занимает значительное время, что плохо совместимо с ситуациями, требующими быстрого реагирования — модель рассчитана на продуктовые и стратегические задачи, а не на операционные решения под давлением.
Типовые ошибки
Ошибка 1: Команда сразу переходит к решению, минуя первый алмаз.
Проблема не исследована, решение придумывается на основе предположений команды, а не реальных данных о пользователях и контексте.
Как избежать: Выделять явное время на Discover и Define, прежде чем разрешать команде генерировать решения.
Ошибка 2: Дивергенция на этапе Discover сворачивается слишком рано.
Команда быстро фиксируется на первой попавшейся гипотезе о проблеме, не исследовав достаточно широкий контекст.
Как избежать: Устанавливать минимальный объём исследования (число интервью, источников данных) перед переходом к Define.
Ошибка 3: Define формулирует проблему слишком широко или слишком узко.
Слишком широкая формулировка не даёт фокуса для второго алмаза, слишком узкая — исключает потенциально верные направления решения.
Как избежать: Проверять формулировку проблемы на конкретность и at the same время достаточную открытость для разных решений.
Ошибка 4: Develop генерирует только очевидные, безопасные варианты.
Команда быстро останавливается на первом разумном решении вместо честной дивергенции с нестандартными вариантами.
Как избежать: Требовать минимальное количество принципиально разных вариантов решения перед переходом к отбору.
Ошибка 5: жёстко следуют линейной последовательности этапов, игнорируя новую информацию, полученную на поздних стадиях.
В реальном процессе Design Bugs Out тестирование прототипов на восьми больницах неизбежно выявляло детали, требовавшие доработки конструкции, — жёсткое следование линейной модели «раз прошли Define, к нему больше не возвращаемся» противоречило бы собственному разделу «Ограничения» модели, прямо признающему необходимость возврата к предыдущим этапам при получении новой информации.
Как избежать: Относиться к четырём фазам как к логической последовательности фокуса внимания, а не к жёсткому, необратимому конвейеру — быть готовым вернуться к Define или даже Discover, если тестирование на этапе Deliver вскрывает, что исходная формулировка проблемы была неполной.
Главное, что нужно знать
Двойной алмаз структурирует процесс дизайн-мышления в два цикла дивергенции-конвергенции: сначала широко исследовать контекст и точно определить правильную проблему (первый алмаз), затем широко сгенерировать варианты решения и довести до жизни лучший (второй алмаз). Ключевая дисциплина — не переходить к решению, пока проблема не понята и не сформулирована явно.
План внедрения
Неделя 1-2: Discover — широкое исследование контекста и пользователей без предварительных гипотез о решении.
Неделя 3: Define — сузить исследование до одной чётко сформулированной проблемы.
Неделя 4-5: Develop — сгенерировать широкий спектр вариантов решения найденной проблемы.
Неделя 6: Deliver — протестировать и довести до жизни выбранное решение.
Далее: поддержание и обновление — при получении новых данных быть готовым вернуться к предыдущему этапу, а не жёстко следовать линейности.
Как реализовать этот план с помощью фрейма «Двойной алмаз (Double Diamond)» в OrgDevTools
Фрейм состоит из четырёх карточек, соответствующих фазам модели — Discover, Define, Develop, Deliver.
Неделя 1-2 — карточка «Discover». Требует широкого исследования контекста и пользователей без предварительных гипотез о решении — именно так команда Design Bugs Out провела месяц интервью в реальных больницах NHS, прежде чем формулировать проблему.
Неделя 3 — карточка «Define». Требует сузить исследование до одной чётко сформулированной проблемы — в кейсе NHS широкое наблюдение сузилось до конкретной проблемы конструкции мебели, затрудняющей очистку.
Неделя 4-5 — карточка «Develop». Требует широкого спектра вариантов решения, а не первого разумного — вердикт фрейма прямо предупреждает: без прохода всех четырёх фаз «решение рискует быть первой попавшейся идеей, а не проверенной», защита от ошибки 4.
Неделя 6 — карточка «Deliver». Требует протестировать и довести до жизни выбранное решение — именно так четыре прототипа Design Bugs Out прошли проверку на реальную эффективность очистки на восьми показательных больницах, прежде чем считаться готовым решением.