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

Дизайн-мышление vs классический инжиниринг: цели, логика и результаты

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

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

Что такое классический инжиниринг

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

Ключевая логика:

Требования и ограничения задаются в начале (пусть и уточняются по ходу).

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

Доказательство «правильности» — расчет, соответствие спецификациям, тесты по заранее заданным критериям.

Типичный ожидаемый результат:

Решение, соответствующее ТЗ, стандартам и метрикам качества.

Где особенно силен классический инжиниринг:

Безопасно-критичные системы (авиация, медтехника, энергетика).

Инфраструктурные платформы (СУБД, сети, компиляторы), где ценность часто определяется производительностью, надежностью и масштабируемостью.

Задачи, где проблема уже хорошо сформулирована и «пространство решений» ограничено.

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

Дизайн-мышление — это человеко-ориентированный подход к созданию решений, который помогает:

понять реальную задачу людей (а не только формально заявленную);

переопределить проблему (если выясняется, что исходная формулировка неверна);

быстро генерировать и проверять гипотезы через прототипы и тесты.

В инженерном контексте дизайн-мышление не заменяет расчеты, архитектуру и тестирование — оно снижает риск создать технически сильное, но невостребованное решение.

Ключевая логика:

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

Доказательство прогресса — обучение: подтвержденные/опровергнутые гипотезы о потребностях и поведении.

Решение развивается итеративно: «сделали → проверили → улучшили».

Полезная рамка, часто применяемая в дизайн-мышлении: баланс

желательности для пользователя;

осуществимости (технической реализуемости);

жизнеспособности для бизнеса.

Эти три фокуса — не «альтернатива инженерии», а расширение критериев успеха.

Этапы дизайн-мышления и их смысл для инженера

В курсе мы будем опираться на последовательность:

Эмпатия

Проблема

Идеация

Прототип

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

Итерация

Коротко о том, что именно добавляется по сравнению с привычной инженерной логикой:

Эмпатия — систематический сбор понимания контекста пользователя (наблюдения, интервью, анализ сценариев). Это уменьшает риск неверных требований.

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

Идеация — расширение пространства решений до того, как команда «влюбится» в первую технически красивую идею.

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

Тестирование — проверки не только корректности, но и понятности, удобства, доверия, готовности использовать.

Итерация — осознанный цикл улучшений на основе данных и наблюдений.

!Сравнение линейного инженерного процесса и итеративной логики дизайн-мышления

Главное отличие: цели

Инжиниринг чаще оптимизирует известную задачу:

повысить производительность на X;

обеспечить надежность Y;

уложиться в ограничения по стоимости и времени;

соответствовать стандартам.

Дизайн-мышление чаще проясняет что именно стоит оптимизировать:

какую задачу пользователь пытается решить;

почему текущее решение не подходит;

какие альтернативы уже существуют;

какие компромиссы для пользователя приемлемы.

Если упростить:

Классический инжиниринг отвечает на вопрос: как сделать.

Дизайн-мышление отвечает на вопрос: что именно делать и зачем.

Отличие: логика принятия решений

Ниже — практичное сравнение того, как разные подходы «думают».

| Измерение | Классический инжиниринг | Дизайн-мышление | |---|---|---| | Старт | Требования, спецификации, ограничения | Наблюдение за людьми, контекст, неопределенность | | Тип задачи | Хорошо определенная | Часто плохо определенная, может быть неверно сформулирована | | Основной риск | Технический провал, дефекты, превышение сроков/бюджета | Создать невостребованный продукт или неправильную функцию | | Основная валюта прогресса | Реализация по плану, покрытие тестами, метрики качества | Проверенные гипотезы, инсайты, подтвержденные потребности | | Решения выбираются по | Оптимальности по метрикам (скорость, надежность, стоимость) | Ценности для пользователя + реализуемости + жизнеспособности | | Прототипирование | Часто ближе к поздним этапам (перед внедрением) | Рано и часто, чтобы учиться дешевле | | Успех | Соответствие спецификации и качеству | Используемость, принятие, ценность, рост/эффект |

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

Отличие: результаты, которые вы приносите бизнесу и пользователю

Ожидаемые результаты классического инжиниринга:

стабильность и масштабирование;

снижение затрат (оптимизации, автоматизация);

выполнение нормативных требований;

предсказуемость поставки.

Ожидаемые результаты дизайн-мышления:

более точное попадание в потребности;

обнаружение скрытых ограничений и «болей»;

снижение потерь от разработки «не того»;

ускорение обучения команды (через итерации).

Практическая формулировка для инженера:

Инжиниринг уменьшает риск некачественно сделать.

Дизайн-мышление уменьшает риск сделать не то.

Обзор методологий: d.school, IDEO, Double Diamond

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

Stanford d.school

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

Источник: Getting Started with Design Thinking

IDEO

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

Источник: IDEO — Design Thinking

Double Diamond

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

Источник: Design Council — Double Diamond

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

Как дизайн-мышление влияет на инженерные инновации: три ориентира

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

Apple: инженерия опыта, а не только функций

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

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

Источник: Apple Human Interface Guidelines

Tesla: итерации в продукте после поставки

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

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

Источник: Tesla — Master Plan, Part Deux

Toyota: «пойти и посмотреть» как фундамент понимания проблемы

Культура Toyota Production System включает принципы непрерывного улучшения и подход genchi genbutsu — «иди и смотри на месте», чтобы понять реальную ситуацию. В терминах дизайн-мышления это близко к эмпатии и проверке предположений фактами.

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

Источник: Toyota — Toyota Production System

Как инженеру объединять оба подхода

Рабочая стратегия для большинства команд — не выбирать «или/или», а использовать дизайн-мышление там, где оно дает максимальный эффект.

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

Новая функция или продукт, где неизвестно, что станет ценностью.

Жалобы пользователей есть, но причина неясна.

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

Требования противоречивы, и стейкхолдеры не согласны, что важно.

Когда доминирует классический инжиниринг:

Понятные требования и жесткие стандарты.

Задачи надежности, безопасности, производительности, соответствия регуляторике.

Оптимизации и масштабирование, где критерии успеха измеримы и согласованы.

Практическая «сшивка»:

Начинайте с эмпатии и формулировки проблемы, чтобы получить правильные требования.

Дальше применяйте инженерные практики (архитектура, тестирование, CI/CD, верификация), чтобы обеспечить правильную реализацию.

Возвращайтесь к пользователю на тестах — даже если вы строите сложную систему без «красивого интерфейса» (у любой системы есть оператор, администратор, интегратор).

Итоги

Классический инжиниринг сильнее в оптимизации и надежной реализации при относительно ясной постановке задачи.

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

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

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

Этап 1: эмпатия и исследование пользователей в инженерном контексте

В предыдущей статье мы разделили две логики:

классический инжиниринг снижает риск некачественно сделать

дизайн-мышление снижает риск сделать не то

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

Что такое эмпатия для инженера

В дизайн-мышлении эмпатия — это не «сочувствие» и не попытка угадать чувства. Это дисциплина исследования, где команда:

наблюдает реальное поведение

задает вопросы про контекст и ограничения

проверяет свои предположения

фиксирует факты, цитаты и конкретные ситуации

В инженерном контексте эмпатия особенно важна, потому что пользователи часто работают:

в условиях времени, шума, усталости, многозадачности

с ограниченными правами доступа и регламентами

через сложные цепочки инструментов и интеграций

с высокой ценой ошибки

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

Кто такой пользователь в инженерных продуктах

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

Конечный пользователь: выполняет работу в интерфейсе или через API

Оператор: следит за системой и реагирует на инциденты

Администратор: настраивает доступы, политики, параметры

Интегратор: подключает к другим системам, пишет скрипты, автоматизацию

Закупщик или владелец бюджета: принимает решение о покупке

Комплаенс или безопасность: вводит запреты и требования

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

!Карта ролей вокруг инженерного продукта, показывающая что "пользователь" — это несколько разных стейкхолдеров

Цели эмпатии: чему именно вы хотите научиться

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

В каком сценарии возникает проблема и как часто

Как пользователь понимает задачу и по каким сигналам оценивает успех

Какие обходные пути и костыли уже используются

Какие ограничения среды важнее всего (скорость, безопасность, регламент, доступы)

Что вызывает недоверие к системе (страх поломать, непредсказуемость, отсутствие обратимости)

Эти ответы станут входом для следующего этапа курса: формулировки проблемы.

Основные методы исследования, которые реально работают у инженеров

Интервью о реальном опыте

Цель — собрать конкретные истории, а не абстрактные мнения.

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

Уточняйте шаги, артефакты, инструменты, людей, решения

Фиксируйте цитаты и факты, а не интерпретации

Хороший практический ориентир от Nielsen Norman Group: интервью работают лучше всего, когда вы углубляетесь в прошлые события и конкретные действия.

Ссылка: User Interviews: How, When, and Why to Conduct Them

Наблюдение и контекстное исследование

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

Смотрите, как работа делается в реальности

Отмечайте прерывания, ручные проверки, копипаст, листочки, чат-рутины

Фиксируйте не только действия, но и причины: почему так делают

Эта логика близка принципу Toyota genchi genbutsu — «пойти и увидеть на месте», чтобы понять реальную ситуацию.

Ссылка: Toyota Production System

Дополнительный ориентир по методу контекстного исследования: Contextual Inquiry

Анализ следов поведения

Когда «поле» недоступно, полезно извлекать эмпатию из следов реальной работы.

Тикеты поддержки и расшифровки звонков

Логи ошибок и причины откатов

Запросы в чатах эксплуатации

Документация, которую пишут сами пользователи

Ограничение: следы показывают где болит, но не всегда объясняют почему и что мешает.

Дневники и самонаблюдение

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

Участники фиксируют событие, цель, шаги, сложности, обходные пути

Команда получает контекст и примеры, которые иначе бы не увидела

Опросы как вспомогательный инструмент

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

насколько распространен сценарий

какие сегменты сталкиваются с проблемой чаще

какие альтернативы используют

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

Как подготовить исследование: минимальный план

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

Опишите решение или область, где есть неопределенность

Сформулируйте 5–10 вопросов обучения

Определите роли пользователей, которых нужно покрыть

Выберите методы и каналы доступа к людям

Подготовьте сценарий интервью или план наблюдения

Решите, как фиксируете данные (заметки, аудио с согласия, шаблон)

Запланируйте синтез: когда и как превращаете сырье в выводы

Практический ориентир по человеко-ориентированному процессу (включая исследование пользователей) дан в стандарте: ISO 9241-210:2019 Human-centred design for interactive systems

Как проводить интервью, чтобы получить инженерно-полезные данные

Структура интервью

Разогрев: роль, контекст, как устроен день

Последний реальный кейс: «расскажите про последний раз, когда…»

Разбор шагов: что было дальше, чем пользовались, где сомневались

Проверка альтернатив: как иначе решают, что пробовали

Завершение: что было бы «идеально», что нельзя менять

Примеры удачных вопросов

«Вспомните последний раз, когда система подвела. Что вы сделали первым?»

«Какие проверки вы делаете вручную, хотя система могла бы сделать сама?»

«В какой момент вы понимаете, что можно доверять результату?»

«Что для вас хуже: сделать медленно или ошибиться?»

Примеры вопросов, которые ломают исследование

«Вам нравится новая функция?»

«Если мы добавим X, будет удобнее?»

«Какую кнопку вы хотите видеть?»

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

Фиксация и синтез: как превратить разговоры в артефакты

Эмпатия дает пользу только если команда может перенести наблюдения в следующую стадию.

Полезные артефакты после 5–10 качественных контактов:

Список повторяющихся задач и сценариев

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

Список «болей» в формулировке наблюдений: что происходит и где ломается

Цитаты, которые точно отражают мотивацию или страх

Карта пути пользователя в одном ключевом сценарии (шаги и точки риска)

Важно: не пытайтесь «доказать» выводы статистикой на этом шаге. Цель эмпатии — расширить понимание и собрать материал для правильной постановки задачи.

Типичные ошибки инженерных команд на этапе эмпатии

Решать задачу в голове во время интервью

Интервьюировать только доступных коллег, а не реальных пользователей

Подменять исследование обсуждением фич

Считать, что телеметрия заменяет разговор и наблюдение

Игнорировать роли эксплуатации и поддержки

Делать выводы по одному яркому кейсу без повторяемости

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

Эмпатия в ограниченных условиях: безопасность, регуляторика, закрытые системы

В некоторых доменах нельзя просто «посадить дизайнера рядом с оператором».

Рабочие компромиссы:

Наблюдение в симуляторе или на учебном контуре

Интервью с разбором артефактов: логи, инструкции, чек-листы

Ролевые walkthrough: пользователь ведет вас по шагам на обезличенных данных

Анализ инцидентов: хронология, точки принятия решений, потери времени

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

Итоги

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

«Пользователь» почти всегда состоит из нескольких ролей, и их нужно различать.

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

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

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

Этап 2: формулировка проблемы и критериев успеха (Problem Statement)

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

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

Зачем инженеру отдельный этап «Проблема»

В классическом инжиниринге задача часто приходит как ТЗ. В дизайн-мышлении задача еще не доказана: ее нужно уточнить, сузить, иногда переопределить.

Этот этап снижает три типовых инженерных риска.

Решить симптом вместо причины

Оптимизировать локальную метрику и ухудшить систему в целом

Сделать улучшение, которое «логично», но не будет принято пользователями

Практический результат этапа: Problem Statement + критерии успеха, которые становятся входом в идеацию, прототипирование и тестирование.

!Как эмпатия превращается в четкую постановку задачи и критерии успеха

Что такое Problem Statement

Problem Statement — короткая формулировка, которая фиксирует:

пользователя или роль

контекст, где возникает проблема

наблюдаемую трудность (что именно ломается в реальной работе)

последствие для пользователя, системы или бизнеса

критерий улучшения (как заметим прогресс)

Важно: это не список решений и не список фич.

Минимальный шаблон

Ниже — шаблон, который хорошо ложится на инженерные продукты.

Для кого: роль пользователя

Когда: контекст и триггер

Проблема: наблюдаемая трудность

Потому что: ключевая причина или ограничение (гипотеза)

В итоге: ущерб или риск

Успех будет, если: измеримый или наблюдаемый критерий

Пример (B2B-инструмент для эксплуатации)

Для кого: дежурный SRE

Когда: ночью при расследовании инцидента

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

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

В итоге: растет MTTR и увеличивается вероятность ошибочного отката

Успех будет, если: дежурный за первые 10 минут может восстановить цепочку изменений и выбрать безопасное действие

Как перейти от эмпатии к формулировке проблемы

Этап эмпатии дает факты и истории. Этап проблемы требует синтеза.

Синтез: от заметок к «паттернам»

Рабочий минимум для команды:

Соберите все наблюдения в единый список: цитаты, факты, шаги сценария, артефакты (логи, формы, инструкции).

Сгруппируйте похожие наблюдения (например, по шагам сценария или по типу затруднений).

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

Отметьте повторяемость: что встречается у нескольких людей или в нескольких источниках (интервью + тикеты + логи).

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

Полезный принцип: на этом шаге не спорьте о том, как исправить. Спорьте о том, что именно происходит.

От симптома к причине: «5 почему»

Инженерные команды любят искать root cause, но часто начинают с технической причины (например, «медленный запрос»), пропуская пользовательскую.

Метод 5 Why помогает пройти цепочку «симптом → механизм → контекст → истинная потребность».

Пример мини-цепочки:

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

Почему замедляет? Потому что сканер запускается на каждый коммит.

Почему запускается на каждый? Потому что политика одна для всех репозиториев.

Почему политика одна? Потому что нет сегментации по риску и критичности.

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

Тогда Problem Statement будет не про «ускорить сканер», а про «сделать политику контроля понятной, дифференцированной и принятой», где скорость — лишь часть критериев.

Источник по методу: ASQ: Five Whys

Причины и факторы: диаграмма Исикавы

Когда факторов много (люди, процессы, инструменты, среда), помогает диаграмма причинно-следственных связей.

Источник: ASQ: Fishbone Diagram

Полезные форматы формулировки проблемы

Один формат редко подходит всем. Ниже — несколько «оберток» вокруг одной и той же сути.

POV: «пользователь + потребность + инсайт»

Формат POV (Point of View) удерживает фокус на человеке и контексте.

| Часть | Что это | Пример формулировки | |---|---|---| | Пользователь | конкретная роль | интегратор, который подключает API к ERP | | Потребность | что нужно сделать в работе | быстро понимать, почему запросы отклоняются | | Инсайт | почему текущий мир мешает | ошибки не объясняют, на каком шаге нарушено условие, и приходится гадать |

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

HMW: «How Might We» как мост к идеации

Формат How Might We полезен, когда проблема уже ясна, и вы хотите открыть пространство решений, не нарушив рамки.

Примеры:

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

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

Правило качества: HMW не должен содержать конкретное решение (например, «как мы можем добавить кнопку»), но должен сохранять контекст и ограничения.

JTBD: «работа, которую человек пытается выполнить»

Подход Jobs To Be Done помогает не путать «пользователя продукта» с «задачей пользователя».

Шаблон:

Когда ситуация, я хочу мотивация/действие, чтобы ожидаемый результат.

Пример:

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

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

Справка: Wikipedia: Jobs-to-be-done

Критерии успеха: как понять, что проблема решена

Problem Statement без критериев успеха приводит к бесконечным спорам «нравится/не нравится» и к оптимизациям не того.

Критерии успеха удобно фиксировать тремя слоями.

Поведенческие сигналы

Это наблюдаемое поведение, которое должно измениться.

Пользователь перестает делать ручную сверку в таблице

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

Новичок выполняет сценарий без подсказок старшего коллеги

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

Продуктовые и процессные метрики

Метрики нужны, чтобы итерации были управляемыми. Но метрика должна быть привязана к Problem Statement.

Примеры (выбирайте те, что соответствуют вашей проблеме):

Время выполнения ключевого сценария

Доля сценариев, завершенных без ошибки

Количество обращений в поддержку по конкретному классу проблем

MTTR или время диагностики до первого корректного действия

Доля откатов из-за неверной диагностики

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

Ограничения и «не ухудшить»

Инженерные решения часто улучшают одно ценой другого. Поэтому критерии успеха должны содержать ограничения.

Примеры:

Не ухудшить безопасность и соответствие политикам

Не увеличить когнитивную нагрузку для новичков

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

Сохранить обратимость действий (возможность отката)

Как формулировать проблему так, чтобы она была инженерно-проверяемой

Ниже — признаки хорошей постановки.

Проблема описывает наблюдаемую трудность, а не оценку («пользователи тупят» — не наблюдение).

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

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

Нет «встроенного решения».

Критерии успеха можно проверить: в тесте, пилоте, по логам, по тикетам.

Таблица: плохая и хорошая формулировка

| Плохая формулировка | Почему плохо | Лучше | |---|---|---| | Нужно сделать интерфейс удобнее | нет роли, контекста, признака успеха | Оператор при пике тревог не успевает отличить критичные алерты от шума и тратит время на ложные срабатывания; успех: доля ложных эскалаций падает, время до первого действия сокращается | | Добавить экспорт в CSV | встроенное решение | Интегратор не может быстро перенести данные в свою систему учета без ручного копирования; успех: перенос занимает меньше 5 минут и не требует ручной правки | | Ускорить систему | непонятно, что именно и для кого | При построении отчета за сутки аналитик ждет 3–5 минут и теряет контекст задачи; успех: отчет строится за приемлемое время при сохранении точности |

Согласование проблемы со стейкхолдерами

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

Минимальный набор того, что стоит согласовать письменно:

Роли пользователей в фокусе и не в фокусе

Сценарий, который улучшаем в первую очередь

Критерии успеха и ограничения

Что не делаем в этой итерации

Практика, которая экономит недели: формулировка in-scope / out-of-scope рядом с Problem Statement.

Выходные артефакты этапа

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

Problem Statement в 3–6 предложениях

3–7 критериев успеха, включая ограничения

Список допущений и рисков (что пока не доказано)

2–5 формулировок HMW для генерации идей

Итоги

Этап Проблема превращает эмпатию в четкую постановку задачи и критерии успеха.

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

Методы вроде 5 Why и диаграммы Исикавы помогают не застрять на симптомах.

Критерии успеха лучше задавать слоями: поведение → метрики → ограничения.

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

Этап 3: идеация — генерация решений и отбор инженерно реализуемых идей

После эмпатии и формулировки Problem Statement команда наконец получает право придумывать решения. Но в инженерной среде идеация часто ломается двумя крайностями:

команда слишком рано «схлопывается» в одно технически красивое решение

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

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

Входные данные идеации

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

Problem Statement с ролью, контекстом, наблюдаемой трудностью и последствиями

критерии успеха, включая ограничения «не ухудшить»

2–5 формулировок HMW (How Might We), которые открывают пространство решений

ключевые инсайты эмпатии: цитаты, обходные пути, причины недоверия, ограничения среды

Если этих артефактов нет, идеация почти неизбежно превращается в «давайте добавим фичу».

Две фазы идеации: дивергенция и конвергенция

Практический смысл этапа — сначала расширить, потом осознанно сузить.

Дивергенция: быстро создать много разных подходов, не оценивая их преждевременно

Конвергенция: выбрать несколько сильных направлений и превратить их в кандидаты на прототипирование

!Схема ритма идеации: расширение вариантов и последующий осознанный отбор

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

Правила хорошей инженерной идеации

Идеи рождаются быстрее, когда оценка отделена по времени от генерации

Хорошая идея обязана отвечать на Problem Statement, а не на «как бы нам встроить технологию X»

Вариативность должна включать не только интерфейс, но и процессы, данные, интеграции, обратимость и наблюдаемость

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

Подготовка сессии идеации

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

Зафиксируйте Problem Statement и критерии успеха в одном месте, чтобы к ним можно было возвращаться.

Выберите одну HMW-формулировку на 10–20 минут работы, а не «всё сразу».

Определите участников так, чтобы были покрыты ключевые ограничения.

Договоритесь о типе результата.

Полезный минимум ролей в инженерной идеации:

инженер(ы) платформы или архитектуры

представитель эксплуатации или поддержки

продукт или бизнес-стейкхолдер

исследователь или тот, кто проводил эмпатию

Техники генерации идей, которые хорошо работают у инженеров

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

Brainwriting вместо «громкого брейншторма»

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

снижает эффект доминирования старших и экстравертов

дает больше идей за то же время

сохраняет след рассуждений

Справка: Brainwriting

Crazy 8s для быстрых вариантов

Участник делает 8 быстрых набросков решений за ограниченное время. Смысл не в красоте, а в принуждении к вариативности.

позволяет уйти от первой очевидной идеи

хорошо подходит для интерфейсов, но применим и к потокам действий

Справка: Crazy 8s

SCAMPER для «переворачивания» решения

SCAMPER — набор глаголов, которые заставляют менять перспективу: Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse.

помогает улучшать существующие процессы и инструменты

полезен при модернизации сложных систем, где «полностью новый продукт» невозможен

Справка: SCAMPER

Морфологическая матрица для системных вариантов

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

Пример параметров для «объяснимых ошибок API»:

где формируется ошибка: шлюз, сервис, контракт, схема данных

n- формат объяснения: код, человекочитаемое сообщение, ссылка на документацию, пример корректного запроса

момент обратной связи: синхронно, асинхронно, в песочнице

Справка: Morphological analysis

TRIZ как источник направлений, когда «всё уперлось в противоречие»

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

Справка: TRIZ

Как расширять пространство решений, не теряя связь с реальностью

Хороший прием — генерировать идеи в нескольких «слоях», потому что в инженерных продуктах ценность часто создается не одной фичей.

интерфейс и UX: что человек видит и делает

процесс: какие шаги исчезают, какие упрощаются, какие автоматизируются

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

интеграции: где решение встраивается в существующую цепочку инструментов

надежность и безопасность: как обеспечиваются права, аудит, обратимость

наблюдаемость: как пользователь и команда понимают, что происходит

Если идеи лежат только в одном слое, команда рискует «косметикой» не решить корневую проблему.

Конвергенция: как отбирать идеи так, чтобы они были инженерно реализуемыми

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

Шаг кластеризации

сгруппируйте идеи по смыслу, не по авторам

дайте каждому кластеру название языком проблемы, а не решения

выберите 3–6 кластеров для дальнейшей оценки

Оценка по трем измерениям

Используйте язык из первой статьи курса: желательность, осуществимость, жизнеспособность.

| Измерение | Вопрос | Инженерные маркеры | |---|---|---| | Желательность | Будут ли этим пользоваться в реальном контексте? | снижает ручной труд, уменьшает риск ошибки, повышает доверие | | Осуществимость | Реально ли построить в ограничениях? | архитектура, безопасность, данные, производительность, сроки | | Жизнеспособность | Оправдано ли для бизнеса и поддержки? | стоимость владения, нагрузка на поддержку, соответствие стратегии |

Важно: на этом этапе вы не ищете «идеальную идею». Вы ищете 2–3 кандидата, которые стоит прототипировать, чтобы быстро научиться.

Быстрый фильтр инженерной реализуемости

Для каждого кластера идей ответьте коротко.

Какие зависимости и интеграции потребуются?

Какие данные нужны, и есть ли они?

Есть ли требования безопасности, аудита, регуляторики?

Где будут основные риски отказа и как их наблюдать?

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

Если на любой вопрос ответа нет, это не повод выкидывать идею. Это повод превратить неизвестность в гипотезу для проверки.

Матрица «ценность для пользователя vs риск/неизвестность»

Инженерной команде полезно отделять сложность реализации от неизвестности.

Сложность: объем работ понятен, просто много задач

Неизвестность: вы не уверены, что это сработает технически или будет принято пользователями

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

Превращение идеи в концепцию для прототипирования

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

Короткое описание: что меняется в мире пользователя.

Для кого и в каком сценарии работает.

Какая гипотеза проверяется.

Что будет прототипом: интерфейс, симуляция, скрипт, демо-стенд, «фейковая» интеграция.

Как меряем успех: поведенческие сигналы и ограничения из Problem Statement.

Пример перехода от идеи к проверке:

Идея: «единая временная линия событий для расследования инцидентов»

Гипотеза: «если дежурный видит деплой, фича-флаг и алерты на одной шкале времени, он быстрее выбирает корректное действие»

Прототип: кликабельный макет + подложенные реальные события из одного инцидента

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

Типичные ошибки на этапе идеации у инженерных команд

Начать оценивать идеи во время генерации и «задушить» дивергенцию

Заменить идеи обсуждением архитектуры без связи с Problem Statement

Выбрать «самое простое» и игнорировать ценность для пользователя

Выбрать «самое умное» и игнорировать ограничения эксплуатации и поддержки

Принять решение голосованием без явных критериев успеха и ограничений

Выходные артефакты этапа

К концу идеации у команды должен быть набор, который прямо ведет в прототипирование.

2–3 выбранные концепции решений

для каждой концепции: гипотеза, ключевые допущения, риски

план прототипа: что именно делаем, чтобы проверить самое важное дешевле всего

список вопросов для тестирования с пользователями

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

Этап 4: прототипирование — быстро, дешево, проверяемо

После эмпатии, Problem Statement и идеации у команды появляется 2–3 концепции решений. Следующий риск типично инженерный: слишком рано перейти к «правильной реализации» и потратить недели на код, прежде чем выяснится, что:

пользователи не понимают, как этим пользоваться

решение не вписывается в реальный процесс

ключевая гипотеза ценности не подтверждается

важное ограничение (безопасность, права, аудит, обратимость) ломает идею

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

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

Прототип — это намеренно неполная версия решения, созданная для проверки конкретной гипотезы в заданном сценарии.

Важно отличать прототип от похожих инженерных артефактов.

| Артефакт | Зачем делают | Главный вопрос | Типичный риск | |---|---|---|---| | Прототип | Проверить гипотезу о ценности/понятности/вписывании в процесс | Поймут ли, захотят ли, смогут ли использовать? | слишком «красивый», но ничего не проверяет | | POC (proof of concept) | Доказать техническую осуществимость | Можем ли мы это вообще сделать? | доказали технику, не доказали пользу | | MVP | Минимальный продукт для рынка/эксплуатации | Есть ли устойчивый спрос и эффект? | сделали «минимальный», но дорогой в поддержке |

Прототип может включать код, но цель кода здесь не «доставить фичу», а извлечь знание.

Справка: Prototype

Принцип этапа: проверяйте самое рискованное допущение

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

Типовые классы допущений в инженерных продуктах:

ценность: это действительно снимает боль из Problem Statement

понятность: пользователь правильно интерпретирует состояние системы и следующий шаг

доверие: пользователь готов полагаться на результат (особенно в рискованных действиях)

вписывание в процесс: решение попадает в нужный момент и не ломает регламент

данные: нужные данные существуют и их можно корректно связать

операционность: можно безопасно поддерживать, диагностировать, откатывать

!Схема показывает, что прототип — это мост от допущений к наблюдаемым сигналам

Из чего состоит хороший прототип

Чтобы прототип был проверяемым, у него должна быть структура.

Гипотеза

Сценарий (в каком контексте проверяем)

Задача для пользователя (что он должен сделать)

Артефакт прототипа (макет, скрипт, демо, симуляция)

Сигналы успеха (что наблюдаем)

Ограничения (что нельзя ухудшить из критериев успеха)

Пример формулировки (по мотивам Problem Statement из предыдущей статьи):

Гипотеза: единая временная линия «деплой → фича-флаги → алерты → метрики» снизит время до первого обоснованного действия у дежурного.

Сценарий: ночное расследование инцидента.

Задача: определить вероятную причину деградации и выбрать действие.

Прототип: кликабельный макет + подложенные события одного реального инцидента.

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

Ограничения: не ухудшить безопасность и обратимость действий.

Верность прототипа: «достаточно реалистично, чтобы проверить гипотезу»

У прототипа есть верность (иногда говорят fidelity): насколько он похож на будущий продукт. В инженерных задачах полезно разложить верность на компоненты.

визуальная: похоже ли на будущий UI

функциональная: выполняется ли часть логики

данные: похожи ли данные на реальные по структуре и качеству

интеграции: есть ли настоящие вызовы систем (или моки)

операционность: можно ли наблюдать, дебажить, безопасно откатывать

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

!Матрица помогает выбирать, что прототипировать в первую очередь

Типы прототипов, полезные инженерам

Выбор типа прототипа зависит от того, что именно вы проверяете.

Прототипы для проверки понятности и потока действий

бумажный набросок или схема экранов

кликабельный макет

интерактивная демонстрация без реальной логики

Такие прототипы быстро выявляют:

где пользователь ожидает увидеть информацию

какие термины и статусы интерпретируются неверно

где нужен «следующий шаг» и обратимость

Прототипы для проверки данных и объяснимости

прототип отчета на «подложенных» данных из реального кейса

симуляция (например, генерация событий и построение временной линии)

«полуфейковая» аналитика: часть вычислений настоящая, часть — зашита

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

Wizard of Oz и Concierge как способ быстро проверить ценность

Wizard of Oz прототип — пользователь думает, что система автоматизирована, но часть работы делает человек «за кулисами». Это уместно, когда автоматизация дорогая, а ценность и формат взаимодействия еще не доказаны.

Справка: Wizard of Oz experiment

Пример (инженерный B2B): вы хотите «умные рекомендации действий при инциденте». Прототип может выглядеть как UI, где «рекомендация» появляется по нажатию кнопки, но в пилоте ее формирует дежурный эксперт по заранее заданному чек-листу. Вы проверяете:

используют ли рекомендацию

как формулировка влияет на доверие

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

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

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

мок-сервер и контракт API

«фейковая» интеграция через файл/очередь сообщений

прототип в песочнице с ограниченной областью данных

Здесь цель — проверить ключевые вопросы:

где возникают несовместимости контрактов

какие поля реально нужны

какие ошибки должны быть объяснимыми

как организовать безопасную обратимость

Как инженеру сделать прототип безопасным

В инженерных доменах прототип иногда попадает в среду с реальными рисками. Поэтому даже «быстрый» артефакт должен учитывать базовые защитные рамки.

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

Явные ограничения: сообщите пользователю, что это прототип и где он «врет».

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

Аудит и доступы: не обходите политики безопасности ради скорости.

Если безопасность не позволяет тестировать «в поле», прототипируйте через:

разбор реальных кейсов на данных инцидентов (без доступа к прод)

walkthrough по шагам с записью экрана

симуляции и проигрывание сценариев на стенде

Прототип как план эксперимента: что фиксировать до тестирования

Чтобы следующий этап (тестирование) не превратился в «ну вроде норм», зафиксируйте минимум до встречи с пользователями.

Какая гипотеза проверяется (одна главная на прототип).

Какие вопросы должны получить ответ.

Какие сигналы вы считаете успехом.

Какие сигналы считаются провалом.

Какие ограничения нельзя нарушить.

Пример сигналов (без сложной аналитики):

пользователь проходит сценарий без подсказок

пользователь выбирает корректное действие и может объяснить почему

количество «остановок» и вопросов снижается

пользователь не делает опасных ошибок из-за неверной интерпретации статусов

Типичные ошибки прототипирования у инженерных команд

Делать прототип как «почти готовый продукт» и сжигать бюджет до обучения.

Прототипировать то, что и так понятно (низкий риск), игнорируя рискованные допущения.

Смешивать в одном прототипе слишком много гипотез, из-за чего непонятно, что именно сработало.

Прятать ограничения прототипа и получать ложное доверие.

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

Выход этапа

К концу прототипирования у вас должно получиться то, что напрямую ведет в тестирование.

1–2 прототипа на каждую выбранную концепцию (часто один прототип на одну ключевую гипотезу)

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

список того, что прототип не проверяет (чтобы не переоценить результаты)

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

Этап 5–6: тестирование и итерация — обратная связь как двигатель улучшений

На предыдущих этапах курса вы сделали самое важное для инженерной инновации:

на этапе эмпатии собрали реальные сценарии, ограничения и причины недоверия

на этапе формулировки проблемы зафиксировали Problem Statement и критерии успеха

на этапе идеации превратили проблему в несколько концепций решений

на этапе прототипирования создали артефакты, которые проверяют ключевые допущения дешево

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

Этапы тестирование и итерация превращают прототипы в знания и изменения: вы получаете наблюдаемую обратную связь, принимаете решение и обновляете Problem Statement, концепцию или прототип.

!Цикл обучения через тестирование и итерации

Что такое тестирование в дизайн-мышлении (и чем оно не является)

Тестирование в дизайн-мышлении — это проверка гипотез о том, что решение:

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

снимает боль из Problem Statement

вписывается в процесс, регламент и ограничения

не ломает важные ограничения (безопасность, обратимость, нагрузка на эксплуатацию)

Важно различать тестирование в дизайн-мышлении и привычные инженерные проверки.

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

Если сказать кратко: QA отвечает на вопрос правильно ли реализовали, а тестирование в дизайн-мышлении — то ли реализуем и как это улучшить.

Практический ориентир по тому, как проводить качественное тестирование с пользователями: Nielsen Norman Group — Usability Testing 101.

Подготовка: что должно быть определено до теста

Тестирование дает пользу только если оно привязано к гипотезам и критериям успеха из этапа Проблема.

Минимальный комплект, который стоит зафиксировать письменно.

Гипотеза

Сценарий (контекст из эмпатии)

Задачи для участника (что он должен попытаться сделать)

Сигналы успеха и провала (наблюдаемое поведение)

Ограничения (что нельзя ухудшить)

Что именно тест не проверяет (чтобы не сделать ложных выводов)

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

Если дежурный видит единую временную линию «деплой → фича-флаги → алерты → метрики», то он быстрее выбирает первое обоснованное действие и реже делает опасные шаги наугад.

Такая гипотеза не обещает «всем стало удобно», а задает наблюдаемое изменение в конкретном сценарии.

Кого тестировать: роли важнее количества

В инженерных продуктах один «пользователь» почти всегда распадается на роли (вы уже видели это на этапе эмпатии). Для тестирования это критично: разные роли по-разному понимают риски, ценность и допустимые компромиссы.

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

Типовые роли для инженерного B2B/инфраструктурного продукта:

конечный пользователь

оператор эксплуатации

администратор (доступы, политики)

интегратор (API, скрипты)

Если вы тестируете только одну роль, зафиксируйте это как ограничение вывода.

Форматы тестирования, которые чаще всего полезны инженерам

Модерируемое тестирование сценария

Модерируемое означает, что ведущий задает задачи и наблюдает, но не учит.

Подходит, когда вы проверяете:

понятность статусов и терминов

правильность следующего шага

доверие к данным и рекомендациям

Базовая техника — думай вслух (участник проговаривает, что он пытается сделать и почему). Это снижает риск неверной интерпретации наблюдений. Справка: Wikipedia — Think-aloud protocol.

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

Когда прототип еще грубый, можно проверить саму идею:

понимает ли пользователь ценность

не противоречит ли это его процессу

какие условия нужны, чтобы он доверял результату

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

Пилот в ограниченной среде

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

Полезен, когда нужно проверить:

реальную частоту использования

интеграционные и операционные риски

появление неожиданных сценариев

Для инженерных систем пилот часто безопаснее проводить через:

песочницу

обезличенные данные

ограниченные права

явную обратимость (возможность отката)

Эксперимент в продукте (A/B тест)

A/B тест — сравнение двух вариантов поведения системы на разных группах пользователей. Он полезен, когда у вас уже есть стабильный продукт и понятная метрика. Справка: Wikipedia — A/B testing.

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

Сценарий теста: как не скатиться в сбор мнений

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

Как формулировать задания

давайте участнику цель, а не инструкцию

привязывайте цель к реальному триггеру из эмпатии

избегайте подсказок терминов, которые вы хотите проверить

Примеры хороших заданий:

У вас деградация сервиса после деплоя. Покажите, что вы сделаете в первые 10 минут и почему.

Запрос к API отклонен. Попробуйте понять причину и исправить запрос так, чтобы он прошел.

Примеры плохих заданий:

Найдите кнопку экспорта и нажмите ее.

Вам удобно, что ошибка теперь справа?

Какие данные собирать: сигналы сильнее мнений

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

Наблюдаемые сигналы (предпочтительно)

время до первого обоснованного действия

количество возвратов назад и переключений контекстов

места, где участник останавливается и ищет подтверждение

ошибки интерпретации статуса (опасные особенно)

необходимость обращаться к документации или к более опытному коллеге

Вербальная обратная связь (вторично)

Высказывания важны, но их нужно привязывать к поведению.

Что вы ожидали увидеть?

Почему вы не доверяете этому выводу?

По каким признакам вы решаете, что действие безопасно?

Практичный прием: фиксируйте цитату только вместе с контекстом что человек делал в этот момент.

!Шаблон протокола наблюдений, который сразу превращается в задачи итерации

Разбор результатов: как превращать наблюдения в решения

После 5–8 сессий тестирования (или после пилота) у вас обычно появляется набор повторяющихся проблем. Дальше важно отделить симптомы от причин.

Полезный минимальный процесс.

Соберите наблюдения в единый список

Сгруппируйте по паттернам

Для каждого паттерна сформулируйте предполагаемую причину

Свяжите паттерн с критерием успеха из Problem Statement

Примите решение: что меняем в следующей итерации

Чтобы решения не превратились в спор «мне кажется», используйте простую таблицу приоритизации.

| Паттерн проблемы | Насколько это мешает сценарию | Насколько часто повторяется | Риск (ошибка, безопасность, деньги) | Что меняем | |---|---|---|---|---| | Неверно читают статус | высоко | часто | высокий | переименовать, добавить объяснение и пример | | Не видят следующий шаг | средне | часто | средний | добавить явный CTA и безопасный дефолт | | Не доверяют рекомендации | высоко | иногда | высокий | показать источники данных и условия применимости |

Итерация: что именно может измениться

Итерация — это не только «улучшить UI». В инженерных продуктах изменения часто лежат в других слоях.

формулировка проблемы (иногда тест показывает, что вы решали не то)

критерии успеха (иногда выясняется, что метрика была неверным прокси)

поток действий (процесс пользователя)

данные и связность событий (что нужно объединить или сделать объяснимым)

права доступа, аудит, обратимость

документация и обучающие подсказки

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

Три исхода итерации

Упорствовать: гипотеза подтверждается, улучшаем детали и идем к более реалистичному прототипу или MVP

Повернуть: проблема верна, но выбранное решение не работает; возвращаемся к идеации или меняем концепцию

Остановиться: ценности нет или ограничения делают решение нецелесообразным

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

Как встроить итерации в инженерный жизненный цикл

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

Техники, которые помогают делать итерации безопасно:

фича-флаги (включение по ролям/группам)

канареечные релизы (ограниченный процент пользователей)

откат и обратимость действий

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

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

Частые ошибки на этапе тестирования и итерации

тестировать «на коллегах», которые не живут в реальном контексте

задавать вопросы, которые подсказывают ответ, и получать подтверждение своих идей

собирать мнения вместо наблюдений поведения

смешивать в одном тесте слишком много изменений и не понимать, что повлияло

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

не фиксировать решения итерации письменно и возвращаться к тем же обсуждениям

Выходные артефакты этапов

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

список подтвержденных и опровергнутых гипотез

обновленная версия Problem Statement и критериев успеха (если нужно)

приоритизированный список изменений для следующего прототипа или MVP

план следующего теста: что проверяем, на каких ролях, какими сигналами

Итоги

Тестирование в дизайн-мышлении проверяет ценность, понятность, доверие и вписывание в контекст, а не только корректность реализации.

Сильный тест начинается с гипотезы, сценария, задач, сигналов успеха и ограничений.

Итерация может менять не только интерфейс, но и процесс, данные, объяснимость, права и операционность.

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

Если предыдущие этапы отвечали на вопрос что стоит сделать, то тестирование и итерации отвечают на вопрос как довести решение до устойчивого эффекта, не потратив лишнее на неверное направление.

Методологии и кейсы инноваций: d.school, IDEO, Double Diamond, Apple, Tesla, Toyota

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

Эта статья решает две задачи:

дает инженерно-практичное сравнение трех популярных рамок: Stanford d.school, IDEO, Double Diamond

показывает, как человеко-ориентированная и итеративная логика читается в кейсах Apple, Tesla и Toyota

Зачем инженеру знать несколько методологий

Разные рамки не конкурируют как «правильная» и «неправильная». Они помогают:

выбирать подходящий ритм работы под тип неопределенности

объяснять процесс стейкхолдерам общепринятым языком

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

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

!Сопоставление этапов курса с тремя популярными рамками дизайн-мышления

Stanford d.school: ясный цикл для быстрого обучения

В чем идея

Stanford d.school популяризировал понятный цикл, который легко запустить в команде и быстро превратить в регулярную практику. Классическая модель: Empathize → Define → Ideate → Prototype → Test.

сильный акцент на ранней работе с людьми

быстрые циклы прототипирования и проверки

культура "делай, чтобы думать" вместо "думай, чтобы сделать"

Источник: Stanford d.school — Getting Started with Design Thinking

Как это читать инженеру

Empathize соответствует нашей статье про эмпатию: исследование реального контекста и ролей.

Define соответствует Problem Statement и критериям успеха.

Prototype и Test в d.school часто очень ранние и «легкие», что снижает стоимость ошибки выбора направления.

Практическое применение:

используйте d.school, когда команда «не знает, что строить» и нужно быстро научиться

фиксируйте каждую итерацию как гипотезу и сигнал, иначе цикл станет хаотичным

IDEO: человеко-ориентированный дизайн как управляемый процесс

В чем идея

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

упор на междисциплинарность

прототипирование как основной метод исследования решений

внимание к внедрению, то есть к тому, как решение переживет реальный мир

Источник: IDEO — Design Thinking

Как это читать инженеру

В инженерных командах IDEO-подход особенно полезен как напоминание: «инновация» — это не только алгоритм или архитектура, но и то, как решение:

встроится в процессы пользователей

будет поддерживаться и объясняться

станет масштабируемым и жизнеспособным

Практическое применение:

используйте IDEO-оптику, когда решение затрагивает много ролей и стейкхолдеров

отдельно продумывайте «внедряемость»: эксплуатация, поддержка, обучение, стоимость владения

Double Diamond: дисциплина дивергенции и конвергенции

В чем идея

Double Diamond от Design Council описывает две связки "расширить → сузить":

сначала исследуем и уточняем проблему

затем исследуем и уточняем решение

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

Источник: Design Council — The Double Diamond

Как это читать инженеру

Double Diamond удобно накладывается на наши этапы:

левый «алмаз»: Эмпатия → Проблема

правый «алмаз»: Идеация → Прототип → Тестирование → Итерация

Практическое применение:

используйте Double Diamond, когда стейкхолдеры спорят о постановке задачи

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

Как выбрать рамку под вашу ситуацию

Ниже — инженерно-практичная шпаргалка.

| Ситуация | Что выбрать как "основной язык" | Почему это помогает | |---|---|---| | Непонятно, что нужно пользователю, много неизвестности | d.school | быстрые циклы прототипов и обучения | | Много стейкхолдеров, важно внедрение и жизнеспособность | IDEO | процесс ориентирован на принятие решения в реальном мире | | Команда преждевременно уходит в решение, спорит о проблеме | Double Diamond | дисциплинирует дивергенцию и конвергенцию |

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

Кейсы инженерных инноваций: что здесь про дизайн-мышление

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

Apple: инженерия пользовательского опыта как часть требований

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

Инженерный смысл:

UX становится частью спецификации

простота использования достигается инженерными решениями: производительность, энергопотребление, согласованность поведения, ограничения платформы

Источник, который показывает, что опыт формализуется как руководство и требования: Apple — Human Interface Guidelines

Что взять инженеру в практику:

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

тестируйте понятность и доверие так же системно, как корректность

Tesla: продукт как непрерывная итерация после поставки

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

Инженерный смысл:

обновляемость и безопасная поставка изменений становятся архитектурными требованиями

телеметрия и обратная связь — часть жизненного цикла продукта

Источник: Tesla — Master Plan, Part Deux

Что взять инженеру в практику:

проектируйте систему так, чтобы итерации были управляемыми: фича-флаги, поэтапный rollout, наблюдаемость, обратимость

разделяйте «мы можем обновлять» и «мы можем обновлять безопасно»

Toyota: «пойти и посмотреть» и непрерывное улучшение

Toyota Production System известна принципами, которые близки к эмпатии и итерациям: genchi genbutsu (идти на место и видеть своими глазами) и kaizen (непрерывное улучшение).

Инженерный смысл:

проблема уточняется у источника, а не только по отчетам

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

Источник: Toyota — Toyota Production System

Что взять инженеру в практику:

собирайте эмпатию через реальные артефакты работы: чек-листы, логи, реальные «обходные пути»

относитесь к улучшению как к серии небольших итераций с проверкой эффекта, а не как к разовому «большому проекту»

!Карта: как элементы дизайн-мышления проявляются в трех инженерных кейсах

Как связать методологии и кейсы с этапами курса

Чтобы этот материал не остался «историей про компании», свяжем его с тем, что вы уже изучили.

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

Проблема: Double Diamond защищает от ранней фиксации на решении и помогает согласовать формулировку задачи.

Идеация: IDEO подталкивает генерировать решения не только в UI, но и в процессах, данных и внедрении.

Прототип: d.school делает прототипирование ранним и дешевым, чтобы учиться до «правильной реализации».

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

Итоги

d.school, IDEO и Double Diamond — разные «языки» одной сути: человеко-ориентированное обучение через итерации.

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

Кейсы Apple, Tesla и Toyota показывают три инженерные формы дизайн-мышления: требования через опыт, итерации после поставки, эмпатия через «пойти и посмотреть».

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