Я как-то увлёкся поиском ответов на вопрос «Почему мы что-то считаем красивым, а что-то нет». И наткнулся на лекцию потрясающей Евгении Тимоновой Нейроэстетика прекрасного: восприятие всего

Удовольствие гарантирую! 💯

Аргументация дизайна. Часть 1

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

Дизайнер, который умеет быть убедительным:

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

Мне не нравятся концепции «защиты» или «продажи» дизайна. Защита подразумевает нападение, а я не вижу смысла нападать на чью-то идею. Потому что творческий коллектив нацелен на совместное изобретение, а значит должны работать принципы совместного додумывания и улучшения идей. Но обосновать изменения всё-таки придётся, и будет здорово, если обоснование будет последовательным, стройным и логичным. Для этого можно использовать модель аргументации Стивена Тулмина.

Стивен Тулмин — британский философ, логик и теоретик аргументации, один из ключевых мыслителей XX века в области прикладной логики и риторики.

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

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

1. Тезис (Claim) — то, что вы утверждаете.
2. Данные (Data) — факты, на которые опираетесь.
3. Гарантия (Warrant) — логическая связь между фактами и тезисом.
4. Основание гарантии (Backing) — доказательства, почему эта связь надёжна.
5. Ограничение (Qualifier) — степень уверенности в тезисе.
6. Опровержение (Rebuttal) — признание условий, при которых ваш тезис не сработает.

Аргументация дизайна. Часть 2

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

Далее я буду использовать примеры из типового сценария оплаты в интернет-магазине. Ну или что-нибудь похожее по смыслу и сложности.

Утверждения бывают разные:

1️⃣ Утверждение-наблюдение — констатация наблюдаемого или измеренного.

— Пользователи путаются в сценарии оплаты;
— 70% пользователей закрывают форму на шаге ввода адреса;
— Среднее время заполнения анкеты — 6 минут;
— Мобильная версия сайта загружается 8 секунд;


2️⃣ Утверждение-оценка — интерпретация или субъективное суждение, основанное на опыте или наблюдении.

— Этот интерфейс неудобен для новых пользователей;
— Процесс регистрации слишком длинный для первого входа;
— Форма выглядит перегруженной для маленького экрана;

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


3️⃣ Утверждение-рекомендация — ориентировано на действие, предлагает решение.

— Нужно переработать сценарий оплаты;
— Нужно упростить форму регистрации до трёх шагов;
— Рекомендуется добавить подсказки внутри полей;
— Следует оптимизировать изображения для ускорения загрузки.

(Рекомендации — это то, что чаще всего ждут от дизайнера, потому что они продвигают к изменениям)


4️⃣ Утверждение-гипотеза — условное предположение о возможном результате изменений.

— Если мы добавим прогресс-бар, пользователи будут чаще завершать оплату;
— Добавление прогресс-бара улучшит восприятие формы оформления заказа;
— Сокращение количества полей в форме регистрации повысит её завершение;
— Если добавить визуальные подсказки, пользователи будут быстрее находить нужный раздел;
— Адаптация интерфейса под мобильный формат снизит показатель отказов;
— Добавление превью товара на этапе оплаты снизит число возвратов;

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

Аргументация дизайна. Часть 3

Данные / Основания (Data / Grounds) — это факты, наблюдения, метрики или инсайты, на которых основано Утверждение (Claim).

Например:
— В среднем пользователи совершают 3 попытки оплаты, и 20% не завершают оформление заказа;
— На A/B-тесте вариант B показал рост конверсии на 15%.

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

☝️ Факты — это достоверная информация, а интерпретации — это наши галлюцинации.


Объясню по порядку.

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

Как понять что факт — это факт:
— можно проверить независимыми методами;
— результат проверки будет одинаков при повторении;
— не зависит от субъективного мнения.

Например:
— Среднее время заполнения формы — 1,5 минуты;
— В ходе тестирования 5 из 7 участников нажали на не ту кнопку на третьем шаге.

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



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


То есть это интерпретация когда:
— Основание различается у разных специалистов при одинаковых исходных данных;
— Часто содержит оценочные или вероятностные слова.

Например:
— Пользователи путаются в сценарии оплаты;

(Это интерпретация факта, что 27% пользователей не завершают оплату. Интерпретация в слове «путаются». Они может не путаются, а наоборот разбираются и намеренно завершают оплату, поняв невыгодность условий доставки)


⚜️ Или вот, например, классика:

Факт: «Пользователи не нажимают кнопку».
Интерпретация: «Пользователи не видят кнопку»

Как сделать интерпретацию фактом:

Например, проверить методом Eye tracking. Тогда возможные факты:

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

Аргументация дизайна. Часть 4

Гарантия (Warrant) объясняет, почему из Данных (Data) логично следует Утверждение (Claim). Это «мост» между наблюдаемым и утверждаемым.

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

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

🤔 Пример великого заблуждения:

Утверждение
— Новый дизайн уменьшает когнитивную нагрузку;

Основание
— Форма стала на 50% короче, количество полей уменьшено с 12 до 5;

Гарантия
— Если человек делает меньше шагов — он тратит меньше усилий.

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

То есть по факту, полей стало меньше, а время заполнения — дольше. Усталость — выше. Сомнений — больше.


☝️ Реальный кейс:

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

Главный вопрос, который нужно задать:

Почему из этих данных можно сделать именно такой вывод?

Аргументация дизайна. Часть 5

Подкрепление гарантии (Backing) — это доводы (факты, исследования, авторитетные источники или эмпирические данные) в поддержку Гарантии, если Гарантия подвергается сомнению. Что, на самом деле, очень разумно.

Чаще всего это ссылка на более широкую систему знаний: экспертизу или описанные ранее правила.

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

🔸В науке подкреплением являются научные эксперименты, доказанные теории и законы.
🔸В бизнесе — это часто отраслевые стандарты, прецеденты или статистика.
🔸В дизайне мы используем гайдлайны, результаты usability-тестов и данные проведённых ранее похожих по смыслу A/B-экспериментов.

Например:
— Согласно исследованиям Nielsen Norman Group, сценарии с более 2 шагов и без прогресса-бара имеют в 1.5 раза больше отказов;
— Какое-то там исследование показывает, что лишние поля в форме увеличивают показатель отказа на 25%.

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

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

В общем, это нужно для устранения сомнений.

Аргументация дизайна. Часть 6

Модальность / Степень уверенности (Qualifier) — указывает, насколько обосновано Утверждение: при каких условиях, с какой вероятностью, в каком объёме или в каком контексте утверждение считается справедливым.

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


То есть модальность:

1️⃣ Делает аргумент гибче и реалистичнее;
2️⃣ Снижает категоричность утвержденияи и показывает, что вывод не претендует на абсолютную истину;
3️⃣ Помогает дизайнеру звучать более честно и профессионально;
4️⃣ Служит переходом к Потенциальному опровержению.


Например:
— Вероятно, новый сценарий будет восприниматься как более удобный…
— В текущей версии customer journey…
— Скорее всего, эффект будет заметен только для…
— Почти наверняка улучшение загрузки…
— Предположительно, мобильные юзеры…
— В редких случаях на слабом интернете может не загружаться…
— Есть основания полагать, что люди постарше не справятся с…

Аргументация дизайна. Часть 7

Потенциальное опровержение / Условие, при котором тезис не работает (Rebuttal) — это условия, при которых утверждение может быть оспорено или признано неприменимым. То есть по сути это такая форма превентивного возражения, встроенная внутрь аргумента.


Нужно для того, чтобы:
— Показать, что дизайнер учёл контекст и альтернативные сценарии;
— Делает аргумент более устойчивым, предвосхищая критику;
— Тоже показывает честность и профессиональную зрелость дизайнера.


Опровержение чаще всего формулируется как условие или исключение:
— За исключением случаев, когда…
— Но не тогда, когда…
— Если только не…
— Кроме ситуации, когда
— Только при условии, если…
— Если не учитывать ситуации, при которых…
— Кроме пользователей, у которых…
— Это не относится к…
— При наличии Z…


Пример:
— Кроме сценариев для B2B-клиентов;
— В старых браузерах автозаполнение может не сработать;
— На маленьких смартфон кнопка не будет помещаться в первый экран.

Вместе с Утверждением Опровержение будет звучать следующим образом:

Пример с пушами:
Claim:

— Push-уведомления вернут пользователей в приложение...

Rebuttal:

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

Пример с онбордингом:
Claim:

— Сценарий онбординга повысит retention...

Rebuttal:

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

Аргументация дизайна. Часть 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. Убедиться в значимости изменений и раскатать изменения на всю аудиторию.

Вы великолепны 👑

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

Как дизайнеру быть убедительным. Леонид Ивахов

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

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

Упомянутый в выпуске пост с раскрытием темы можно найти по этой ссылке

Вопросы для Лёни можно оставить в комментариях к выпуску

👉 Слушать в телеграм-плеере

👉 Слушать в Apple

👉 Слушать в Яндексе

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

Вместо одного эксперта на next level, я собрал несколько человек в мульти-коллабу на next level

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

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

Приходите! 💥