Double Diamond (Двойной алмаз, Design Council)

Команда получает задачу и сразу бросается придумывать решение — новую фичу, новый дизайн, новый процесс. Решение получается технически хорошим, но не решает реальную проблему пользователя, потому что саму проблему толком не исследовали. Спешка на этапе понимания проблемы почти гарантированно приводит к красивому, но бесполезному решению.

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

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

Модель разработана британским Design Council и опубликована в 2005 году по итогам исследования процессов проектирования одиннадцати ведущих мировых компаний (включая Sony, Nike, LEGO). Название "двойной алмаз" отражает форму диаграммы — два ромба, каждый из которых сначала расширяется (дивергенция, генерация вариантов), затем сужается (конвергенция, фокусировка на одном варианте).

Задокументированный реальный кейс применения Double Diamond самим Design Council: в 2008 году совместно с Министерством здравоохранения Великобритании и Агентством закупок NHS был запущен проект «Design Bugs Out» для борьбы с внутрибольничными инфекциями через переосмысление больничной мебели и оборудования. Discover: команда дизайнеров, эргономистов и исследователей провела месяц интервью с пациентами и персоналом в больницах NHS в Хаддерсфилде, Манчестере и Саутгемптоне, наблюдая, как реально происходит уборка и распространение бактерий в палатах. Define: широкое исследование сузилось до конкретной, чётко сформулированной проблемы — конструкция стандартной больничной мебели (кресла для пациентов, прикроватные тумбочки, столики) физически затрудняла качественную очистку и создавала скрытые зоны накопления патогенов. Develop и Deliver: команда разработала и протестировала на восьми показательных больницах Англии четыре новых изделия — легко очищаемое кресло-туалет, кресло пациента, прикроватную тумбочку и надкроватный столик, каждое из которых прошло проверку на реальную эффективность очистки по сравнению со стандартной заражённой больничной мебелью. Это прямая иллюстрация принципа «не переходить ко второму алмазу, пока не определена проблема»: только после месяца полевых интервью в реальных больницах команда перешла от исследования к генерации конкретных дизайнерских решений, а не начала проектировать мебель на основе предположений.

Второй задокументированный кейс — из совершенно другой сферы, цифрового продукта коммерческой компании, а не физического изделия для государственного здравоохранения: LEGO, одна из одиннадцати компаний, чьи процессы легли в основу самой модели Double Diamond, впоследствии применила её к редизайну раздела «LEGO Education» своего сайта, адресованного учителям, ищущим учебные материалы. Discover: команда провела этнографическое исследование прямо в классах десяти европейских школ, наблюдая, как учителя реально ищут и подбирают учебные материалы в процессе подготовки уроков. Define: широкое наблюдение сузилось до конкретной проблемы — учителям было принципиально важно находить материалы по учебной цели урока (какой навык или тему материал помогает освоить), тогда как существовавшая навигация сайта была построена вокруг возраста ребёнка и конкретного продукта LEGO, что не соответствовало реальной логике поиска учителя. Develop и Deliver: команда разработала и протестировала с учителями три разных варианта информационной архитектуры сайта, прежде чем выбрать и запустить окончательную версию с навигацией, построенной вокруг учебных целей и навыков, а не вокруг возраста или товарной линейки. В отличие от кейса NHS, где ошибочное предположение касалось физической конструкции мебели, в кейсе LEGO ошибочным предположением изначально было представление о том, по какому принципу пользователь вообще ищет информацию, — оба кейса объединяет одно: правильное решение (новая мебель, новая навигация) стало возможным только после того, как первый алмаз выявил, что исходное предположение команды о самой проблеме было неверным.

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

1. Принцип: Первый алмаз — понять правильную проблему (Discover → Define)

   Discover (открытие) — широкое исследование контекста, пользователей, рынка без предварительных гипотез о решении. Define (определение) — сужение множества наблюдений до одной чётко сформулированной проблемы, которую стоит решать.

2. Принцип: Второй алмаз — найти правильное решение (Develop → Deliver)

   Develop (разработка) — генерация широкого спектра возможных решений найденной проблемы, включая нестандартные варианты. Deliver (поставка) — тестирование, доработка и вывод в жизнь одного выбранного решения.

3. Принцип: Дивергенция перед конвергенцией на каждом этапе

   На каждом из двух ромбов сначала намеренно расширяется пространство вариантов (не сужать преждевременно), и только потом происходит осознанный выбор — преждевременная фокусировка на одном варианте (проблемы или решения) — главный риск, который модель призвана предотвратить.

4. Принцип: Не переходить ко второму алмазу, пока не определена проблема

   Переход от Define к Develop должен происходить только после того, как проблема чётко сформулирована и согласована — попытка одновременно исследовать проблему и придумывать решение размывает оба процесса.

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

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

Ошибка 1: Команда сразу переходит к решению, минуя первый алмаз.

Проблема не исследована, решение придумывается на основе предположений команды, а не реальных данных о пользователях и контексте.

Как избежать: Выделять явное время на Discover и Define, прежде чем разрешать команде генерировать решения.

Ошибка 2: Дивергенция на этапе Discover сворачивается слишком рано.

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

Как избежать: Устанавливать минимальный объём исследования (число интервью, источников данных) перед переходом к Define.

Ошибка 3: Define формулирует проблему слишком широко или слишком узко.

Слишком широкая формулировка не даёт фокуса для второго алмаза, слишком узкая — исключает потенциально верные направления решения.

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

Ошибка 4: Develop генерирует только очевидные, безопасные варианты.

Команда быстро останавливается на первом разумном решении вместо честной дивергенции с нестандартными вариантами.

Как избежать: Требовать минимальное количество принципиально разных вариантов решения перед переходом к отбору.

Ошибка 5: жёстко следуют линейной последовательности этапов, игнорируя новую информацию, полученную на поздних стадиях.

В реальном процессе Design Bugs Out тестирование прототипов на восьми больницах неизбежно выявляло детали, требовавшие доработки конструкции, — жёсткое следование линейной модели «раз прошли Define, к нему больше не возвращаемся» противоречило бы собственному разделу «Ограничения» модели, прямо признающему необходимость возврата к предыдущим этапам при получении новой информации.

Как избежать: Относиться к четырём фазам как к логической последовательности фокуса внимания, а не к жёсткому, необратимому конвейеру — быть готовым вернуться к Define или даже Discover, если тестирование на этапе Deliver вскрывает, что исходная формулировка проблемы была неполной.

1. Ошибка 6: исследование на этапе Discover подтверждает изначальное предположение команды о категории проблемы, вместо того чтобы поставить это предположение под сомнение.

   Команда LEGO до начала проекта могла бы предположить, что дело в недостаточном количестве материалов или в устаревшем визуальном дизайне сайта, — и, не проведя настоящего этнографического наблюдения за учителями в реальных классах, легко подтвердила бы одну из этих поверхностных гипотез. Реальная находка — что сам принцип навигации (по возрасту/товару, а не по учебной цели) был категориально неверным — стала возможна только потому, что Discover проектировался как открытое наблюдение за реальным поведением, а не как проверка заранее выбранной гипотезы.

   Как избежать

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

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

1. Неделя 1-2: Discover — широкое исследование контекста и пользователей без предварительных гипотез о решении.

2. Неделя 3: Define — сузить исследование до одной чётко сформулированной проблемы.

3. Неделя 4-5: Develop — сгенерировать широкий спектр вариантов решения найденной проблемы.

4. Неделя 6: Deliver — протестировать и довести до жизни выбранное решение.

   Далее: поддержание и обновление — при получении новых данных быть готовым вернуться к предыдущему этапу, а не жёстко следовать линейности.

Как реализовать этот план с помощью фрейма «Двойной алмаз (Double Diamond)» в OrgDevTools

Фрейм превращает план внедрения в рабочую тетрадь, в которой вместо заметок нужны цифры. Вы вносите, сколько исследований провели, сколько людей и инсайтов собрали, сколько формулировок проблемы и концепций решения перебрали и что показали тесты. По этим данным фрейм показывает, где алмаз «сплющился», и выносит итог. Это бесплатный тренажёр: на нём можно пройти оба алмаза на учебной задаче или на живом проекте команды.

Книги по теме

Design Council — «Eleven Lessons: Managing Design in Eleven Global Companies» (2005). Первоисточник модели, основан на исследовании реальных процессов проектирования одиннадцати компаний.