Обратили внимание как много лежит только с 1 по 3 пунктах? И на то, как мало фреймворков надо знать? Поэтому мой ютуб из фреймворков состоит (некоторые бесполезные убраны конечно же). Рисуйте + думайте.

Почему так мало фреймворков надо знать?
Без еды не выжить. Значит, у тебя есть в голове понимание, что нужно кушать. Значит, нужна еда, которую можно получить в обмен на деньги. Чтобы получить деньги, нужна работа. На работе платят деньги в обмен на твои навыки. Получив совокупную ценность (от всех сотрудников), компания конвертирует ее в какой-то результат (какой бы он ни был) в ценность для клиента и тут дальше как повезет: будут покупать или нет — хз.

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

Что для этого нужно?
- уметь рисовать интерфейсы и опыт с ними (чтобы любой вид кнопки/инпута/карточки на любой платформе не был для тебя проблемой).
- уметь понимать как нарисовать хороший интерфейс (продолжать рисовать, смотреть, пробовать + база граф дизайна) и опыт с этим.
- уметь понимать пользователя через его когда/хочу/чтобы (jtbd), чтобы ты рисовал хороший интерфейс с пониманием в каком контексте, для кого и для чего оно будет использоваться — продуктов без контекста практически не существует, и давайте мыслить работой в it, а не в вакууме.
- уметь делать коридорки и ю-тесты, чтобы проверить на базовые ошибки интерфейс или найти какие-то инсайты
- уметь понимать чиселки через постановку гипотез и посчитанный эффект

Снова обратите на первые 2 пункта.

[1/2]

❌ Почему модель Кано не работает в продуктовой работе

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

Это не «хейт». Это разбор по фактам, разбитый по частям.

—

Часть 1. Что такое модель Кано (коротко)

Модель Кано — это способ классифицировать функции продукта через опрос пользователей.

Суть:
- спрашиваем, как человек отнесётся к функции если она есть;
- и если её нет;
- по ответам функции делятся на:

обязательные
важные
привлекательные
безразличные

На бумаге звучит логично.
На практике — нет.

—

Часть 2. Проблема №1 — фундаментальная дыра методологии
❗️ Кано не решает ключевой вопрос: что именно показывать пользователю

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

Варианты:
- текстовое описание → человек оценивает фантазию;
- прототип → зачем тогда опрос, если можно смотреть поведение?

👉 Метод перекладывает критический риск интерпретации на исследователя
и не даёт правил, как этот риск снижать.

—

Часть 3. Проблема №2 — заявленные vs проявленные предпочтения

Это базовый принцип поведенческой экономики.

Есть два типа предпочтений:
- что люди говорят;
- что люди делают и за что платят.

И они часто не совпадают.

Примеры:

«Хожу в зал 3 раза в неделю» → был 2 раза за 3 месяца;

«Готов платить за экологию» → покупает самое дешёвое;

«30к за часы — дорого» → покупает за 35к после примерки.

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

📌 Кано работает только с заявленными предпочтениями.
А продуктовая реальность живёт в проявленных.

—

Часть 4. Классические провалы заявленных предпочтений

New Coke (1985)
200 000 слепых тестов → новая формула «вкуснее».
Запуск → провал.

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

iPhone 2007
Если бы Apple спросили:
- телефон без кнопок? ❌
- без сменного аккумулятора? ❌

Apple не спрашивали. Они запустили.

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

—

Часть 5. Проблема №3 — субъективность и отсутствие воспроизводимости

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

Что это значит:
- разные команды → разные выводы из одних данных;
- нет воспроизводимости;
- решение зависит от трактовки, а не от данных.

👉 Это не эксперимент, а рамка для мнений.

@easyaboutdesign

[2/2]

Часть 6. Проблема №4 — отсутствие связи с деньгами и метриками

Допустим, вы получили:

функция A — обязательна
- нужна 1% пользователей
- 3 месяца разработки
- нулевой импакт

функция B — безразлична
- 80% пользователей
- 1 неделя разработки
- +10% конверсии

Кано скажет: делай A.
RICE / ICE скажут: делай B.

📌 Кано не отвечает на вопросы:

- сколько пользователей затронет?
- какое влияние будет?
- какие усилия требуются?
- какой ROI?

—

Часть 7. Проблема №5 — историческая искаженность

Модель создана:
- в конце 70-х,
- до интернета,
- до аналитики,
- до A/B-тестов,
- до data-driven культуры.

Это не «плохо».
Это контекстно ограничено.

Сегодня у нас есть:
- телеметрия,
- real-time аналитика,
- дешевые эксперименты: коридорки и юзабилити-тесты, fake door
- A/B на n% трафика.

Кано создавался для мира, где ничего этого не было.

—

Часть 8. Эффект «испорченного телефона»
- оригинал на японском,
- закрытые публикации,
- десятилетия пересказов,
- Medium / курсы / консалтинг.

📌 Большинство работает не с оригиналом, а с переводами, и допущениями, в которых потерян исходный контекст.

📌 В результате «Кано» сегодня — это не оригинальный метод, а его адаптированная версия, удобная для обучения и презентаций.

—

Часть 9. Почему Кано всё ещё используют

- Так учили.
- Метод простой.
- «Надо же как-то приоритизировать».
- Карго-культ: «так делают большие компании».
- Запрос заказчика.

Простота ≠ предсказательная сила.

—

Часть 10. Что работает вместо Кано

Jobs To Be Done + метрики + ЭКСПЕРИМЕНТЫ (= МНОГО ДИЗАЙНА)
- вопросы про прошлое поведение, а не будущее мнение;
- контекст, триггер, выбор, цена, последствия;
- проверяемые гипотезы;
- связь с бизнес-метриками.

Инструменты:
- Много дизайна = Много макетов
- JTBD-интервью,
- RICE / ICE,
- fake door,
- коридорки,
- ю-тесты,
- A/B.

Решения принимаются:
- по действиям, сценариям, которые надо рисовать
- по деньгам,
- по метрикам, а не по словам


Итог Кано:
- опирается на слова, а не поведение;
- не связана с экономикой;
- не воспроизводима;
- не предсказывает результат.

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

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

@easyaboutdesign

upd по Магнум опусу:
- продолжаю готовить сценарии и материал для практики
- благодаря нейронкам теория появится быстрее, так как ее будет озвучивать мой голос и мой ИИ клон
- практику буду записывать я (так что там много часов будет)
- к курсу будет телеграмм бот (надеюсь), который я завайкодил почти для тех, кто хочет почитать конспекты, а также пройти квизы для закрепления, если я их доделаю тоже на вайбкоде))
- все бесплатно будет, ничего не поменялось

На след. неделе попробую сделать канбан-доску какую-то, для тех, кто хочет следить как двигается материал (мало ли интересно)

@easyaboutdesign

Изи навыки опубликовал целиком. Кайфуйте.

Смотреть плейлист
Смотреть плейлист
Смотреть плейлист

@easyaboutdesign

За 3 часа стрима получилось сделать mvp!

Основная цель стрима показать:
- как без знаний начать работу в cursor.com
- как создавать правила
- на старте вам не нужны знаний, надо пробовать
- и пробуя, спрашивать курсор "как с тобой работать" "как создавать правила"
- не копируйте чужие промпты!
- используйте свои знания чтобы создавать на их основе правила, которые помогут ИИ регулировать сам себя
- сначала определить цель, контекст, ограничения и критерии плохого и хорошего результата

Вот что мы сделали:
- сделали mvp конструктора матрицы компетенций с отправкой от роли lead к designer, последний может узнать у ИИ про компетенции
- и оно работает!

Технический стек:
- фронт: react + reactflow.dev (для схем)
- бэкенд: supabase (бесплатный план)
- регистрация/авторизация по otp (код на почту)
- две роли (designer / lead)
- создание компетенций на схеме и отправка от роли lead обновленной матрицы на designer
- подключили ИИ (chatgpt) к нодам чтобы объяснял что значит каждая нода (компетенция)
- дебага много было тоже
- наговаривал голосом через mac whisper

Чтобы делать свои правила:
.cursor - папка в корне проекта, а внутри нее rules папка, внутри которой уже создавайте .mdc формата файлы (markdown) и пишите свои правила, делайте ссылки между правилами указывая путь до них

гав-гав

https://youtu.be/zGLCZmST4Ho
https://youtu.be/zGLCZmST4Ho
https://youtu.be/zGLCZmST4Ho

@easyaboutdesign