Что такое дизайн-мышление: этапы и примеры
Основы3 минРедакция Innovialabs
Коротко
Дизайн-мышление — подход к решению задач, который начинается с понимания людей и проходит пять этапов: эмпатия, фокусировка, генерация идей, прототип и тест. Его ценность — в дешёвой проверке гипотез на реальных пользователях до разработки, а не в воркшопах со стикерами.
Дизайн-мышление в одном абзаце
Дизайн-мышление — способ решать задачи, начиная с людей, у которых эта задача есть. Вместо того чтобы сразу придумывать решение, команда сначала выясняет, как пользователи ведут себя на самом деле, формулирует настоящую проблему, генерирует несколько идей, быстро собирает прототипы и тестирует их. Этапы обычно называют эмпатия, фокусировка, идеи, прототип и тест, и они повторяются циклами, а не проходятся один раз по прямой.
Пять этапов
| Этап | Цель | Что делают | Результат |
|---|---|---|---|
| Эмпатия | Понять пользователей и их контекст | Интервью, наблюдение, обращения в поддержку, аналитика | Заметки, цитаты, наблюдаемое поведение |
| Фокусировка | Сформулировать правильную проблему | Группировка находок, формулировка проблемы | Одна чёткая задача |
| Идеи | Найти много вариантов решения | Брейншторм, скетчи, вопросы «как мы можем…» | Шорт-лист идей |
| Прототип | Дёшево сделать идеи осязаемыми | Бумажные скетчи, кликабельные макеты в Figma | То, что можно попробовать |
| Тест | Понять, что работает | Юзабилити-сессии с реальными пользователями | Основания доработать или двигаться дальше |
Реалистичный пример: запись в клинику
Представьте частную клинику: страницу онлайн-записи открывают, но до конца запись доходит редко. Первая реакция — «перерисовать форму».
Эмпатия. Команда разговаривает с несколькими пациентами и сотрудниками регистратуры, наблюдает, как люди пытаются записаться. Выясняется: многие не знают, какой врач им нужен, — они знают только симптом. Другие уходят, когда их просят создать аккаунт.
Фокусировка. Проблема переформулируется с «форма некрасивая» на: пациенты, которые знают свой симптом, но не знают специалиста, не могут выбрать врача и уходят, не записавшись. Хорошая формулировка называет пользователя, потребность и препятствие, но не диктует решение.
Идеи. Команда превращает это в вопрос «Как мы можем помочь пациенту попасть к нужному врачу без медицинских знаний?». Варианты: выбор по симптому, короткая анкета-помощник, запись сначала на общую консультацию, заявка на обратный звонок, гостевая запись без регистрации.
Прототип. Две идеи собирают в кликабельные экраны: подбор по симптому и гостевую запись. Без кода — ровно столько детализации, сколько нужно для проверки.
Тест. Несколько человек из целевой аудитории проходят оба прототипа с реалистичным заданием: «Запишитесь на приём из-за боли в спине на этой неделе». Команда смотрит, где люди сомневаются. Например, подбор по симптому работает, но формулировки путают, а гостевая запись снимает серьёзный барьер. Следующая итерация дорабатывает оба решения.
Итоговое решение может совсем не походить на «красивую форму», с которой всё начиналось, — в этом и смысл.
Как метод применяют неправильно
- Театр воркшопов. День стикеров без единого реального пользователя. Без исследования эмпатия превращается в догадки.
- Пропуск фокусировки. Команда прыгает от интервью сразу к идеям и лечит симптом, а не проблему.
- Влюблённость в первую идею. Генерация нужна, чтобы сравнивать варианты; одна идея — это не выбор.
- Слишком вылизанные прототипы. Недели на детальный макет делают его жалко выбрасывать и замедляют обучение.
- Тест на коллегах. Коллеги слишком хорошо знают продукт. Тестируйте на людях из вашей аудитории.
- Восприятие как линейного процесса. Тест часто возвращает к фокусировке или идеям. Это успех, а не провал.
- Остановка на инсайтах. Дизайн-мышление должно заканчиваться решениями и изменениями в продукте, а не презентацией.
Когда метод стоит применять
Дизайн-мышление окупается, когда проблема неясна, поведение пользователей плохо изучено или цена ошибки высока: новые продукты, новые функции, редизайн ключевых сценариев. Для небольшого понятного изменения обычно хватает более лёгкого процесса.
Практичный минимум для большинства команд: поговорить с реальными пользователями, записать одну формулировку проблемы, набросать несколько вариантов и протестировать самый дешёвый прототип, который отвечает на ваш вопрос.