Аргументация дизайна. Часть 1
Для того чтобы дизайнеру быть убедительным в процессе обсуждения дизайна можно использовать специальную технику. Она пригодится во время демонстрации дизайна арт-директору или команде.
Дизайнер, который умеет быть убедительным:
1. Сам лучше верит в те изменения, которые предлагает
2. Обладает большим авторитетом в глазах коллег, заказчика и своего руководителя.
Мне не нравятся концепции «защиты» или «продажи» дизайна. Защита подразумевает нападение, а я не вижу смысла нападать на чью-то идею. Потому что творческий коллектив нацелен на совместное изобретение, а значит должны работать принципы совместного додумывания и улучшения идей. Но обосновать изменения всё-таки придётся, и будет здорово, если обоснование будет последовательным, стройным и логичным. Для этого можно использовать модель аргументации Стивена Тулмина.
Стивен Тулмин — британский философ, логик и теоретик аргументации, один из ключевых мыслителей XX века в области прикладной логики и риторики.
Он разработал модель аргументации, которая состоит из шести компонентов, три из которых являются обязательными, а три — вспомогательными, которые обеспечивают гибкость и обоснованность в процессе убеждения.
Сначала коротко, а потом я раскрою подробно каждый компонент:
1. Тезис (Claim) — то, что вы утверждаете.
2. Данные (Data) — факты, на которые опираетесь.
3. Гарантия (Warrant) — логическая связь между фактами и тезисом.
4. Основание гарантии (Backing) — доказательства, почему эта связь надёжна.
5. Ограничение (Qualifier) — степень уверенности в тезисе.
6. Опровержение (Rebuttal) — признание условий, при которых ваш тезис не сработает.
Для того чтобы дизайнеру быть убедительным в процессе обсуждения дизайна можно использовать специальную технику. Она пригодится во время демонстрации дизайна арт-директору или команде.
Дизайнер, который умеет быть убедительным:
1. Сам лучше верит в те изменения, которые предлагает
2. Обладает большим авторитетом в глазах коллег, заказчика и своего руководителя.
Мне не нравятся концепции «защиты» или «продажи» дизайна. Защита подразумевает нападение, а я не вижу смысла нападать на чью-то идею. Потому что творческий коллектив нацелен на совместное изобретение, а значит должны работать принципы совместного додумывания и улучшения идей. Но обосновать изменения всё-таки придётся, и будет здорово, если обоснование будет последовательным, стройным и логичным. Для этого можно использовать модель аргументации Стивена Тулмина.
Стивен Тулмин — британский философ, логик и теоретик аргументации, один из ключевых мыслителей XX века в области прикладной логики и риторики.
Он разработал модель аргументации, которая состоит из шести компонентов, три из которых являются обязательными, а три — вспомогательными, которые обеспечивают гибкость и обоснованность в процессе убеждения.
Сначала коротко, а потом я раскрою подробно каждый компонент:
1. Тезис (Claim) — то, что вы утверждаете.
2. Данные (Data) — факты, на которые опираетесь.
3. Гарантия (Warrant) — логическая связь между фактами и тезисом.
4. Основание гарантии (Backing) — доказательства, почему эта связь надёжна.
5. Ограничение (Qualifier) — степень уверенности в тезисе.
6. Опровержение (Rebuttal) — признание условий, при которых ваш тезис не сработает.
❤8🔥4
Аргументация дизайна. Часть 2
Утверждение (Claim) — это то, что мы предлагаем принять как некоторую позицию, которая требует обоснования. А всё остальное (данные, гарантия, обоснование, ограничения и опровержение) служит для его поддержки или уточнения.
Далее я буду использовать примеры из типового сценария оплаты в интернет-магазине. Ну или что-нибудь похожее по смыслу и сложности.
Утверждения бывают разные:
1️⃣ Утверждение-наблюдение — констатация наблюдаемого или измеренного.
— Пользователи путаются в сценарии оплаты;
— 70% пользователей закрывают форму на шаге ввода адреса;
— Среднее время заполнения анкеты — 6 минут;
— Мобильная версия сайта загружается 8 секунд;
2️⃣ Утверждение-оценка — интерпретация или субъективное суждение, основанное на опыте или наблюдении.
— Этот интерфейс неудобен для новых пользователей;
— Процесс регистрации слишком длинный для первого входа;
— Форма выглядит перегруженной для маленького экрана;
(Это нормально оперировать оценкой, если у нас нет измеримых данных, тогда мы обращаемся к опыту)
3️⃣ Утверждение-рекомендация — ориентировано на действие, предлагает решение.
— Нужно переработать сценарий оплаты;
— Нужно упростить форму регистрации до трёх шагов;
— Рекомендуется добавить подсказки внутри полей;
— Следует оптимизировать изображения для ускорения загрузки.
(Рекомендации — это то, что чаще всего ждут от дизайнера, потому что они продвигают к изменениям)
4️⃣ Утверждение-гипотеза — условное предположение о возможном результате изменений.
— Если мы добавим прогресс-бар, пользователи будут чаще завершать оплату;
— Добавление прогресс-бара улучшит восприятие формы оформления заказа;
— Сокращение количества полей в форме регистрации повысит её завершение;
— Если добавить визуальные подсказки, пользователи будут быстрее находить нужный раздел;
— Адаптация интерфейса под мобильный формат снизит показатель отказов;
— Добавление превью товара на этапе оплаты снизит число возвратов;
(Нужно понимать что любая идея по сути всегда является гипотезой, которая требует проверки на правдивость. О том как вообще строятся гипотезы я тоже как-нибудь напишу)
Утверждение (Claim) — это то, что мы предлагаем принять как некоторую позицию, которая требует обоснования. А всё остальное (данные, гарантия, обоснование, ограничения и опровержение) служит для его поддержки или уточнения.
Далее я буду использовать примеры из типового сценария оплаты в интернет-магазине. Ну или что-нибудь похожее по смыслу и сложности.
Утверждения бывают разные:
1️⃣ Утверждение-наблюдение — констатация наблюдаемого или измеренного.
— Пользователи путаются в сценарии оплаты;
— 70% пользователей закрывают форму на шаге ввода адреса;
— Среднее время заполнения анкеты — 6 минут;
— Мобильная версия сайта загружается 8 секунд;
2️⃣ Утверждение-оценка — интерпретация или субъективное суждение, основанное на опыте или наблюдении.
— Этот интерфейс неудобен для новых пользователей;
— Процесс регистрации слишком длинный для первого входа;
— Форма выглядит перегруженной для маленького экрана;
(Это нормально оперировать оценкой, если у нас нет измеримых данных, тогда мы обращаемся к опыту)
3️⃣ Утверждение-рекомендация — ориентировано на действие, предлагает решение.
— Нужно переработать сценарий оплаты;
— Нужно упростить форму регистрации до трёх шагов;
— Рекомендуется добавить подсказки внутри полей;
— Следует оптимизировать изображения для ускорения загрузки.
(Рекомендации — это то, что чаще всего ждут от дизайнера, потому что они продвигают к изменениям)
4️⃣ Утверждение-гипотеза — условное предположение о возможном результате изменений.
— Если мы добавим прогресс-бар, пользователи будут чаще завершать оплату;
— Добавление прогресс-бара улучшит восприятие формы оформления заказа;
— Сокращение количества полей в форме регистрации повысит её завершение;
— Если добавить визуальные подсказки, пользователи будут быстрее находить нужный раздел;
— Адаптация интерфейса под мобильный формат снизит показатель отказов;
— Добавление превью товара на этапе оплаты снизит число возвратов;
(Нужно понимать что любая идея по сути всегда является гипотезой, которая требует проверки на правдивость. О том как вообще строятся гипотезы я тоже как-нибудь напишу)
❤6🔥2
Аргументация дизайна. Часть 3
Данные / Основания (Data / Grounds) — это факты, наблюдения, метрики или инсайты, на которых основано Утверждение (Claim).
Например:
— В среднем пользователи совершают 3 попытки оплаты, и 20% не завершают оформление заказа;
— На A/B-тесте вариант B показал рост конверсии на 15%.
Основания часто являются частью формулировки утверждения-наблюдения, но самое важно — это разделять факты от интерпретаций.
☝️ Факты — это достоверная информация, а интерпретации — это наши галлюцинации.
Объясню по порядку.
⚫ Факты — это объективные, проверяемые сведения, которые можно зафиксировать, воспроизвести или измерить. Они описывают то, что произошло или наблюдается, без добавления оценок или предположений.
Как понять что факт — это факт:
— можно проверить независимыми методами;
— результат проверки будет одинаков при повторении;
— не зависит от субъективного мнения.
Например:
— Среднее время заполнения формы — 1,5 минуты;
— В ходе тестирования 5 из 7 участников нажали на не ту кнопку на третьем шаге.
Теперь самое интересное, из-за чего обычно возникают все споры, сомнения в экспертности экспертов, а дизайнер часто звучит неубедительно.
⚫ Интерпретации — это выводы, объяснения или оценки, сделанные на основе фактов. Интерпретации могут преломлять факт через призму опыта, заблуждений, убеждений, иллюзий, искажённой логики рассуждения и тд.
То есть это интерпретация когда:
— Основание различается у разных специалистов при одинаковых исходных данных;
— Часто содержит оценочные или вероятностные слова.
Например:
— Пользователи путаются в сценарии оплаты;
(Это интерпретация факта, что 27% пользователей не завершают оплату. Интерпретация в слове «путаются». Они может не путаются, а наоборот разбираются и намеренно завершают оплату, поняв невыгодность условий доставки)
⚜️ Или вот, например, классика:
Факт: «Пользователи не нажимают кнопку».
Интерпретация: «Пользователи не видят кнопку»
Как сделать интерпретацию фактом:
Например, проверить методом Eye tracking. Тогда возможные факты:
— Респондент не видит элемент, потому что он незаметный, или соседние элементы отвлекают внимание
— видит, но не понимает смысл (не ассоциирует что он интерактивный), потому что элемент выглядит как декоративный приём (оформление)
— видит, но не ассоциирует со своей задачей, потому что название или внешний вид элемента вводит заблуждение
— видит, понимает, ассоциирует, но опасается нажимать, элемент не подсказывает что будет дальше после взаимодействия
Данные / Основания (Data / Grounds) — это факты, наблюдения, метрики или инсайты, на которых основано Утверждение (Claim).
Например:
— В среднем пользователи совершают 3 попытки оплаты, и 20% не завершают оформление заказа;
— На A/B-тесте вариант B показал рост конверсии на 15%.
Основания часто являются частью формулировки утверждения-наблюдения, но самое важно — это разделять факты от интерпретаций.
☝️ Факты — это достоверная информация, а интерпретации — это наши галлюцинации.
Объясню по порядку.
⚫ Факты — это объективные, проверяемые сведения, которые можно зафиксировать, воспроизвести или измерить. Они описывают то, что произошло или наблюдается, без добавления оценок или предположений.
Как понять что факт — это факт:
— можно проверить независимыми методами;
— результат проверки будет одинаков при повторении;
— не зависит от субъективного мнения.
Например:
— Среднее время заполнения формы — 1,5 минуты;
— В ходе тестирования 5 из 7 участников нажали на не ту кнопку на третьем шаге.
Теперь самое интересное, из-за чего обычно возникают все споры, сомнения в экспертности экспертов, а дизайнер часто звучит неубедительно.
⚫ Интерпретации — это выводы, объяснения или оценки, сделанные на основе фактов. Интерпретации могут преломлять факт через призму опыта, заблуждений, убеждений, иллюзий, искажённой логики рассуждения и тд.
То есть это интерпретация когда:
— Основание различается у разных специалистов при одинаковых исходных данных;
— Часто содержит оценочные или вероятностные слова.
Например:
— Пользователи путаются в сценарии оплаты;
(Это интерпретация факта, что 27% пользователей не завершают оплату. Интерпретация в слове «путаются». Они может не путаются, а наоборот разбираются и намеренно завершают оплату, поняв невыгодность условий доставки)
⚜️ Или вот, например, классика:
Факт: «Пользователи не нажимают кнопку».
Интерпретация: «Пользователи не видят кнопку»
Как сделать интерпретацию фактом:
Например, проверить методом Eye tracking. Тогда возможные факты:
— Респондент не видит элемент, потому что он незаметный, или соседние элементы отвлекают внимание
— видит, но не понимает смысл (не ассоциирует что он интерактивный), потому что элемент выглядит как декоративный приём (оформление)
— видит, но не ассоциирует со своей задачей, потому что название или внешний вид элемента вводит заблуждение
— видит, понимает, ассоциирует, но опасается нажимать, элемент не подсказывает что будет дальше после взаимодействия
🔥4
Аргументация дизайна. Часть 4
Гарантия (Warrant) объясняет, почему из Данных (Data) логично следует Утверждение (Claim). Это «мост» между наблюдаемым и утверждаемым.
Обычно мы считаем её самоочевидной, поэтому можем опускать и не произносить. Но именно гарантия делает аргумент логически валидным, иначе мы просто имеем два разрозненных утверждения: факт и мнение, которые не соединены между собой.
Пример:
— Если пользователи тратят много времени и делают ошибки — сценарий неудобен;
— Если пользователи чаще завершают оплату, значит сценарий стал эффективнее.
🤔 Пример великого заблуждения:
Утверждение
— Новый дизайн уменьшает когнитивную нагрузку;
Основание
— Форма стала на 50% короче, количество полей уменьшено с 12 до 5;
Гарантия
— Если человек делает меньше шагов — он тратит меньше усилий.
Дело в том что полей или, например, шагов оформления заказа стало меньше, но при этом каждый шаг, каждое поле стали сами по себе сложнее. То есть на каждом этапе нужно внимательнее вдумываться и разбираться в условиях и корректности взаимодействия.
То есть по факту, полей стало меньше, а время заполнения — дольше. Усталость — выше. Сомнений — больше.
☝️ Реальный кейс:
Главный вопрос, который нужно задать:
Почему из этих данных можно сделать именно такой вывод?
Гарантия (Warrant) объясняет, почему из Данных (Data) логично следует Утверждение (Claim). Это «мост» между наблюдаемым и утверждаемым.
Обычно мы считаем её самоочевидной, поэтому можем опускать и не произносить. Но именно гарантия делает аргумент логически валидным, иначе мы просто имеем два разрозненных утверждения: факт и мнение, которые не соединены между собой.
Пример:
— Если пользователи тратят много времени и делают ошибки — сценарий неудобен;
— Если пользователи чаще завершают оплату, значит сценарий стал эффективнее.
🤔 Пример великого заблуждения:
Утверждение
— Новый дизайн уменьшает когнитивную нагрузку;
Основание
— Форма стала на 50% короче, количество полей уменьшено с 12 до 5;
Гарантия
— Если человек делает меньше шагов — он тратит меньше усилий.
Дело в том что полей или, например, шагов оформления заказа стало меньше, но при этом каждый шаг, каждое поле стали сами по себе сложнее. То есть на каждом этапе нужно внимательнее вдумываться и разбираться в условиях и корректности взаимодействия.
То есть по факту, полей стало меньше, а время заполнения — дольше. Усталость — выше. Сомнений — больше.
☝️ Реальный кейс:
Когда мы в Билайне делали сценарий привязи банковской карты для автоплатежей, там не требовался CVV. И люди тормозились и не привязывали карты. Оказывается, они по привычке искали куда вводить CVV, думали что у них не отображается поле. То есть поле убрали, а прохождение сценария усложнили.
Главный вопрос, который нужно задать:
Почему из этих данных можно сделать именно такой вывод?
❤3
Аргументация дизайна. Часть 5
Подкрепление гарантии (Backing) — это доводы (факты, исследования, авторитетные источники или эмпирические данные) в поддержку Гарантии, если Гарантия подвергается сомнению. Что, на самом деле, очень разумно.
Чаще всего это ссылка на более широкую систему знаний: экспертизу или описанные ранее правила.
Подкрепление гарантии — это доказательство того, что логика перехода от основания / данных к утверждению каким-то образом обоснована. Потому что в процессе аргументации возникает вопрос: а почему мы решили что эта логика адекватна?
🔸В науке подкреплением являются научные эксперименты, доказанные теории и законы.
🔸В бизнесе — это часто отраслевые стандарты, прецеденты или статистика.
🔸В дизайне мы используем гайдлайны, результаты usability-тестов и данные проведённых ранее похожих по смыслу A/B-экспериментов.
Например:
— Согласно исследованиям Nielsen Norman Group, сценарии с более 2 шагов и без прогресса-бара имеют в 1.5 раза больше отказов;
— Какое-то там исследование показывает, что лишние поля в форме увеличивают показатель отказа на 25%.
Мы можем использовать известные бенчмарки, опыт предыдущих экспериментов и вообще любые эмпирические данные, если они являются показательными и релевантными для подкрепления.
То есть подкрепление гарантии — это не доказательство утверждения напрямую, а обоснование самого правила, по которому из данных / основания делается вывод.
В общем, это нужно для устранения сомнений.
Подкрепление гарантии (Backing) — это доводы (факты, исследования, авторитетные источники или эмпирические данные) в поддержку Гарантии, если Гарантия подвергается сомнению. Что, на самом деле, очень разумно.
Чаще всего это ссылка на более широкую систему знаний: экспертизу или описанные ранее правила.
Подкрепление гарантии — это доказательство того, что логика перехода от основания / данных к утверждению каким-то образом обоснована. Потому что в процессе аргументации возникает вопрос: а почему мы решили что эта логика адекватна?
🔸В науке подкреплением являются научные эксперименты, доказанные теории и законы.
🔸В бизнесе — это часто отраслевые стандарты, прецеденты или статистика.
🔸В дизайне мы используем гайдлайны, результаты usability-тестов и данные проведённых ранее похожих по смыслу A/B-экспериментов.
Например:
— Согласно исследованиям Nielsen Norman Group, сценарии с более 2 шагов и без прогресса-бара имеют в 1.5 раза больше отказов;
— Какое-то там исследование показывает, что лишние поля в форме увеличивают показатель отказа на 25%.
Мы можем использовать известные бенчмарки, опыт предыдущих экспериментов и вообще любые эмпирические данные, если они являются показательными и релевантными для подкрепления.
То есть подкрепление гарантии — это не доказательство утверждения напрямую, а обоснование самого правила, по которому из данных / основания делается вывод.
В общем, это нужно для устранения сомнений.
🔥3
Аргументация дизайна. Часть 6
Модальность / Степень уверенности (Qualifier) — указывает, насколько обосновано Утверждение: при каких условиях, с какой вероятностью, в каком объёме или в каком контексте утверждение считается справедливым.
Можно использовать такие формулировки:
«вероятно», «возможно», «скорее всего», «почти наверняка», «в редких случаях», «с большой вероятностью», «есть основания полагать, что», «по всей видимости», «предположительно», «в большинстве случаев» и тд.
То есть модальность:
1️⃣ Делает аргумент гибче и реалистичнее;
2️⃣ Снижает категоричность утвержденияи и показывает, что вывод не претендует на абсолютную истину;
3️⃣ Помогает дизайнеру звучать более честно и профессионально;
4️⃣ Служит переходом к Потенциальному опровержению.
Например:
— Вероятно, новый сценарий будет восприниматься как более удобный…
— В текущей версии customer journey…
— Скорее всего, эффект будет заметен только для…
— Почти наверняка улучшение загрузки…
— Предположительно, мобильные юзеры…
— В редких случаях на слабом интернете может не загружаться…
— Есть основания полагать, что люди постарше не справятся с…
Модальность / Степень уверенности (Qualifier) — указывает, насколько обосновано Утверждение: при каких условиях, с какой вероятностью, в каком объёме или в каком контексте утверждение считается справедливым.
Можно использовать такие формулировки:
«вероятно», «возможно», «скорее всего», «почти наверняка», «в редких случаях», «с большой вероятностью», «есть основания полагать, что», «по всей видимости», «предположительно», «в большинстве случаев» и тд.
То есть модальность:
1️⃣ Делает аргумент гибче и реалистичнее;
2️⃣ Снижает категоричность утвержденияи и показывает, что вывод не претендует на абсолютную истину;
3️⃣ Помогает дизайнеру звучать более честно и профессионально;
4️⃣ Служит переходом к Потенциальному опровержению.
Например:
— Вероятно, новый сценарий будет восприниматься как более удобный…
— В текущей версии customer journey…
— Скорее всего, эффект будет заметен только для…
— Почти наверняка улучшение загрузки…
— Предположительно, мобильные юзеры…
— В редких случаях на слабом интернете может не загружаться…
— Есть основания полагать, что люди постарше не справятся с…
🔥1
Аргументация дизайна. Часть 7
Потенциальное опровержение / Условие, при котором тезис не работает (Rebuttal) — это условия, при которых утверждение может быть оспорено или признано неприменимым. То есть по сути это такая форма превентивного возражения, встроенная внутрь аргумента.
Нужно для того, чтобы:
— Показать, что дизайнер учёл контекст и альтернативные сценарии;
— Делает аргумент более устойчивым, предвосхищая критику;
— Тоже показывает честность и профессиональную зрелость дизайнера.
Опровержение чаще всего формулируется как условие или исключение:
— За исключением случаев, когда…
— Но не тогда, когда…
— Если только не…
— Кроме ситуации, когда
— Только при условии, если…
— Если не учитывать ситуации, при которых…
— Кроме пользователей, у которых…
— Это не относится к…
— При наличии Z…
Пример:
— Кроме сценариев для B2B-клиентов;
— В старых браузерах автозаполнение может не сработать;
— На маленьких смартфон кнопка не будет помещаться в первый экран.
Вместе с Утверждением Опровержение будет звучать следующим образом:
Пример с пушами:
Claim:
Rebuttal:
Пример с онбордингом:
Claim:
Rebuttal:
Потенциальное опровержение / Условие, при котором тезис не работает (Rebuttal) — это условия, при которых утверждение может быть оспорено или признано неприменимым. То есть по сути это такая форма превентивного возражения, встроенная внутрь аргумента.
Нужно для того, чтобы:
— Показать, что дизайнер учёл контекст и альтернативные сценарии;
— Делает аргумент более устойчивым, предвосхищая критику;
— Тоже показывает честность и профессиональную зрелость дизайнера.
Опровержение чаще всего формулируется как условие или исключение:
— За исключением случаев, когда…
— Но не тогда, когда…
— Если только не…
— Кроме ситуации, когда
— Только при условии, если…
— Если не учитывать ситуации, при которых…
— Кроме пользователей, у которых…
— Это не относится к…
— При наличии Z…
Пример:
— Кроме сценариев для B2B-клиентов;
— В старых браузерах автозаполнение может не сработать;
— На маленьких смартфон кнопка не будет помещаться в первый экран.
Вместе с Утверждением Опровержение будет звучать следующим образом:
Пример с пушами:
Claim:
— Push-уведомления вернут пользователей в приложение...
Rebuttal:
…если только они не будут восприниматься как спам и не вызовут отток.
Пример с онбордингом:
Claim:
— Сценарий онбординга повысит retention...
Rebuttal:
…если только он не окажется слишком длинным и не отпугнёт нетерпеливых пользователей.
🔥2
Аргументация дизайна. Часть 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. Убедиться в значимости изменений и раскатать изменения на всю аудиторию.
Вы великолепны 👑
Наконец вышел выпуск про аргументацию. Там ещё про разные когнитивные искажения, которые часто вводят в заблуждение и мешают понимать друг друга 🥳
Forwarded from Подкаст «Дизайн Прост»
Как дизайнеру быть убедительным. Леонид Ивахов
У нас в гостях eх-арт-директор цифровых продуктов «Мой МТС» и автор телеграм-канала «Функции дизайна» – Леонид Ивахов. Лёня рассказал о том, как дизайнеру убеждать коллег и клиентов с помощью модели аргументации британского философа Стивена Е. Тулмина.
О том, как бороться с когнитивными и искажениями и как правильная формулировка может спасти или уничтожить аргументацию. А еще Леня рассказал как тренировать ИИ для тренировки скилов убеждения.
Упомянутый в выпуске пост с раскрытием темы можно найти по этой ссылке
Вопросы для Лёни можно оставить в комментариях к выпуску
👉 Слушать в телеграм-плеере
👉 Слушать в Apple
👉 Слушать в Яндексе
У нас в гостях eх-арт-директор цифровых продуктов «Мой МТС» и автор телеграм-канала «Функции дизайна» – Леонид Ивахов. Лёня рассказал о том, как дизайнеру убеждать коллег и клиентов с помощью модели аргументации британского философа Стивена Е. Тулмина.
О том, как бороться с когнитивными и искажениями и как правильная формулировка может спасти или уничтожить аргументацию. А еще Леня рассказал как тренировать ИИ для тренировки скилов убеждения.
Упомянутый в выпуске пост с раскрытием темы можно найти по этой ссылке
Вопросы для Лёни можно оставить в комментариях к выпуску
👉 Слушать в телеграм-плеере
👉 Слушать в Apple
👉 Слушать в Яндексе
❤4
Ультрапотрясающий Миша Розов позвал меня на свой курс NextLevel чтобы читать там курс лекций. Я буду рассказывать и проводить воркшопы на общую тему «Как быть дизайнером». А про то как делать дизайн расскажут другие топовые ребята ☺️
wannabe.ru
Интенсив для дизайнеров Next Level Concepts от Миши Розова
Научитесь проектировать омниканальные концепты будущего — эмоции, интерфейсы, 2D-анимация, AI-Gen, Spatial Design
🔥5
Forwarded from Wannabe like Rozov (Mike Rozov)
Вместо одного эксперта на next level, я собрал несколько человек в мульти-коллабу на next level
Лёня Ивахов называет себя путешествующим дизайн-директором — потому что у него за спиной и много лет одноклассников, и последняя дизайн-трансформация МТСа, и потому что при этом он много путешествует по вполне загадочным местам
Лёню я позвал по той причине, что унего есть большой корпоративный опыт, при этом широкое понимание как естественно и системно развиваться дизайнерам, о чем он и расскажет в нескольких лекциях на курсе
Лёня Ивахов называет себя путешествующим дизайн-директором — потому что у него за спиной и много лет одноклассников, и последняя дизайн-трансформация МТСа, и потому что при этом он много путешествует по вполне загадочным местам
Лёню я позвал по той причине, что унего есть большой корпоративный опыт, при этом широкое понимание как естественно и системно развиваться дизайнерам, о чем он и расскажет в нескольких лекциях на курсе
❤4🔥3
Forwarded from Wannabe like Rozov (Mike Rozov)
This media is not supported in your browser
VIEW IN TELEGRAM
Open talk Миши Розова и Лёни Ивахова: точки роста в карьере дизайнера
Системно поговорим про то как искать свои точки роста, чем здесь может помочь Customer Journey и перспектива: дизайнер — продукт, заказчик — пользователь.
Все это для того, чтобы понять, как достигать результатов и преодолевать потолок, когда кажется, что ты застрял и пути наверх уже нет.
Встречаемся 9 сентября в 19:00 по мск.
👉 Регистрация через бот
Системно поговорим про то как искать свои точки роста, чем здесь может помочь Customer Journey и перспектива: дизайнер — продукт, заказчик — пользователь.
Все это для того, чтобы понять, как достигать результатов и преодолевать потолок, когда кажется, что ты застрял и пути наверх уже нет.
Встречаемся 9 сентября в 19:00 по мск.
👉 Регистрация через бот
🔥3
Forwarded from Дизайн-кружок WANNABE| открытые мероприятия
Привет! Это Лёня Ивахов, дизайн-директор (ex-Билайн, Одноклассники, МТС).
Есть интересная мысль для вас — если вы уже middle, делаете работу хорошо, но возникают вопросики:
→ что я реально даю бизнесу и людям?
→ почему другие растут, а я топчусь?
→ где моя ценность, за что готовы платить?
Чтобы ответить на них, вам придётся изучать потребности ваших клиентов и заказчиков и сформулировать ценность, которую вы можете им предложить как дизайнеры.
И если вы сможете дать эту ценность, а ваши клиенты будут готовы за неё платить, то это будет тот самый Product Market Fit, о котором так много говорят.
Где вы — Product, о котором клиенты должны узнать и понять, как с вами делать дела, а Market — это клиенты, которым нужен дизайн. А Fit — ваш идеальный мэтч 🩶
Сегодня, 9 сентября, в 19:00 по мск, я проведу целую лекцию, где мы с Мишей Розовым разберём путь клиента до вас, чтобы вас можно было легко найти, сложно потерять и невозможно забыть.
Для этого нам понадобится разобраться, что же такое Customer Journey на самом деле, как устроены точки контакта клиента и дизайнера, и где там рост.
Приходите, чтобы не набивать шишки самим и учиться на моем опыте.
Зарегистрируйтесь через бота, если хотите задать свой вопрос, точно получить все материалы ивента и ничего не пропустить.
👉 https://t.me/wnbl_rozova_bot?start=w43983247
Есть интересная мысль для вас — если вы уже middle, делаете работу хорошо, но возникают вопросики:
→ что я реально даю бизнесу и людям?
→ почему другие растут, а я топчусь?
→ где моя ценность, за что готовы платить?
Чтобы ответить на них, вам придётся изучать потребности ваших клиентов и заказчиков и сформулировать ценность, которую вы можете им предложить как дизайнеры.
И если вы сможете дать эту ценность, а ваши клиенты будут готовы за неё платить, то это будет тот самый Product Market Fit, о котором так много говорят.
Где вы — Product, о котором клиенты должны узнать и понять, как с вами делать дела, а Market — это клиенты, которым нужен дизайн. А Fit — ваш идеальный мэтч 🩶
Сегодня, 9 сентября, в 19:00 по мск, я проведу целую лекцию, где мы с Мишей Розовым разберём путь клиента до вас, чтобы вас можно было легко найти, сложно потерять и невозможно забыть.
Для этого нам понадобится разобраться, что же такое Customer Journey на самом деле, как устроены точки контакта клиента и дизайнера, и где там рост.
Приходите, чтобы не набивать шишки самим и учиться на моем опыте.
Зарегистрируйтесь через бота, если хотите задать свой вопрос, точно получить все материалы ивента и ничего не пропустить.
👉 https://t.me/wnbl_rozova_bot?start=w43983247
Митя Осадчук недавно на курсе Next Level ребятам рассказывал про метод прогрессивного джипега. И показал на сайте Лебедева ководство от 2010го. И когда сказал что раньше джипег грузился сверху вниз, я себя почувствовал старым 🥲
А потом показал уровни дизайна Джесса Джеймса Гарретта. И это был контрольный 🔫
С Днём рождения, Митя Осадчук! ♥️
А потом показал уровни дизайна Джесса Джеймса Гарретта. И это был контрольный 🔫
С Днём рождения, Митя Осадчук! ♥️
❤3🎉3👏1
Всем привет!
1 октября стартует курс Next Level UI, на котором в коллабе с Мишей Розовым, Виталей Рынским и Максом Десятых я прочитаю сразу 3 лекции, посвящённые лидерству в дизайне и как быть дизайнером:
1️⃣ Стили управления в дизайне. Матрица ролей Адизеса.
2️⃣ Модель измений и работа с ограничивающими убеждениями. Пирамида нейрологических уровней Дилтса.
3️⃣ Мотивация. Какая бывает и откуда берётся.
Про что коллаба в целом:
— Эта коллаборация даст самые глубокие знания и современные технологии для выразительного насыщенного UI.
— Будут еженедельные воркшопы и лекции, чтобы вы не теряли мотивацию.
— В конце — просмотр портфолио/кейсов от приглашенных экспертов
Условия:
— Чтобы присоединиться к коллаборации, нужно занять место до 30 сентября включительно.
— Самые известные дизайнеры индустрии, помогут разобраться в психологии и модели развития личности, чтобы вы были непобедимы в карьере.
— Есть небольшая интенсивная группа, туда набираем всего 40 человек. Осталось 18 мест.
— Занятия будут проходить в октябре и ноябре.
Next Level UI — это курс для дизайнеров, которые хотят выйти на международный уровень!
👉 Почитать подробнее и успеть в последний вагон 👈
1 октября стартует курс Next Level UI, на котором в коллабе с Мишей Розовым, Виталей Рынским и Максом Десятых я прочитаю сразу 3 лекции, посвящённые лидерству в дизайне и как быть дизайнером:
1️⃣ Стили управления в дизайне. Матрица ролей Адизеса.
2️⃣ Модель измений и работа с ограничивающими убеждениями. Пирамида нейрологических уровней Дилтса.
3️⃣ Мотивация. Какая бывает и откуда берётся.
Про что коллаба в целом:
— Эта коллаборация даст самые глубокие знания и современные технологии для выразительного насыщенного UI.
— Будут еженедельные воркшопы и лекции, чтобы вы не теряли мотивацию.
— В конце — просмотр портфолио/кейсов от приглашенных экспертов
Условия:
— Чтобы присоединиться к коллаборации, нужно занять место до 30 сентября включительно.
— Самые известные дизайнеры индустрии, помогут разобраться в психологии и модели развития личности, чтобы вы были непобедимы в карьере.
— Есть небольшая интенсивная группа, туда набираем всего 40 человек. Осталось 18 мест.
— Занятия будут проходить в октябре и ноябре.
Next Level UI — это курс для дизайнеров, которые хотят выйти на международный уровень!
👉 Почитать подробнее и успеть в последний вагон 👈
🔥2
Аргументация дизайна. Часть 9. Лучшие практики (Best Practices)
Когда мы ищем подкрепление / основание гарантии (Backing) в процессе аргументации дизайна, то чаще всего начинаем с поиска лучших практик. Нам кажется, что если кто-то это уже это сделал, то вероятность того, что наша гипотеза попадает в точку, повышается. Тут важно не попасть в когнитивное искажение и не словить иллюзию ложного подтверждения.
Нужно понимать следующее:
1️⃣ Это решение делают такие жи дизайнеры, и они могут ошибаться.
2️⃣ Это решение может быть невалидированной гипотезой, которая в данный момент просто тестируется.
3️⃣ Это решение делали наспех в условиях ограниченных ресурсов, и оно может быть просто временным.
4️⃣ Контекст и задача этого решения совсем неочевидна, и цель такого дизайна совсем в другом.
Раньше найти коллекцию UI/UX-кейсов было практически невозможно. Сейчас их нужно собирать по крупицам и накапливать свою базу знаний и понимания.
2 года назад, когда я работал в МТС, я сам вручную проводил анализ экосистмной связанности Сбера, Яндекса, Тинькофф и тд. Я вручную авторизовывался, решал одни и те же типовые задачи по поиску единиц контент и товаров, оформлял заказы, проводил платежи, анализировал методы коммуникации с клиентом и пр. Это занимает огромное кол-во времени, но зато позволяет найти огромное кол-во интересных и неочевидных решений, которые обычно не на виду.
Сейчас такие решения можно поискать, например, в ScreenBook — коллекции скриншотов российских мобильных приложений для iOS и Android. Можно искать по экранам 📱, UI-элементам и даже анимациям ✨
Экономит кучу времени и сил. Но будьте категоричнее в оценке референсов: анализируйте удачность этого решения относительно задачи, и постарайтесь попробовать использовать эти решения вживую.
Ещё рекомендую тг-канал, куда публикуются обновления контента: 📲@ux_advocate
А я дальше напишу про когнитивные искажения.
Когда мы ищем подкрепление / основание гарантии (Backing) в процессе аргументации дизайна, то чаще всего начинаем с поиска лучших практик. Нам кажется, что если кто-то это уже это сделал, то вероятность того, что наша гипотеза попадает в точку, повышается. Тут важно не попасть в когнитивное искажение и не словить иллюзию ложного подтверждения.
Нужно понимать следующее:
если это существует — это не значит, что это хорошее решение.
1️⃣ Это решение делают такие жи дизайнеры, и они могут ошибаться.
2️⃣ Это решение может быть невалидированной гипотезой, которая в данный момент просто тестируется.
3️⃣ Это решение делали наспех в условиях ограниченных ресурсов, и оно может быть просто временным.
4️⃣ Контекст и задача этого решения совсем неочевидна, и цель такого дизайна совсем в другом.
Раньше найти коллекцию UI/UX-кейсов было практически невозможно. Сейчас их нужно собирать по крупицам и накапливать свою базу знаний и понимания.
2 года назад, когда я работал в МТС, я сам вручную проводил анализ экосистмной связанности Сбера, Яндекса, Тинькофф и тд. Я вручную авторизовывался, решал одни и те же типовые задачи по поиску единиц контент и товаров, оформлял заказы, проводил платежи, анализировал методы коммуникации с клиентом и пр. Это занимает огромное кол-во времени, но зато позволяет найти огромное кол-во интересных и неочевидных решений, которые обычно не на виду.
Сейчас такие решения можно поискать, например, в ScreenBook — коллекции скриншотов российских мобильных приложений для iOS и Android. Можно искать по экранам 📱, UI-элементам и даже анимациям ✨
Экономит кучу времени и сил. Но будьте категоричнее в оценке референсов: анализируйте удачность этого решения относительно задачи, и постарайтесь попробовать использовать эти решения вживую.
Ещё рекомендую тг-канал, куда публикуются обновления контента: 📲@ux_advocate
А я дальше напишу про когнитивные искажения.
🔥4❤1
Леонид Ивахов
А я дальше напишу про когнитивные искажения.
Чтобы написать подробно про когнитивные искажения, пришлось хорошенько разобраться в том, откуда они берутся и как устроено наше мышление в целом.
И тут пришлось перелопатить кучу всего:
1️⃣ Прочитать довольно непростую книгу нобелевского лаурета Даниэля Канемана «Думай медленно, решай быстро».
Там все возможные искажения описаны на примере экспериментов.
Там про две системы мышления: быструю и медленную. И про то как быстрая лихо упрощает восприятие реальности, что приводит к искажениям.
2️⃣ Понять что искажения являются частью структуры убеждений. А здесь просто невероятный океан интересного.
От того какие виды убеждений существуют и как они связаны с ценностями.
3️⃣ Пришлось посмотреть пару курсов про работу с ограничивающими убеждениями.
А там кроме классических НЛП-техник, которые используются в коучинге, ещё и новейшие психотехники типа EMDR (Eye Movement Desensitization and Reprocessing, оно же ДПДГ - Десенсибилизация и переработка движениями глаз).
4️⃣ Написать лекцию для курса WANNABE для дизайнеров с примерами ограничивающих убеждений и методами, превращающими их в расширяющие убеждения.
А поскольку процесс этот очень часто бесючий, то показать как в структуре эго-состояний это можно реализовать с заботой и любовью к себе.
5️⃣ И ценность всего этого хочется показать на примере нейрологических уровней Роберта Дилтса.
Там сразу становится понятно как убеждения, и лежащие в основе них когнитивные искажения, знатно так мешают нам строить дизайнерский карьерный трек и быть счастливыми :)
А ещё его книга «Фокусы языка» даёт множество инструментов эффективной работы с убеждениями. Книга не такая сложная как у Канемана, рекомендую.
___
В общем, даже не знаю с какой стороны подойти, чтобы всё это начать публиковать в формате канала 😂
___
Но зато ещё я успел побывать в Папуа — Новая Гвинея 🇵🇬, ЮАР 🇿🇦 и Японии 🇯🇵. И очень хорошо прочувствавать нашу способность строить иллюзии и страдать от них 😂
И тут пришлось перелопатить кучу всего:
1️⃣ Прочитать довольно непростую книгу нобелевского лаурета Даниэля Канемана «Думай медленно, решай быстро».
Там все возможные искажения описаны на примере экспериментов.
Там про две системы мышления: быструю и медленную. И про то как быстрая лихо упрощает восприятие реальности, что приводит к искажениям.
2️⃣ Понять что искажения являются частью структуры убеждений. А здесь просто невероятный океан интересного.
От того какие виды убеждений существуют и как они связаны с ценностями.
3️⃣ Пришлось посмотреть пару курсов про работу с ограничивающими убеждениями.
А там кроме классических НЛП-техник, которые используются в коучинге, ещё и новейшие психотехники типа EMDR (Eye Movement Desensitization and Reprocessing, оно же ДПДГ - Десенсибилизация и переработка движениями глаз).
4️⃣ Написать лекцию для курса WANNABE для дизайнеров с примерами ограничивающих убеждений и методами, превращающими их в расширяющие убеждения.
А поскольку процесс этот очень часто бесючий, то показать как в структуре эго-состояний это можно реализовать с заботой и любовью к себе.
5️⃣ И ценность всего этого хочется показать на примере нейрологических уровней Роберта Дилтса.
Там сразу становится понятно как убеждения, и лежащие в основе них когнитивные искажения, знатно так мешают нам строить дизайнерский карьерный трек и быть счастливыми :)
А ещё его книга «Фокусы языка» даёт множество инструментов эффективной работы с убеждениями. Книга не такая сложная как у Канемана, рекомендую.
___
В общем, даже не знаю с какой стороны подойти, чтобы всё это начать публиковать в формате канала 😂
___
Но зато ещё я успел побывать в Папуа — Новая Гвинея 🇵🇬, ЮАР 🇿🇦 и Японии 🇯🇵. И очень хорошо прочувствавать нашу способность строить иллюзии и страдать от них 😂
1🔥5😁1