Метод двойного бриллианта в UX-дизайне

Метод двойного бриллианта – один из самых известных и широко используемых подходов в UX-дизайне и разработке инновационных продуктов. Главная особенность метода заключается в четком разделении этапов понимания проблемы и разработки решения. Такой подход помогает избежать одной из самых распространенных ошибок в дизайне – создания качественного продукта, который решает неверно определенную задачу.

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

Метод двойного бриллианта (Double Diamond) – это структура проектирования и решения проблем, который помогает командам системно исследовать потребности пользователей, точно формулировать задачи и находить наиболее эффективные решения. Он получил широкое распространение в UX-дизайне, разработке цифровых продуктов и инновационном менеджменте.

В современном виде модель была представлена Британским советом по дизайну (Design Council) в 2005 году после изучения процессов проектирования в ведущих мировых компаниях. Исследователи обнаружили, что успешные проекты, независимо от отрасли, следуют схожему сценарию: сначала команды широко исследуют проблему и постепенно сужают ее до четкой формулировки, а затем таким же образом переходят от множества возможных идей к одному наиболее эффективному решению. Эта закономерность была визуализирована в виде двух соединенных ромбов – отсюда и название «Двойной бриллиант».

Однако истоки этого подхода появились значительно раньше. Еще в 1960-х годах американские исследователи Алекс Осборн и Сидни Парнс разработали процесс CPS (Creative Problem Solving), основанный на чередовании генерации идей и их отбора. Позднее венгеро-американский ученый Бела Банати развил концепцию дивергентного и конвергентного мышления, показав, что эффективное решение сложных задач требует последовательного перехода от широкого исследования к концентрации на наиболее важных аспектах проблемы.

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

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

Визуально модель состоит из двух последовательных «бриллиантов». Первый представляет пространство проблемы, а второй – пространство решения. Первый бриллиант помогает ответить на вопрос: «Какую проблему мы действительно должны решать?», а второй – «Какое решение будет наиболее эффективным?».

Весь процесс включает четыре этапа:

• Исследование – изучение пользователей, их потребностей, поведения и контекста использования продукта.
• Определение – анализ полученных данных и формулирование основной проблемы, которую необходимо решить.
• Разработка – генерация идей, создание концепций и прототипов возможных решений.
• – тестирование, доработка и внедрение наиболее жизнеспособного решения.

Одним из главных преимуществ метода является то, что он помогает избежать распространенной ошибки — преждевременного поиска решения без глубокого понимания самой проблемы. Команды не начинают проектирование сразу, а сначала исследуют ситуацию, проверяют свои предположения и только затем переходят к разработке. Такой подход повышает вероятность создания продукта, который действительно отвечает ожиданиям пользователей.

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

Этот этап относится к дивергентной части модели, поэтому на нем приветствуется широкий взгляд на проблему. Команда не ограничивается первоначальными предположениями, а рассматривает все возможные причины существующих трудностей и изучает разные точки зрения. Важно не спешить с выводами и не пытаться сразу найти решение, поскольку преждевременное сужение фокуса может привести к тому, что будет решаться не та проблема, которая действительно важна для пользователей.

В процессе исследования обычно задаются открытые вопросы:

• Какие трудности испытывают пользователи?
• Что является причиной этих проблем?
• Кто участвует в процессе и каким образом затронут существующей ситуацией?
• Какие потребности пользователей остаются неудовлетворенными?
• Каковы бизнес-цели и ограничения проекта?

Чтобы ответить на эти вопросы, UX-команды используют различные методы исследования, сочетая качественные и количественные данные.

Исследование обычно начинается с анализа уже существующей информации. Команда изучает статьи, отчеты, аналитические материалы, статистику и предыдущие исследования. Это позволяет получить общее представление о проблеме, выявить тенденции и сформировать первоначальные гипотезы.

После этого проводится первичное исследование, которое предполагает непосредственное взаимодействие с пользователями. Наиболее распространенными методами являются:

Интервью с пользователями

Это один из самых ценных инструментов UX-исследования. Интервью позволяют узнать о реальном опыте пользователей, их целях, ожиданиях и трудностях. Они могут быть структурированными, полуструктурированными или свободными, однако чаще всего используются полуструктурированные интервью, которые сочетают заранее подготовленные вопросы с возможностью углубиться в интересные темы по ходу беседы.

Опросы

Опросы помогают собрать данные от большого количества пользователей и выявить общие закономерности. Они особенно полезны для количественной оценки проблем и проверки гипотез, сформированных на основе интервью.

Наблюдение

Иногда лучший способ понять пользователя – увидеть, как он взаимодействует с продуктом в реальной жизни. Наблюдение позволяет выявить привычки, поведение и трудности, о которых пользователи могут даже не упоминать в интервью. Такой метод особенно важен для создания продуктов, ориентированных на реальные сценарии использования.

Фокус-группы

Этот метод представляет собой групповое обсуждение, в ходе которого участники делятся своими мнениями и опытом. Фокус-группы позволяют быстро собрать разнообразные точки зрения, однако требуют внимательной модерации, поскольку мнения участников могут влиять друг на друга.

Конкурентный анализ

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

Карты эмпатии

Одним из ключевых принципов этапа исследования является развитие эмпатии по отношению к пользователям. Дизайнеры стремятся понять не только то, что люди делают, но и то, что они думают, чувствуют, видят и слышат в процессе взаимодействия с продуктом.

Для этого часто используются карты эмпатии. Они помогают структурировать наблюдения и зафиксировать:

• что пользователь говорит;
• что он делает;
• что он думает;
• что чувствует;
• что видит вокруг себя;
• что слышит от окружающих.

Такой инструмент позволяет команде лучше понять мотивацию пользователей и увидеть проблему их глазами.

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

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

Главная цель этапа – сформулировать понятное и практическое описание проблемы, которое станет основой для дальнейшей разработки. Хорошо сформулированная проблема должна:

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

Например, в ходе исследования CRM-системы можно обнаружить, что пользователи редко используют функции создания отчетов, поскольку интерфейс слишком сложен, а для работы требуется большое количество ручного ввода данных. В таком случае проблема заключается не в недостатке функций, а в сложности их использования. Именно эта формулировка будет определять дальнейшее направление проектирования.

Анализ и приоритизация данных

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

Одним из наиболее распространенных инструментов является диаграмма сходства (Affinity Mapping). С ее помощью исследовательские данные объединяются в группы по общим темам. Например, жалобы пользователей могут быть связаны с навигацией, сложностью интерфейса или отсутствием нужной информации. Такая структуризация позволяет увидеть, какие проблемы возникают чаще всего и требуют первоочередного внимания.

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

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

Метод «Розы и шипы»

Для определения приоритетов команда может использовать упражнение «Розы и шипы». Его цель – выделить положительные и отрицательные аспекты пользовательского опыта.

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

Формулирование вопросов «Как мы можем…?»

После определения основных болевых точек часто применяется техника HMW (How Might We), что можно перевести как «Как мы можем…?».

Суть метода заключается в том, чтобы преобразовать проблемы в открытые вопросы, стимулирующие поиск решений. Например, вместо вопроса «Как заставить пользователей отказаться от определенного поведения?» можно сформулировать более широкий вопрос: «Как мы можем улучшить пользовательский опыт, учитывая существующие привычки пользователей?».

Такая формулировка помогает команде сосредоточиться не на ограничениях, а на поиске возможностей и новых идей.

Поиск первопричин проблемы

Важной частью этапа определения является выявление не только симптомов, но и истинных причин проблемы. Для этого используются специальные методы анализа.

Одним из них является метод «5 почему», который предполагает последовательное задавание вопроса «Почему?» до тех пор, пока не будет найдена корневая причина проблемы.

Например:

• Пользователи не используют функцию отчетов. Почему?

Потому что она слишком сложна.

• Почему она кажется сложной?

Потому что требует большого количества действий.

• Почему требуется так много действий?

Потому что интерфейс ориентирован на опытных пользователей.

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

Также для анализа причин может использоваться диаграмма Исикавы («рыбья кость»), которая помогает рассмотреть проблему с разных сторон: с точки зрения процессов, технологий, среды, персонала и других факторов.

                                                              ***

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

Именно на этом этапе закладывается фундамент будущего решения. Если проблема сформулирована правильно, последующие этапы – разработка и реализация – будут направлены на решение реальных пользовательских задач, а не на создание функций, которые окажутся невостребованными.

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

Как и этап исследования, стадия разработки относится к дивергентной части модели. Однако если раньше команда исследовала проблему, то теперь она широко исследует возможные способы ее решения. На этом этапе приветствуются креативность, эксперименты и нестандартное мышление. Важно не ограничивать себя только очевидными вариантами, поскольку именно разнообразие идей позволяет найти действительно эффективное и инновационное решение.

Генерация идей

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

На этом этапе действует важное правило: количество важнее качества. Даже самые необычные или на первый взгляд нереалистичные идеи могут стать основой для успешного решения в дальнейшем.

Одним из популярных инструментов генерации идей является Креативная матрица. Она строится на основе вопросов «Как мы можем…?», сформулированных на предыдущем этапе. По горизонтали располагаются ключевые вопросы, а по вертикали – различные области, например:

• технологии;
• социальные сети;
• игры;
• искусственный интеллект;
• люди и сообщества;
• мобильные устройства;
• геймификация.

На пересечении вопроса и темы команда предлагает как можно больше идей. Такой подход помогает выйти за рамки привычных решений и стимулирует творческое мышление.

Создание прототипов

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

Сначала используются низкодетализированные прототипы. Это могут быть:

• эскизы интерфейсов;
• бумажные макеты;
• схемы экранов;
• вайрфреймы;
• простые кликабельные модели.

Главная цель таких прототипов – быстро представить идею в наглядном виде и проверить ее без значительных затрат времени и ресурсов.

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

Тестирование и итерации

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

Пользователи взаимодействуют с прототипами, а команда анализирует:

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

Такой процесс называют итеративным проектированием. Команда может неоднократно возвращаться к предыдущим версиям решений, пересматривать концепции и экспериментировать с новыми подходами.

Например, если исследование показало, что пользователи интернет-магазина отказываются от покупки из-за долгой доставки, команда может рассмотреть сразу несколько решений:

• отображать сроки доставки еще до добавления товара в корзину;
• рекомендовать альтернативные товары с более быстрой доставкой;
• предлагать товары, которые доступны в ближайшем магазине;
• внедрить интеллектуальный поиск, учитывающий доступность товара.

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

Использование MVP

Еще одним важным инструментом данного этапа является MVP (Minimum Viable Product) – минимально жизнеспособный продукт.

MVP представляет собой версию продукта с минимальным набором функций, достаточным для решения основной задачи пользователя. Такой подход позволяет:

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

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

Персоны и пользовательские сценарии

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

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

                                                               ***

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

Таким образом, этап разработки превращает абстрактную формулировку проблемы в реальные идеи и рабочие прототипы, позволяя команде найти решение, которое одновременно отвечает потребностям пользователей, соответствует бизнес-целям и является технически реализуемым.

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

Если предыдущие стадии были направлены на исследование, формулирование проблемы и генерацию идей, то реализация – это этап конвергенции, где множество вариантов сужается до одного итогового решения. Здесь особенно важно убедиться, что выбранная концепция действительно решает проблему, выявленную на этапе определения, и соответствует как пользовательским потребностям, так и бизнес-целям.

Выбор финального решения

На начальном этапе реализации команда возвращается к ранее разработанным идеям и прототипам. Часто используется визуальное голосование, при котором каждый участник команды выбирает наиболее перспективные решения (обычно 1–2 варианта). Затем обсуждаются лидирующие идеи, их сильные и слабые стороны, а также возможности улучшения.

Для дальнейшей приоритизации может использоваться метод матрицы влияния и сложности. Он помогает распределить идеи по двум критериям:

• насколько сильно решение влияет на пользовательский опыт и бизнес-результаты;
• насколько сложно его реализовать с технической и организационной точки зрения.

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

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

Подготовка к реализации

После выбора финальной концепции команда приступает к ее детальной проработке. Создаются высокодетализированные прототипы, максимально приближенные к реальному продукту. Они включают финальный визуальный дизайн, проработанную структуру интерфейса и взаимодействие между экранами.

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

Разработка и запуск продукта

На этапе реализации разработчики превращают утвержденные макеты и прототипы в работающий продукт. Это включает программирование, интеграцию систем и подготовку продукта к запуску.

Параллельно могут проводиться дополнительные активности, связанные с выводом продукта на рынок:

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

Эти действия помогают обеспечить успешное внедрение решения и его быстрое принятие аудиторией.

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

• юзабилити-тестирование – наблюдение за тем, как пользователи выполняют задачи в готовом продукте;
• опросы пользователей – сбор обратной связи о качестве и удобстве решения;
• метод «мысли вслух» – пользователи комментируют свои действия при работе с продуктом;
• теневое наблюдение – команда наблюдает за реальным использованием продукта в естественной среде.

Также могут использоваться A/B-тестирование и проверки доступности, чтобы убедиться, что продукт подходит максимально широкой аудитории.

Запуск и оценка эффективности

После запуска продукта работа команды не заканчивается. Важно отслеживать его эффективность в реальных условиях. Для этого используются ключевые показатели эффективности (KPI), такие как уровень вовлеченности пользователей, конверсия, удовлетворенность клиентов и частота использования продукта.

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

                                                              ***

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

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

1. Пропуск этапа исследования

Одна из самых распространенных и критичных ошибок – попытка сразу перейти к решению, минуя первый «бриллиант». Фраза «мы уже знаем проблему» часто приводит к тому, что команда работает с неверными предположениями.

Без полноценного этапа исследования существует высокий риск создать продукт, который решает не ту задачу. В результате ресурсы тратятся впустую, а итоговое решение не приносит ожидаемой ценности пользователям.

2. Линейное восприятие процесса

Метод двойного бриллианта часто ошибочно воспринимается как строгая последовательность шагов, которые нельзя нарушать. На практике это итеративный процесс, в котором команды регулярно возвращаются к предыдущим этапам.

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

3. Путаница между дивергентным мышлением и отсутствием фокуса

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

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

4. Слишком сильная детализация на ранних этапах

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

Однако цель этого этапа – обучение через быстрые итерации, а не создание финального продукта. Излишняя детализация замедляет процесс и снижает гибкость.

5. Неправильное понимание этапа определения

Еще одна распространенная ошибка – восприятие этапа определения как обычного дизайн-брифа. На самом деле этот этап должен привести к конкретной, измеримой формулировке проблемы, а не к размытым задачам вроде «улучшить пользовательский опыт».

Четкое определение проблемы является основой для всех последующих решений, и его качество напрямую влияет на успех проекта.

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

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