Функция Дизайна | Леонид Ивахов

А я дальше напишу про когнитивные искажения.

Аргументация дизайна. Часть 9. Лучшие практики (Best Practices) Когда мы ищем подкрепление / основание гарантии (Backing) в процессе аргументации дизайна, то чаще всего начинаем с поиска лучших практик. Нам кажется, что если кто-то это уже это сделал, то вероятность того, что наша гипотеза попадает в точку, повышается. Тут важно не попасть в когнитивное искажение и не словить иллюзию ложного подтверждения. Нужно понимать следующее: если это существует — это не значит, что это хорошее решение. 1️⃣ Это решение делают такие жи дизайнеры, и они могут ошибаться. 2️⃣ Это решение может быть невалидированной гипотезой, которая в данный момент просто тестируется. 3️⃣ Это решение делали наспех в условиях ограниченных ресурсов, и оно может быть просто временным. 4️⃣ Контекст и задача этого решения совсем неочевидна, и цель такого дизайна совсем в другом. Раньше найти коллекцию UI/UX-кейсов было практически невозможно. Сейчас их нужно собирать по крупицам и накапливать свою базу знаний и понимания. 2 года назад, когда я работал в МТС, я сам вручную проводил анализ экосистмной связанности Сбера, Яндекса, Тинькофф и тд. Я вручную авторизовывался, решал одни и те же типовые задачи по поиску единиц контент и товаров, оформлял заказы, проводил платежи, анализировал методы коммуникации с клиентом и пр. Это занимает огромное кол-во времени, но зато позволяет найти огромное кол-во интересных и неочевидных решений, которые обычно не на виду. Сейчас такие решения можно поискать, например, в ScreenBook — коллекции скриншотов российских мобильных приложений для iOS и Android. Можно искать по экранам 📱, UI-элементам и даже анимациям ✨ Экономит кучу времени и сил. Но будьте категоричнее в оценке референсов: анализируйте удачность этого решения относительно задачи, и постарайтесь попробовать использовать эти решения вживую. Ещё рекомендую тг-канал, куда публикуются обновления контента: 📲@ux_advocate А я дальше напишу про когнитивные искажения.

Всем привет! 1 октября стартует курс Next Level UI, на котором в коллабе с Мишей Розовым, Виталей Рынским и Максом Десятых я прочитаю сразу 3 лекции, посвящённые лидерству в дизайне и как быть дизайнером: 1️⃣ Стили управления в дизайне. Матрица ролей Адизеса. 2️⃣ Модель измений и работа с ограничивающими убеждениями. Пирамида нейрологических уровней Дилтса. 3️⃣ Мотивация. Какая бывает и откуда берётся. Про что коллаба в целом: — Эта коллаборация даст самые глубокие знания и современные технологии для выразительного насыщенного UI. — Будут еженедельные воркшопы и лекции, чтобы вы не теряли мотивацию. — В конце — просмотр портфолио/кейсов от приглашенных экспертов Условия: — Чтобы присоединиться к коллаборации, нужно занять место до 30 сентября включительно. — Самые известные дизайнеры индустрии, помогут разобраться в психологии и модели развития личности, чтобы вы были непобедимы в карьере. — Есть небольшая интенсивная группа, туда набираем всего 40 человек. Осталось 18 мест. — Занятия будут проходить в октябре и ноябре. Next Level UI — это курс для дизайнеров, которые хотят выйти на международный уровень! 👉 Почитать подробнее и успеть в последний вагон 👈

Митя Осадчук недавно на курсе Next Level ребятам рассказывал про метод прогрессивного джипега. И показал на сайте Лебедева ководство от 2010го. И когда сказал что раньше джипег грузился сверху вниз, я себя почувствовал старым 🥲 А потом показал уровни дизайна Джесса Джеймса Гарретта. И это был контрольный 🔫 С Днём рождения, Митя Осадчук! ♥️

Привет! Это Лёня Ивахов, дизайн-директор (ex-Билайн, Одноклассники, МТС). Есть интересная мысль для вас — если вы уже middle, делаете работу хорошо, но возникают вопросики: → что я реально даю бизнесу и людям? → почему другие растут, а я топчусь? → где моя ценность, за что готовы платить? Чтобы ответить на них, вам придётся изучать потребности ваших клиентов и заказчиков и сформулировать ценность, которую вы можете им предложить как дизайнеры. И если вы сможете дать эту ценность, а ваши клиенты будут готовы за неё платить, то это будет тот самый Product Market Fit, о котором так много говорят. Где вы — Product, о котором клиенты должны узнать и понять, как с вами делать дела, а Market — это клиенты, которым нужен дизайн. А Fit — ваш идеальный мэтч 🩶 Сегодня, 9 сентября, в 19:00 по мск, я проведу целую лекцию, где мы с Мишей Розовым разберём путь клиента до вас, чтобы вас можно было легко найти, сложно потерять и невозможно забыть. Для этого нам понадобится разобраться, что же такое Customer Journey на самом деле, как устроены точки контакта клиента и дизайнера, и где там рост. Приходите, чтобы не набивать шишки самим и учиться на моем опыте. Зарегистрируйтесь через бота, если хотите задать свой вопрос, точно получить все материалы ивента и ничего не пропустить. 👉 https://t.me/wnbl_rozova_bot?start=w43983247

Open talk Миши Розова и Лёни Ивахова: точки роста в карьере дизайнера Системно поговорим про то как искать свои точки роста, чем здесь может помочь Customer Journey и перспектива: дизайнер — продукт, заказчик — пользователь. Все это для того, чтобы понять, как достигать результатов и преодолевать потолок, когда кажется, что ты застрял и пути наверх уже нет. Встречаемся 9 сентября в 19:00 по мск. 👉 Регистрация через бот

Приходите! 💥

Вместо одного эксперта на next level, я собрал несколько человек в мульти-коллабу на next level Лёня Ивахов называет себя путешествующим дизайн-директором — потому что у него за спиной и много лет одноклассников, и последняя дизайн-трансформация МТСа, и потому что при этом он много путешествует по вполне загадочным местам Лёню я позвал по той причине, что унего есть большой корпоративный опыт, при этом широкое понимание как естественно и системно развиваться дизайнерам, о чем он и расскажет в нескольких лекциях на курсе

Ультрапотрясающий Миша Розов позвал меня на свой курс NextLevel чтобы читать там курс лекций. Я буду рассказывать и проводить воркшопы на общую тему «Как быть дизайнером». А про то как делать дизайн расскажут другие топовые ребята ☺️

Как дизайнеру быть убедительным. Леонид Ивахов У нас в гостях eх-арт-директор цифровых продуктов «Мой МТС» и автор телеграм-канала «Функции дизайна» – Леонид Ивахов. Лёня рассказал о том, как дизайнеру убеждать коллег и клиентов с помощью модели аргументации британского философа Стивена Е. Тулмина. О том, как бороться с когнитивными и искажениями и как правильная формулировка может спасти или уничтожить аргументацию. А еще Леня рассказал как тренировать ИИ для тренировки скилов убеждения. Упомянутый в выпуске пост с раскрытием темы можно найти по этой ссылке Вопросы для Лёни можно оставить в комментариях к выпуску 👉 Слушать в телеграм-плеере 👉 Слушать в Apple 👉 Слушать в Яндексе

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

Аргументация дизайна. Часть 8 Давайте попробуем собрать всё вместе, чтобы получилась демонстрация изменений, которая выглядит убедительно. 🎯Цель изменения дизайна (Всегда начинайте с поставленной задачи. Это поможет выровнять контекст всем участникам обсуждения) Повысить удобство процесса оплаты и конверсию завершённых покупок. 🤕Проблема, выявленная в продукте (У любой задачи есть предпосылка. Она должна обозначить актуальность задачи: степень влияния и актуальность) В мобильной версии на промежуточных экранах теряется до 18% пользователей. Данные получены от продуктовых аналитиков за 4Q. ☝️Утверждение (Это то изменение, которое предлагает дизайнер, и которое должно быть убедительным) С высокой вероятностью новый сценарий оплаты повысит конверсию завершённых покупок на 10–20% и сделает процесс удобнее для большинства пользователей 💊Основания (Это то, благодаря чему утверждение должно сработать) 1. Объединили все шаги оплаты на одном экране 2. Убрали необязательные поля. 3. Добавили автоподстановку данных по адресу и вводу сохранённых карт. ⚖️Гарантия (Это то, почему мы считаем что это логично) Сокращение шагов и снижение когнитивной нагрузки повышают удобство и вероятность завершения оплаты 🔬Подкрепление гарантии (Ссылаемся к чему-то авторитетному и проверенному) — Исследования NNGroup показывают: упрощение чек-аута и удаление необязательных полей повышают конверсию на 10–20%, а автозаполнение сокращают время выполнения задачи и количество ошибок. — Ещё A/B-эксперимент 2023 года с упрощённым сценарием подписки дал +12% к завершённым оплатам ⛔️Опровержение (Показываем что продумали разные кейсы и есть возможность облажаться) При оплате в рассрочку эффект вероятно будет ниже или даже хуже, потому что более сложный вариант рассрочки будет конкурировать за основной быстрый способ оплаты. 📋План действий (Поскольку изменения достаточно рискованные и ресурсозатратные, лучше убедиться заранее что они к лучшему) 1. Собрать прототип на основе макетов и AI (связка Figma AI, GPT или Coursor) 2. Провести UX-тесты в лаборатории на 6-8 респондентов за 1-2 дня 3. Доработать сценарии и разбить изменения на несколько этапов: сначала упрощение полей, затем автоподстановка. 4. Провести серию A/B-экспериментов для проверки гипотезы на малой выборке пользователей, чтобы не уронить конверсию на этапе оплаты. 5. Убедиться в значимости изменений и раскатать изменения на всю аудиторию. Вы великолепны 👑

Аргументация дизайна. Часть 7 Потенциальное опровержение / Условие, при котором тезис не работает (Rebuttal) — это условия, при которых утверждение может быть оспорено или признано неприменимым. То есть по сути это такая форма превентивного возражения, встроенная внутрь аргумента. Нужно для того, чтобы: — Показать, что дизайнер учёл контекст и альтернативные сценарии; — Делает аргумент более устойчивым, предвосхищая критику; — Тоже показывает честность и профессиональную зрелость дизайнера. Опровержение чаще всего формулируется как условие или исключение: — За исключением случаев, когда… — Но не тогда, когда… — Если только не… — Кроме ситуации, когда — Только при условии, если… — Если не учитывать ситуации, при которых… — Кроме пользователей, у которых… — Это не относится к… — При наличии Z… Пример: — Кроме сценариев для B2B-клиентов; — В старых браузерах автозаполнение может не сработать; — На маленьких смартфон кнопка не будет помещаться в первый экран. Вместе с Утверждением Опровержение будет звучать следующим образом: Пример с пушами: Claim: — Push-уведомления вернут пользователей в приложение... Rebuttal: …если только они не будут восприниматься как спам и не вызовут отток. Пример с онбордингом: Claim: — Сценарий онбординга повысит retention... Rebuttal: …если только он не окажется слишком длинным и не отпугнёт нетерпеливых пользователей.

Аргументация дизайна. Часть 6 Модальность / Степень уверенности (Qualifier) — указывает, насколько обосновано Утверждение: при каких условиях, с какой вероятностью, в каком объёме или в каком контексте утверждение считается справедливым. Можно использовать такие формулировки: «вероятно», «возможно», «скорее всего», «почти наверняка», «в редких случаях», «с большой вероятностью», «есть основания полагать, что», «по всей видимости», «предположительно», «в большинстве случаев» и тд. То есть модальность: 1️⃣ Делает аргумент гибче и реалистичнее; 2️⃣ Снижает категоричность утвержденияи и показывает, что вывод не претендует на абсолютную истину; 3️⃣ Помогает дизайнеру звучать более честно и профессионально; 4️⃣ Служит переходом к Потенциальному опровержению. Например: — Вероятно, новый сценарий будет восприниматься как более удобный… — В текущей версии customer journey… — Скорее всего, эффект будет заметен только для… — Почти наверняка улучшение загрузки… — Предположительно, мобильные юзеры… — В редких случаях на слабом интернете может не загружаться… — Есть основания полагать, что люди постарше не справятся с…

Аргументация дизайна. Часть 5 Подкрепление гарантии (Backing) — это доводы (факты, исследования, авторитетные источники или эмпирические данные) в поддержку Гарантии, если Гарантия подвергается сомнению. Что, на самом деле, очень разумно. Чаще всего это ссылка на более широкую систему знаний: экспертизу или описанные ранее правила. Подкрепление гарантии —  это доказательство того, что логика перехода от основания / данных к утверждению каким-то образом обоснована. Потому что в процессе аргументации возникает вопрос: а почему мы решили что эта логика адекватна? 🔸В науке подкреплением являются научные эксперименты, доказанные теории и законы. 🔸В бизнесе — это часто отраслевые стандарты, прецеденты или статистика. 🔸В дизайне мы используем гайдлайны, результаты usability-тестов и данные проведённых ранее похожих по смыслу A/B-экспериментов. Например: — Согласно исследованиям Nielsen Norman Group, сценарии с более 2 шагов и без прогресса-бара имеют в 1.5 раза больше отказов; — Какое-то там исследование показывает, что лишние поля в форме увеличивают показатель отказа на 25%. Мы можем использовать известные бенчмарки, опыт предыдущих экспериментов и вообще любые эмпирические данные, если они являются показательными и релевантными для подкрепления. То есть подкрепление гарантии — это не доказательство утверждения напрямую, а обоснование самого правила, по которому из данных / основания делается вывод. В общем, это нужно для устранения сомнений.

Аргументация дизайна. Часть 4 Гарантия (Warrant) объясняет, почему из Данных (Data) логично следует Утверждение (Claim). Это «мост» между наблюдаемым и утверждаемым. Обычно мы считаем её самоочевидной, поэтому можем опускать и не произносить. Но именно гарантия делает аргумент логически валидным, иначе мы просто имеем два разрозненных утверждения: факт и мнение, которые не соединены между собой. Пример: — Если пользователи тратят много времени и делают ошибки — сценарий неудобен; — Если пользователи чаще завершают оплату, значит сценарий стал эффективнее. 🤔 Пример великого заблуждения: Утверждение — Новый дизайн уменьшает когнитивную нагрузку; Основание — Форма стала на 50% короче, количество полей уменьшено с 12 до 5; Гарантия — Если человек делает меньше шагов — он тратит меньше усилий. Дело в том что полей или, например, шагов оформления заказа стало меньше, но при этом каждый шаг, каждое поле стали сами по себе сложнее. То есть на каждом этапе нужно внимательнее вдумываться и разбираться в условиях и корректности взаимодействия. То есть по факту, полей стало меньше, а время заполнения — дольше. Усталость — выше. Сомнений — больше. ☝️ Реальный кейс: Когда мы в Билайне делали сценарий привязи банковской карты для автоплатежей, там не требовался CVV. И люди тормозились и не привязывали карты. Оказывается, они по привычке искали куда вводить CVV, думали что у них не отображается поле. То есть поле убрали, а прохождение сценария усложнили. Главный вопрос, который нужно задать: Почему из этих данных можно сделать именно такой вывод?

Аргументация дизайна. Часть 3 Данные / Основания (Data / Grounds) — это факты, наблюдения, метрики или инсайты, на которых основано Утверждение (Claim). Например: — В среднем пользователи совершают 3 попытки оплаты, и 20% не завершают оформление заказа; — На A/B-тесте вариант B показал рост конверсии на 15%. Основания часто являются частью формулировки утверждения-наблюдения, но самое важно — это разделять факты от интерпретаций. ☝️ Факты — это достоверная информация, а интерпретации — это наши галлюцинации. Объясню по порядку. ⚫ Факты — это объективные, проверяемые сведения, которые можно зафиксировать, воспроизвести или измерить. Они описывают то, что произошло или наблюдается, без добавления оценок или предположений. Как понять что факт — это факт: — можно проверить независимыми методами; — результат проверки будет одинаков при повторении; — не зависит от субъективного мнения. Например: — Среднее время заполнения формы — 1,5 минуты; — В ходе тестирования 5 из 7 участников нажали на не ту кнопку на третьем шаге. Теперь самое интересное, из-за чего обычно возникают все споры, сомнения в экспертности экспертов, а дизайнер часто звучит неубедительно. ⚫ Интерпретации — это выводы, объяснения или оценки, сделанные на основе фактов. Интерпретации могут преломлять факт через призму опыта, заблуждений, убеждений, иллюзий, искажённой логики рассуждения и тд. То есть это интерпретация когда: — Основание различается у разных специалистов при одинаковых исходных данных; — Часто содержит оценочные или вероятностные слова. Например: — Пользователи путаются в сценарии оплаты; (Это интерпретация факта, что 27% пользователей не завершают оплату. Интерпретация в слове «путаются». Они может не путаются, а наоборот разбираются и намеренно завершают оплату, поняв невыгодность условий доставки) ⚜️ Или вот, например, классика: Факт: «Пользователи не нажимают кнопку». Интерпретация: «Пользователи не видят кнопку» Как сделать интерпретацию фактом: Например, проверить методом Eye tracking. Тогда возможные факты: — Респондент не видит элемент, потому что он незаметный, или соседние элементы отвлекают внимание — видит, но не понимает смысл (не ассоциирует что он интерактивный), потому что элемент выглядит как декоративный приём (оформление) — видит, но не ассоциирует со своей задачей, потому что название или внешний вид элемента вводит заблуждение — видит, понимает, ассоциирует, но опасается нажимать, элемент не подсказывает что будет дальше после взаимодействия

Аргументация дизайна. Часть 2 Утверждение (Claim) — это то, что мы предлагаем принять как некоторую позицию, которая требует обоснования. А всё остальное (данные, гарантия, обоснование, ограничения и опровержение) служит для его поддержки или уточнения. Далее я буду использовать примеры из типового сценария оплаты в интернет-магазине. Ну или что-нибудь похожее по смыслу и сложности. Утверждения бывают разные: 1️⃣ Утверждение-наблюдение — констатация наблюдаемого или измеренного. — Пользователи путаются в сценарии оплаты; — 70% пользователей закрывают форму на шаге ввода адреса; — Среднее время заполнения анкеты — 6 минут; — Мобильная версия сайта загружается 8 секунд; 2️⃣ Утверждение-оценка — интерпретация или субъективное суждение, основанное на опыте или наблюдении. — Этот интерфейс неудобен для новых пользователей; — Процесс регистрации слишком длинный для первого входа; — Форма выглядит перегруженной для маленького экрана; (Это нормально оперировать оценкой, если у нас нет измеримых данных, тогда мы обращаемся к опыту) 3️⃣ Утверждение-рекомендация — ориентировано на действие, предлагает решение. — Нужно переработать сценарий оплаты; — Нужно упростить форму регистрации до трёх шагов; — Рекомендуется добавить подсказки внутри полей; — Следует оптимизировать изображения для ускорения загрузки. (Рекомендации — это то, что чаще всего ждут от дизайнера, потому что они продвигают к изменениям) 4️⃣ Утверждение-гипотеза — условное предположение о возможном результате изменений. — Если мы добавим прогресс-бар, пользователи будут чаще завершать оплату; — Добавление прогресс-бара улучшит восприятие формы оформления заказа; — Сокращение количества полей в форме регистрации повысит её завершение; — Если добавить визуальные подсказки, пользователи будут быстрее находить нужный раздел; — Адаптация интерфейса под мобильный формат снизит показатель отказов; — Добавление превью товара на этапе оплаты снизит число возвратов; (Нужно понимать что любая идея по сути всегда является гипотезой, которая требует проверки на правдивость. О том как вообще строятся гипотезы я тоже как-нибудь напишу)

Аргументация дизайна. Часть 1 Для того чтобы дизайнеру быть убедительным в процессе обсуждения дизайна можно использовать специальную технику. Она пригодится во время демонстрации дизайна арт-директору или команде. Дизайнер, который умеет быть убедительным: 1. Сам лучше верит в те изменения, которые предлагает 2. Обладает большим авторитетом в глазах коллег, заказчика и своего руководителя. Мне не нравятся концепции «защиты» или «продажи» дизайна. Защита подразумевает нападение, а я не вижу смысла нападать на чью-то идею. Потому что творческий коллектив нацелен на совместное изобретение, а значит должны работать принципы совместного додумывания и улучшения идей. Но обосновать изменения всё-таки придётся, и будет здорово, если обоснование будет последовательным, стройным и логичным. Для этого можно использовать модель аргументации Стивена Тулмина. Стивен Тулмин — британский философ, логик и теоретик аргументации, один из ключевых мыслителей XX века в области прикладной логики и риторики. Он разработал модель аргументации, которая состоит из шести компонентов, три из которых являются обязательными, а три — вспомогательными, которые обеспечивают гибкость и обоснованность в процессе убеждения. Сначала коротко, а потом я раскрою подробно каждый компонент: 1. Тезис (Claim) — то, что вы утверждаете. 2. Данные (Data) — факты, на которые опираетесь. 3. Гарантия (Warrant) — логическая связь между фактами и тезисом. 4. Основание гарантии (Backing) — доказательства, почему эта связь надёжна. 5. Ограничение (Qualifier) — степень уверенности в тезисе. 6. Опровержение (Rebuttal) — признание условий, при которых ваш тезис не сработает.