✈️ На этой неделе я в перелётах и джетлагах, поэтому заранее подготовила для вас материалы. Кстати, прямо сейчас пересекаю атлантику и да, у меня есть тут интернет! До чего дошел прогресс)

Ну а эта неделя будет посвящена дизайн-мышлению. Начнём с предпосылок.

Раньше, когда создавали продукт, ключевой вопрос звучал так: как это сделать? Фокус был на технологиях, бюджете и сроках. Но со временем всё стало сложнее: появились цифровые системы, быстро меняющиеся рынки, растущие ожидания пользователей. Мир нуждался в более гибком подходе.

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

IDEO — международная компания, основанная в Калифорнии в 1991 году. Важно! Она не придумала дизайн-мышление с нуля, но сыграла огромную роль в том, как мы его понимаем сегодня. В IDEO собрали разрозненные практики в единую методологию и сделали её понятной для бизнеса.

Классическая модель дизайн-мышления включает этапы:

✦ эмпатия
✦ формулировка проблемы
✦ генерация идей
✦ прототипирование
✦ тестирование

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

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

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

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

Эмпатия / Empathize

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

Фокусировка / Define

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

Генерация идей / Ideate

Это этап, где можно и нужно мечтать, перебарщивать, спорить и рисовать на доске. Мы придумываем как можно больше вариантов от очевидных до самых безумных. Тут не оцениваем, просто свободно генерируем без ограничений (вспоминаем про метод crazy 8).

Прототипирование / Prototype

Теперь пора что-то сделать руками. Прототип — это макет, черновик, бумажная модель или даже презентация, которая показывает, как идея работает. Чем проще и быстрее, тем лучше.

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

Показываем прототип пользователям, слушаем их, смотрим на реакцию. Что-то может пойти не так.. и это нормально. Мы делаем выводы и часто возвращаемся на шаг назад, чтобы всё улучшить. Если честно, иногда нужно вернуться даже больше, чем на один шаг. Этапы дизайн-мышления не являются строго линейными и могут выполняться параллельно, повторяться и перескакивать друг через друга в зависимости от хода проекта. И помним - универсальной таблетки для идеального проекта нет, всегда важно подключать свою голову и критическое мышление.

Ну и немного разбавим это контент. Вчера пролетала северный полюс. Не могу не поделиться ♥️

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

Дивергентное и конвергентное мышление.

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

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

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

Обе фазы одинаково важны. Если сразу начать сужать, новое просто не появится. А если всё время расширять, можно застрять в бесконечном «а что если».

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

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

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

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

👉 А вы замечали у себя эти переключения? Какой режим даётся вам сложнее?

Завершая неделю про дизайн-мышление, хочу порекомендовать вам одну отличную книгу Design Thinking: Pocket Guide (в русском переводе «Дизайн-мышление. Все инструменты в одной книге»).

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

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

Всё решают люди и обстоятельства. Их умение смотреть глубже, видеть потенциал в идеях, тестировать, ошибаться и доводить до результата.

🧠 Давайте сегодня обсудим такую штуку как Bias

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

Мозг как ленивый читер, который всё время хочет срезать путь. И вместо логики включает свои внутренние «хитрые тропки».

✦ Это баги в восприятии, встроенные в нашу базовую прошивку

✦ Они есть у всех — и у дизайнеров, и у пользователей

✦ Влияют на поведение и принятие решений сильнее, чем хотелось бы

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

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

А вы замечаете подобные искажения на себе?


❤️‍🔥 — да, замечаю и работаю с этим

🤔 — задумался(лась) об этом

🌚 — я всегда объекнивен(на)

Ребят, я вы знаете что такое вайбкодинг? Это не совсем в тему этого канала, но я тут за час сделала себе бота, который помогает мне в рабочих процессах, сэкономила 150 000 руб в моменте и очень много денег в перспективе какого-то времени. При этом я понимала примерно НИЧЕГО в скриптах и настройке ботов до утра вчерашнего дня.

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

Поставьте ❤️ если да и 🌚 если нет.

❤️❤️❤️ По многочисленным лайкам, первая часть моего рассказа о моем опыте вайб-кодинга.

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

Чтобы не утонуть в деталях, я расскажу историю в формате STAR. Это структура, которую в США часто просят на собеседованиях: Situation, Task, Action, Result. Звучит как аббревиатура для HR, но на деле это супер-полезная штука. С её помощью любой рассказ становится коротким, понятным и цепляющим.

Начнем с нашей ситуйэшн

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

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

Надо было что-то делать. Но что? Заходить самим каждый день? Можно, но честно говоря у нас есть задачи поважнее. Нанять администратора? Дорого и не факт, что найдём ответственного. Просить менторов заглядывать чаще? Они и так стараются, но не всегда получается.

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

❤️ — да, интересно следить за историей

🌚 — девочки не могут кодить, даже если это вайб

🤔 — хочу понять, как работает STAR

Продолжаю рассказ о своем первом опыте вайбкодинга. Task

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

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

Я поделилась этой идеей с Женей. Может, подключим разработчика? Оказалось, что да, но позже. Сейчас команда горит на подготовке к UPROCK Fest, и сроки неизвестны.

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

Внутри было ощущение, что мы просто вязнем. А задача ведь очевидна: алгоритм понятный, решение рядом. И тогда я подумала: «А если попробовать сделать это самой? У меня же есть нейросети и я с их помощью могу и сама осилить эту задачу.

А как часто вам приходится откладывать свои идеи из-за ожидания разработки?

🌚 — всё время жду

🤔 — иногда приходится, но такова жизнь

👾 —разработчики никогда меня не подводили

👉 кайндли ремайндер: завтра в 19:00 я проведу разбор портфолио) посмотрим 5 разных интересных кейсов. Во всю готовлюсь, надеюсь всех вас увидеть.