Дизайн-мышление в реальных проектах: мой процесс от эмпатии до тестирования

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

Что такое дизайн-мышление простыми словами

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

Когда дизайн-мышление действительно работает

Подход особенно полезен, если вы:

• проектируете новый продукт и ещё не понимаете поведение аудитории — особенно актуально для стартапов, где каждую гипотезу можно быстро проверить с помощью no-code прототипа на Bubble или Webflow;
• переделываете сложный интерфейс с высоким количеством ошибок — здесь без понимания корневых причин вы просто перенесёте проблемы в новый дизайн;
• ищете, почему конверсия падает, а причина неочевидна — количественные данные покажут «что», а качественные исследования объяснят «почему»;
• запускаете SaaS или внутренний сервис, где цена ошибки высока — ошибка в логике интерфейса может стоить потери клиентов, поэтому важно сначала проверить сценарии на реальных пользователях, а не полагаться на интуицию;
• работаете в команде, где у всех есть мнение, но мало фактов — дизайн-мышление заменяет бесконечные споры структурой, основанной на данных.

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

Мой рабочий цикл: от эмпатии до тестирования

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

1. Эмпатия: сначала понять людей, а не интерфейс

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

Что я собираю на этапе эмпатии

• Интервью с пользователями или клиентами — самый прямой способ услышать реальные формулировки проблем;
• Наблюдение за реальным процессом — часто люди говорят одно, а делают другое, поэтому я стараюсь увидеть их работу в естественной среде;
• Заявки в поддержку, жалобы, записи звонков — именно там лежат самые честные описания болей, которые пользователи не всегда высказывают в интервью;
• Поведенческие данные: клики, отказы, путь до цели — здесь я нередко использую инструменты вроде Hotjar или FullStory, а иногда и AI-модели для поиска аномалий в поведении;
• Контекст: устройство, частота использования, опыт, ограничения — без этого легко спроектировать интерфейс, неудобный для реальных условий.

Какие вопросы помогают

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

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

• Спрашивать «нравится ли вам интерфейс» вместо «как вы решаете задачу сейчас» — первое даёт вежливые ответы, второе — реальное поведение;
• Собирать мнения вместо наблюдений — люди часто говорят одно, а делают другое, поэтому я всегда стараюсь смотреть на действия;
• Общаться только с лояльными пользователями — те, кто уже ушёл или недоволен, дадут гораздо более ценные инсайты;
• Игнорировать тех, кто бросил продукт — их опыт часто указывает на критические проблемы;
• Делать выводы по одному интервью — единичное мнение может быть случайным, важны повторяющиеся паттерны.

Полезный принцип

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

2. Определение проблемы: без этого идеи расплываются

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

Пример слабой формулировки

«Пользователям неудобно пользоваться кабинетом».

Пример сильнее

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

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

Как я формулирую задачу

Обычно использую такой шаблон:

• Пользователь: кто?
• Ситуация: в каком контексте?
• Боль: что мешает?
• Цель: чего хочет добиться?
• Ограничение: что нельзя сломать?

Этот шаблон я вывел для себя после нескольких проектов, где мы начинали с размытых «хотелок» и потом переделывали.

Мини-чек-лист на этом этапе

• Проблема описана с точки зрения пользователя, а не команды — никаких «нам нужно увеличить конверсию», только «пользователь не может…».
• Формулировка не содержит решения — если в проблеме уже есть ответ, мы сужаем поле для идей.
• Есть конкретный сценарий — можно представить, как человек сталкивается с этой проблемой.
• Понятно, как проверить, что проблема решена — какой показатель или поведение изменится.

3. Идеация: сначала ширина, потом глубина

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

Как я генерирую идеи

• Делаю быстрые эскизы — часто прямо на бумаге или в FigJam, чтобы не тратить время на детали;
• Выписываю альтернативы без оценки — на этом этапе критика только мешает;
• Использую How Might We-вопросы — это помогает переформулировать проблему в возможность;
• Разделяю «идею функции» и «идею интерфейса» — сначала думаю о том, что должно произойти, потом о том, как это будет выглядеть;
• Смотрю на аналогичные паттерны в других продуктах — не для копирования, а чтобы понять, какие ментальные модели уже знакомы пользователям.

Практический пример

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

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

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

Ошибка, которую вижу чаще всего

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

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

Прототип — это не макет для портфолио, а инструмент проверки гипотезы. Чем быстрее я могу его собрать, тем раньше получу обратную связь. Сейчас для этого я активно использую no-code платформы: например, для проверки логики SaaS-продукта можно за пару дней собрать работающий прототип на Bubble или Glide, даже без участия разработчиков. AI-генераторы интерфейсов вроде Uizard помогают сделать первый набросок по текстовому описанию, но я всегда дорабатываю его вручную, чтобы учесть специфику сценария.

Какие прототипы я использую

• Бумажные схемы — когда нужно быстро обсудить структуру с командой;
• Вайрфреймы — для проработки информационной архитектуры и приоритетов;
• Кликабельные макеты в Figma — для юзабилити-тестов и демонстрации сценариев;
• Прототипы отдельных экранов — для сложных зон, где много состояний и переходов;
• Упрощённые MVP-версии на no-code — когда важно проверить не только интерфейс, но и логику работы с данными.

Какой прототип выбирать

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

Важный нюанс

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

5. Тестирование: здесь идеи встречаются с реальностью

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

Что я проверяю

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

Форматы тестирования

• Модераторское юзабилити-тестирование — мой основной формат для глубокого понимания;
• Быстрые проверки на 3–5 респондентах — когда нужно оперативно подтвердить или опровергнуть гипотезу;
• Удалённые сессии — через Zoom или специализированные платформы, удобно для распределённых команд;
• Сравнение нескольких вариантов экрана — A/B-тесты на прототипах помогают выбрать направление;
• Наблюдение за поведением в продукте после запуска — чтобы увидеть, как решение работает в реальных условиях.

Как задавать вопросы

Лучше спрашивать не «понятно ли?», а:

• Что вы ожидаете увидеть дальше?
• Почему вы выбрали именно этот вариант?
• Что вас смущает на этом шаге?
• Как бы вы назвали эту функцию своими словами?

Типовые ошибки на тестах

• Подсказывать ответ — это лишает тест смысла, пользователь должен сам разобраться;
• Объяснять интерфейс до того, как человек попробовал — мы не будем стоять за спиной у каждого реального пользователя;
• Делать выводы по одному сильному мнению — важны повторяющиеся паттерны, а не единичные реакции;
• Слушать только слова и не смотреть на действия — часто люди говорят, что всё понятно, но при этом не могут выполнить задачу;
• Тестировать слишком рано «идеальный» макет вместо реального сценария — если прототип перегружен деталями, пользователь может отвлекаться на визуал, а не на логику.

Что я считаю хорошим результатом

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

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

Как не превратить дизайн-мышление в ритуал

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

Признаки формального подхода

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

Что помогает держать процесс живым

• Начинать с реальной боли, а не с идеи — тогда каждый этап будет иметь смысл;
• Фиксировать гипотезы письменно — это делает их проверяемыми и не даёт «подгонять» результаты;
• Отделять факты от интерпретаций — «пользователь нажал не туда» и «пользователь запутался» — разные вещи;
• Ставить ограничения по времени — бесконечные исследования убивают momentum;
• Не бояться пересматривать выводы — если новые данные противоречат старым, это нормально.

Практический чек-лист перед стартом проекта

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

• Понятно, для кого делаем продукт — есть описание целевой аудитории, а не «все пользователи».
• Известно, какую задачу пользователь пытается решить — в терминах его целей, а не наших функций.
• Собраны хотя бы базовые факты о поведении людей — не предположения, а наблюдения или данные.
• Сформулирована проблема без решения внутри — можно показать коллеге и получить однозначное понимание.
• Есть 2–3 альтернативные идеи — не одна «гениальная», а несколько разных направлений.
• Выбран самый дешёвый способ проверки — прототип, который можно сделать за часы, а не за недели.
• Определено, что считается успехом теста — какой сигнал покажет, что гипотеза верна.

Частые вопросы

Сколько пользователей нужно для проверки?

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

Можно ли пропустить эмпатию, если сроки горят?

Можно, но это как строить дом без фундамента. Если времени мало, я провожу хотя бы 3–4 коротких интервью или анализирую существующие данные (записи поддержки, аналитику), чтобы не работать вслепую. Полное отсутствие эмпатии почти всегда приводит к переделкам на более поздних этапах.

Дизайн-мышление подходит только для новых продуктов?

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

Что важнее: интервью или аналитика?

Оба источника дополняют друг друга. Интервью объясняют мотивацию и контекст, аналитика — реальное поведение в цифрах. Вместе они дают полную картину. Я часто использую AI для анализа большого объёма качественных данных из интервью (например, расшифровок), чтобы быстрее находить повторяющиеся темы.

Вывод

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