Почему жёсткий UX-процесс мешает делать хорошие продукты

Три недели, сломанный экран мобильного банка и никакого времени на полноценный discovery. Именно такой проект объяснил мне главное: UX-процесс — это инструмент. Инструмент существует для работы, а не ради себя.

Большинство UX-дизайнеров выучили один из шаблонных фреймворков: двойной ромб (Double Diamond — двухфазная модель Design Council), дизайн-мышление, Agile UX. Все они описывают похожую последовательность — исследование, анализ, генерация идей, тестирование. На бумаге выглядит убедительно. В реальных проектах — не всегда.

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

Зачем вообще нужен дизайн-процесс

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

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

Когда процесс становится помехой

Процесс как цель вместо инструмента

В какой-то момент команды начинают больше думать о том, на каком этапе они находятся, чем о том, правильную ли проблему решают. Разговоры сводятся к вопросам: закончили ли мы discovery? Достаточно ли у нас персон? Нужно ли делать journey map?

Сами по себе эти вопросы нормальны. Но они становятся помехой, если отвлекают от главного — понимания и решения пользовательской проблемы.

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

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

Когда реальные ограничения ломают любой план

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

По учебнику нужно было провести полноценный discovery, набрать персоны, построить journey map. На практике этого времени не было. Вместо этого — анализ существующих данных, тикеты службы поддержки и четыре интервью с пользователями. Они помогли выявить три главных проблемы. Команда из четырёх дизайнеров опиралась на готовую дизайн-систему заказчика: каждый создал своё направление — так получилось четыре конкурирующих решения, которые можно было сразу тестировать с пользователями.

Важный момент: аналитика показала, что около 35% пользователей бросали транзакцию на полпути — после выбора получателя, но до подтверждения перевода. Сессионные записи и тикеты указывали на то же место. Интервью объяснили почему там возникала пауза.

Настоящий вопрос — не «всё ли мы знаем?», а «достаточно ли мы знаем для принятия взвешенного решения прямо сейчас?». Иногда именно это и есть реалистичный стандарт.

UX-дизайнерLogRocket Blog

Три урока из практики

Из этого опыта я вывел три принципа, которые помогают адаптировать процесс к реальным условиям.

1. Адаптируйте процесс к задаче

В праве есть принцип пропорциональности: даже когда преследуется законная цель, нужно использовать наименее инвазивный метод. Та же идея работает в дизайне.

Не каждый проект требует долгого discovery, детальных персон или полноценного journey mapping. Перед тем как выбирать UX-активности, задайте вопрос: что нужно узнать или проверить, чтобы принять хорошее решение? Затем выберите минимально достаточный процесс. Срезайте шаги, которые не служат проекту — но не срезайте углы там, где риски высоки.

Иногда формальный процесс — именно то, что нужно. В enterprise-продуктах, в регулируемых отраслях (финтех, медтех, госсектор), при крупных запусках с несколькими командами структура снижает риски и удерживает всех в одном фокусе. Цель — не минимизировать процесс ради минимизации. Цель — сделать его пропорциональным задаче.

2. Совмещайте этапы, когда это помогает

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

• Если можно анализировать существующие данные и параллельно рекрутировать пользователей — делайте это одновременно
• Если можно набрасывать концепции, пока ещё идёт исследование — набрасывайте
• Если можно начать тестировать грубые идеи, не дождавшись ответов на все вопросы — тестируйте

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

3. Привлекайте команду как можно раньше

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

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

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

Гибкий фреймворк из пяти шагов

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

Шаг 1. Соберите ресурсы

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

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

Шаг 2. Что команда уже знает

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

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

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

Шаг 3. Что ещё неизвестно

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

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

Шаг 4. Прототипируйте раньше, чем кажется нужным

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

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

Шаг 5. Рефлексируйте и корректируйте

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

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

Вывод

Дизайн-процесс — не враг хорошего UX. Правильно применённый, он даёт команде структуру, помогает принимать обоснованные решения и фокусироваться на пользователях.

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

Хороший UX-процесс поддерживает лучшие решения. Он не должен мешать их принятию.

Источник: Rethinking the UX design process — LogRocket Blog