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

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

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

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

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

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

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