Double Diamond - отделай "что делать" от "зачем это делать"

На очередном планировании команда полтора часа обсуждает, какую фичу добавить первой. Кто-то тянет в сторону новой интеграции, кто-то — доработки онбординга. В какой-то момент CEO говорит: «Давайте просто сделаем и посмотрим». Команда кивает. Через три недели фича готова. Пользователи её не используют.

Не потому что плохо сделали. Потому что никто не проверил, нужно ли это вообще. Проблему взяли из головы — и пошли решать. Это называется преждевременная конвергенция: команда сходится к решению раньше, чем разобралась в проблеме.

Что такое Double Diamond

Double Diamond — фреймворк процесса разработки, предложенный Design Council в 2004 году. Визуально это два ромба: каждый раскрывается (дивергенция — расширяем поле) и сужается (конвергенция — делаем выбор). Первый ромб — про проблему. Второй — про решение.

Появился он как попытка описать, как лучшие дизайн-команды Великобритании на самом деле работали — задолго до того, как это назвали дизайн-мышлением. Разница с интуитивным подходом одна: команды, которые работали по этой логике, тратили значительно больше времени на первый ромб. И в итоге экономили его на втором.

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

Когда нужен Double Diamond

Команда уверена в проблеме — но данных нет. Продукт растёт, появляются новые сегменты, и кажется, что боль пользователей очевидна. Именно в этот момент чаще всего ошибаются: уверенность без данных — это предположение, которое никто не проверил вслух.
Фичи выходят, но метрики не двигаются. Если несколько релизов подряд не дали измеримого эффекта — это сигнал не про качество разработки. Это сигнал про то, что решается не та проблема. Double Diamond возвращает в точку, где нужно задать вопрос: «А что именно болит у пользователя прямо сейчас?». Команды в этой ситуации почти всегда говорят одно: «Мы знаем, чего хотят пользователи». Именно эта уверенность и стоит им квартала.
Продукт выходит на новый сегмент или рынок. То, что работало для одной аудитории, может не работать для другой — не потому что продукт плохой, а потому что проблема другая. Новый контекст требует нового первого ромба.
Перед значимой инвестицией в разработку. Если впереди несколько месяцев работы и серьёзный бюджет — пройти первый ромб дешевле, чем узнать в конце, что строили не то. Это касается и новых продуктов, и редизайна существующих.

Как внедрить: 4 шага

1. Discover — слушайте без предложения

Выйдите на пользователей с одним вопросом: «Расскажите, как вы решаете [задачу] сейчас». Не про продукт, не про фичи — про жизнь. Цель этой фазы — собрать сырые наблюдения, паттерны поведения, неожиданные контексты.

Критерий: вы провели не меньше 8–10 разговоров с целевым сегментом и зафиксировали минимум 3 паттерна, которых не ожидали.

2. Define — сформулируйте проблему, которую стоит решать

Из собранных наблюдений выберите одну — самую острую, самую частотную, самую дорогостоящую для пользователя. Запишите её в формате «[Кто] сталкивается с [ситуация], потому что [причина], и это приводит к [последствие]».

Deliveroo перед перезапуском логистики провели именно эту фазу и обнаружили: проблема была не в скорости доставки, а в непредсказуемости. Ресторан, курьер, клиент — каждый видел разное время. Переформулировка проблемы изменила всё решение.

Критерий: формулировка проблемы согласована командой и не содержит ни одного слова про решение.

3. Develop — генерируйте варианты количеством

Это фаза, где правила игры меняются: чем больше вариантов, тем лучше. Брейнсторм, прототипы на бумаге, аналоги из других индустрий. Задача не найти правильный ответ — задача собрать как можно больше кандидатов.

IDEO называли эту фазу «да, и…» вместо «да, но…». Каждая идея — не повод для критики, а повод для расширения.

Критерий: на столе минимум 10–15 концепций, прежде чем команда начинает оценивать.

4. Deliver — тестируйте, пока дёшево

Выберите 2–3 наиболее перспективные концепции и проверьте их на пользователях — не через разработку, а через прототипы, кликабельные макеты, ручные сервисы. Голосование внутри команды — не критерий. Реакция живого пользователя — критерий.

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

Критерий: решение выбрано на основе данных с тестирования, а не консенсуса команды.

Варианты применения

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

Для стартапов на стадии 0→1 — первый ромб заменяет Customer Development: вместо интервью «про продукт» — разговоры про жизнь и боли. Второй ромб — это MVP-итерации.

Для BDM и роста — работает для проверки новых каналов или офферов: сначала понять, какую проблему решает канал для клиента, потом тестировать механику.

Что меняется в работе

Главный бизнес-эффект Double Diamond — не в качестве финального продукта. Он в том, сколько времени команда тратит на «не то». Когда первый ромб сделан честно, второй проходит быстрее: меньше разворотов в разработке, меньше споров о приоритетах, меньше фич, которые никто не использует.

Появляется общий язык. Когда CEO предлагает новую фичу, PM может сказать: «Мы сейчас в первом ромбе — давайте сначала проверим проблему». Это не блокировка инициативы. Это способ не сжечь спринт впустую.

Решения становятся объяснимыми. Не «мы так решили», а «вот что мы услышали, вот какую проблему выбрали, вот почему этот вариант выиграл». Инвесторы, стейкхолдеры и новые члены команды видят логику, а не результат голосования.

Как применить у себя

Посмотрите на последние три фичи или направления, которые взяла команда. Для каждой: была ли сформулирована проблема до начала поиска решения — или сразу перешли ко второму ромбу? Что бы изменилось, если бы первый ромб прошли честно?