Дизайн-мышление в коробке: @dzhechkov/design-thinking

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

Тулкит дизайн-мышления — пакет @dzhechkov/design-thinking — существует ровно для того, чтобы этот порыв перехватить. Он добавляет в проект шесть фаз, 25 методик с указанием научного источника и набор правил, которые не дают назвать догадку фактом.

Что именно ставится в проект:
- 8 навыков — оркестратор design-thinking и его зависимости;
- 1 команда — /design-thinking;
- 1 правило — соглашения о папках, фазовых воротах и анти-паттернах;
- 1 шард — таблица проверок DT-001…DT-023 с уровнями строгости.

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

Исходники и публичное зеркало: github.com/djd1m/dz-harness.

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

💬 Просто попроси.
- «Расскажи, что умеет пакет design-thinking» → ассистент откроет README пакета и перескажет, какие навыки, команда и правила ставятся в проект.
- «У меня сырая продуктовая идея, помоги её разобрать» → ассистент активирует навык design-thinking и начнёт с фазы эмпатии, а не с экранов.

Теория без запуска остаётся текстом, поэтому первое, что делает Мира, — ставит пакет в свой проект.

Команда init — точка входа тулкита. Она копирует навыки, команду, правило и шард в папку .claude/ текущего проекта:

npx @dzhechkov/design-thinking init

У команды init есть три полезных режима:
1. обычный — npx @dzhechkov/design-thinking init записывает файлы в проект;
2. предпросмотр — тот же вызов с флагом --dry-run показывает, что будет записано, и ничего не меняет;
3. перезапись — флаг --force обновляет уже установленный тулкит поверх старой версии.

У пакета есть ещё три команды: list перечисляет вложенные навыки, doctor проверяет, что установка в этом проекте цела, а --help и --version отвечают на очевидные вопросы. Мира завела привычку после каждой установки прогонять doctor: отсутствие ошибки при установке ещё не значит, что навык зарегистрировался.

После установки в Claude Code работает и явный вызов /design-thinking твоя задача, и простое описание пользовательской проблемы — навык активируется сам.

Компромиссы: команда init ставит тулкит целиком, включая зависимости, — это делает цепочку работоспособной без сети, но занимает место в .claude/ и перекрывает одноимённые навыки, если они там уже были. Поэтому первый запуск разумно делать с --dry-run.

💬 Просто попроси.
- «Поставь в этот проект пакет design-thinking» → ассистент выполнит npx @dzhechkov/design-thinking init и покажет список записанных файлов.
- «Проверь, что дизайн-мышление установлено правильно» → ассистент запустит doctor и объяснит каждое найденное расхождение.

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

Task Brief от explore — короткий документ, который рождается из сократического разговора: ассистент задаёт уточняющие вопросы и не предлагает решений, пока задача не прояснена. На выходе — тип задачи, ограничения, критерии успеха и то, что заказчик считает результатом.

Зачем этот шаг вообще нужен, если фаза эмпатии всё равно будет разговаривать с пользователями:
- исследование стоит дорого, а Task Brief от explore за десять минут отсекает половину неверных направлений;
- критерии успеха, записанные до работы, невозможно подогнать под результат задним числом;
- маршрутизатор сложности читает этот же документ, чтобы выбрать уровень проекта.

Весь путь выглядит так:

explore (Task Brief)
   ↓
1. Эмпатия → 2. Определение → 3. Идеация → 4. Прототип → 5. Тестирование → 6. Валидация

После каждой фазы конвейер останавливается на контрольной точке и печатает сводку. Мира отвечает ок — и конвейер идёт дальше; углуби <область> — и фаза дорабатывается; либо пишет свободный комментарий.

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

💬 Просто попроси.
- «Помоги сформулировать задачу перед дизайн-мышлением» → ассистент вызовет explore и соберёт Task Brief вопросами, не предлагая решений.
- «Покажи критерии успеха, которые мы записали» → ассистент вернётся к Task Brief и процитирует их дословно.

Первая фаза отвечает на вопрос «кто эти люди и на какую работу они нанимают продукт». Здесь Мира впервые упирается в настоящую развилку.

Проверяемое исследование пользователей держится на двух опорах. Первая — навык goap-research-ed25519: он собирает рыночные данные с цитируемыми источниками и подписью Ed25519. Подпись доказывает, что факт не подменили после сбора; она не доказывает, что факт верен, и пакет об этом честно предупреждает. Вторая опора — сами пользователи, и вот их данные ассистент взять из воздуха не может.

Поэтому фаза устроена с явными остановками:
1. Стоп на интервью. Ассистент просит расшифровки, заметки или записи. Нет интервью — он составляет гид с вопросами, критериями отбора и планом набора и ждёт. Минимум — 15 глубинных интервью для массового рынка и 25 для корпоративного.
2. Стоп на опросе. Нужны результаты от 100 респондентов; нет опроса — ассистент собирает анкету и снова ждёт.
3. Стратегический контекст — при необходимости каскад PESTEL → Портер → SWOT. Никогда SWOT в одиночку: как стартовый анализ он слишком расплывчат.

Выход фазы — отчёт об эмпатии: сегменты, описанные через обстоятельства, а не через возраст и пол; формулировки работы в виде «когда [ситуация], я хочу [мотивация], чтобы [результат]»; карта четырёх сил — толчок, притяжение, привычка, тревога; проверенные источники.

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

💬 Просто попроси.
- «У меня нет интервью, помоги их собрать» → ассистент напишет гид: вопросы, критерии отбора респондентов и план набора.
- «Собери рыночный контекст с проверяемыми источниками» → ассистент запустит goap-research-ed25519 и вернёт факты с цитатами и подписью.

Сырые интервью — это ещё не задача. Вторая фаза сводит их в одну фразу, ради которой всё и затевалось.

Формулировка POV (point of view, точка зрения) — предложение вида «[пользователь] нуждается в [потребность], потому что [инсайт]». Она короткая нарочно: если инсайт не помещается в одну строку, значит, ты ещё не понял, что нашёл.

К этой фразе ведут четыре инструмента, и у каждого своя работа:

интервью ──► холст работы (JTBD)   — на какую работу нанимают продукт
         ──► карта пути «как есть»  — где именно ему больно, шаг за шагом
         ──► диаграмма Исикавы      — почему больно, корневые причины
         ──► карта потока ценности  — сколько времени уходит впустую
                     ↓
            формулировка POV  ──►  3–5 вопросов «как мы могли бы…»

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

Выход фазы — определение проблемы: холст работы по каждому сегменту, карта пути по каждой персоне, диаграмма корневых причин, формулировка POV и 3–5 вопросов «как мы могли бы…», с которых начинается следующая фаза.

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

💬 Просто попроси.
- «Сведи интервью в карту пути как есть» → ассистент построит карту по одной персоне и отметит болевые точки по этапам.
- «Сформулируй точку зрения и вопросы как мы могли бы» → ассистент вернёт формулировку POV и 3–5 вопросов, выведенных из найденных болей.

Мира держит в руках пять вопросов «как мы могли бы…». Соблазн — взять первый ответ, который пришёл в голову, и объявить его гипотезой. Конвейер устроен так, чтобы это было невозможно.

Гипотезы HADI (hypothesis — action — data — insight) — это формулировка вида «если мы сделаем [действие], то [метрика] изменится на [X%] у [сегмента] за [период], потому что [обоснование]». Критерий проверки записывается до эксперимента: иначе после эксперимента любая цифра покажется подтверждением.

Но гипотезы HADI появляются не сразу — сначала обязательны три шага:
1. расхождение — из каждого вопроса «как мы могли бы…» набрать объём идей (техника «безумных восьмёрок» — восемь идей за восемь минут), цель 20–40 сырых идей, без оценки;
2. кластеризация — сгруппировать сырую кучу в направления методом сродства;
3. отбор по трём осям — желанность (люди правда этого хотят, и это видно в данных фаз 1–2), осуществимость (мы это построим), жизнеспособность (экономика сходится). Проходят только идеи, устоявшие по всем трём.

И лишь на выживших идеях строятся гипотезы HADI: минимум пять штук, ранжированные по риску и влиянию, из них 2–3 уходят в прототип.

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

Компромиссы: дисциплина «сначала объём, потом отбор» защищает от влюблённости в первую идею, но она стоит целой сессии. На маленькой задаче маршрутизатор сложности эту фазу просто не включает.

💬 Просто попроси.
- «Накидай сорок идей по этому вопросу, не оценивая» → ассистент проведёт расхождение и вернёт сырой список без фильтра.
- «Отбери идеи по желанности, осуществимости и жизнеспособности» → ассистент оценит кластеры по трём осям и покажет, кто прошёл, а кто нет.

Мира дошла до любимой части — можно наконец что-то строить. Конвейер добавляет одно условие.

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

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

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

И жёсткое требование: минимум две итерации прототипа до того, как что-либо объявляется готовым к тестированию.

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

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

💬 Просто попроси.
- «Подбери точность прототипа под мою гипотезу» → ассистент спросит, что именно нужно узнать, и предложит уровень от наброска до работающего продукта.
- «Собери кликабельный прототип по этой карте пути» → ассистент вызовет frontend-design с ограничением: только предсказуемые и удобные для тестирования шаблоны.

Пятая фаза превращает прототип из замысла в измерение: впервые за весь проект Мира получает цифры, которые никто не нарисовал. И здесь конвейер снова останавливается и просит настоящие данные — результаты тестов ассистент не выдумывает.

Тестирование с реальными пользователями — не показ прототипа коллегам. Правила выборки жёсткие и разные для разных заявлений:
- 5 пользователей на персону — качественный поиск проблем; классическая оценка: столько участников вскрывают около 85% проблем удобства;
- 30 и больше — как только ты хочешь сказать «статистически значимо»;
- 100 и больше респондентов — для количественного опроса.

Пять человек дают проблемы, но не проценты. Сказать «40% пользователей не нашли кнопку» по выборке из пяти — значит выдать двух человек за долю рынка.

Мерить принято по трём осям международного стандарта эргономики: результативность (доля выполненных задач), эффективность (время на задачу, число ошибок) и удовлетворённость (шкала удобства использования, где выше 68 — приемлемо, выше 80 — отлично). Схлопывать три оси в один самодельный порог «прошло/не прошло» запрещено отдельным правилом.

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

В этой же фазе собирается реестр рисков: вероятность и влияние по матрице 5×5, для каждого риска — триггер, стратегия и ответственный. И требуется минимум два цикла «тест — доработка» перед фазой валидации.

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

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

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

Пилотная валидация закрывает этот разрыв. Она устроена просто и потому неудобно:
1. Замысел пилота — один сегмент, одна география, один сценарий использования; длительность — не меньше двух полных циклов использования; базовая линия берётся из замеров «как есть».
2. Прогон — фактические показатели сравниваются со спроектированными: доля полезного времени в процессе, удовлетворённость по точкам контакта, реальная стоимость привлечения и кривая удержания, финальный статус оставшихся гипотез.
3. Разбор расхождений — по каждой метрике считается отклонение факта от проекции; всё, что разошлось больше чем на 20%, идёт на разбор. Если отношение пожизненной ценности к стоимости привлечения упало ниже трёх — модель бизнеса пересматривается.
4. Итоговый отчёт — с одним из четырёх решений: масштабировать, дорабатывать, разворачиваться или закрывать.

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

Мира заметила главное: пилотная валидация обязательна для крупных проектов (уровни L и XL). Для маленьких конвейер честно заканчивается на тестировании — но и рекомендация «стройте это в масштабе» тогда обязана прямо назвать, на чём она держится.

Компромиссы: пилотная валидация — самая долгая фаза и единственная, дающая право на слово «проверено». Она же чаще всего приносит неприятную новость, и в этом её ценность.

💬 Просто попроси.
- «Спроектируй пилот для этой гипотезы» → ассистент предложит границы, длительность и базовые метрики для сравнения.
- «Сравни факт с проекцией и скажи, что делать» → ассистент посчитает отклонения, отметит расхождения больше 20% и предложит решение из четырёх.

Всё, что Мира прочитала до сих пор, — это протокол, который можно тихо нарушить. Поэтому в тулките есть отдельный слой: гейты честности — 23 правила с номерами от DT-001 до DT-023, живущие в файле настроек проверки и в шарде с уровнями строгости.

Они существуют не для порядка, а потому что каждая подмена уже случалась и стоила дорого. Самые показательные:
- DT-011 — на уровнях L и XL пилотная валидация обязательна; без неё карта «как должно быть» остаётся фантазией;
- DT-013 — три оси измерения удобства нельзя схлопывать в один самодельный порог;
- DT-014 — цена и конверсия обязаны быть проверены эмпирически либо помечены как непроверенная экспертная оценка; заявленное намерение купить ценой не является;
- DT-015 — числитель и знаменатель метрики берутся из одного сегмента; смешанная выручка, делённая на пользователей одного канала, прячет убыточный канал за удачным средним;
- DT-016 … DT-018 — вынесенные в заголовок показатели окупаемости должны воспроизводиться из раскрытых входных данных, а модель на числах, не проверенных пилотом, называется проекцией и несёт анализ чувствительности;
- DT-019 — фаза, выполненная коллегой, помечается как делегированная и непроверенная, а не записывается в собственный результат;
- DT-020 — выборка из лояльной или самоотобранной аудитории не переносится на другой профиль клиента;
- DT-023 — планка, назначенная произвольно или подвинутая после промаха, не является проверкой.

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

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

💬 Просто попроси.
- «Проверь мой отчёт на гейты честности» → ассистент пройдёт по правилам DT-001…DT-023 и назовёт нарушенные с номерами.
- «Объясни, почему нельзя писать LTV/CAC = 12» → ассистент покажет соответствующий анти-паттерн и предложит когортный пересчёт с полной стоимостью привлечения.

Не каждой задаче нужны шесть фаз и 25 методик. За это отвечает маршрутизатор сложности — он читает Task Brief и выбирает уровень проекта, а уровень определяет, какие фазы вообще запустятся:
- S — быстрый инсайт по одной персоне: фазы 1, 2 и 5, интервью плюс тест удобства;
- M — новая функция на одну-две персоны: фазы 1–5, добавляются карта пути, гипотезы и прототип;
- L — новый продукт на два-три сегмента: все шесть фаз, добавляются стратегический анализ, поток ценности, выход на рынок и пилот;
- XL — платформа или экосистема: всё вышеперечисленное плюс модель бизнеса Остервальдера, анализ рисков и все необязательные интеграции.

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

тест опроверг точку зрения        → назад в фазу 1 с новыми вопросами
тест показал не ту персону        → назад в фазу 2, карта пути заново
пилот показал экономику ниже 1    → назад в фазу 3, пересмотр модели бизнеса
прототип провалил все сценарии    → назад в фазу 3, другие гипотезы
все гипотезы неубедительны        → назад в фазу 1, другие сегменты

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

Мира записала себе главное правило маршрутизации: уровень назначается один раз в начале и не меняется по ходу. Если объём вырос — это новый проект, а не тихое повышение уровня посреди работы.

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

💬 Просто попроси.
- «Оцени, какой уровень сложности у моей задачи» → ассистент разберёт Task Brief и предложит S, M, L или XL с обоснованием.
- «Тест опроверг нашу точку зрения, что делать» → ассистент назовёт нужную петлю возврата и переформулирует вопросы для новой волны интервью.

Последняя секция — про то, о чём инструменты обычно молчат.

Границы применимости тулкита названы в самом пакете, и Мира считает это признаком зрелости. Дизайн-мышление здесь не нужно, когда:
- задача техническая и уже поставлена — почини ошибку, спроектируй схему данных: для этого есть problem-solver-enhanced и конвейер фич;
- нужен просто поиск информации, без продуктовой цели — тогда достаточно исследовательского навыка;
- просят просто сверстать страницу без запроса на проверку спроса — это работа для frontend-design напрямую.

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

И три способа получить дизайн-мышление в проект — выбирай по тому, что тебе нужно:

| Способ | Что получаешь |
|---|---|
| Один навык через dz init --select design-thinking | Только оркестратор |
| Набор через dz setup --preset meta | Дизайн-мышление и остальные навыки процесса разработки |
| Тулкит через npx @dzhechkov/design-thinking init | Пакет целиком: навык, все зависимости, команда, правило и шард |

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

Все три способа и подробности — на странице пакета в npm и в публичном зеркале github.com/djd1m/dz-harness.

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

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