Сила частичных решений
Программисты ненавидят частичные решения. Если штука работает 99 раз из 100, значит она не работает вообще — так считает программист. Если она работает 9 раз из 10, так это и вовсе издевательство.
Но при взаимодействии с людьми, этими нелогичными белковыми существами, попадание в 90% случаев — отличный результат. Главное, чтобы в оставшихся 10% алгоритм честно говорил «не знаю», а не выдавал результат наобум.
Пример: автоматическое определение пола по имени-фамилии. Да, никакой алгоритм не угадает пол у «Саши Савченко». Но если он уверенно отрабатывает на Настях и Колях, а про «Женю Зверь» честно скажет «не знаю» — это отличный алгоритм. Потому что в 90% случаев вы узнаете пол, а в оставшихся 10% — ничего не потеряете.
Понятно, что частичные решения не везде уместны. Если автопилот в одном полёте из десяти говорит «ой всё, я не смогла» — в топку такой автопилот.
Но намного чаще частичные решения помогают. Главное, чтобы не врали.
Программисты ненавидят частичные решения. Если штука работает 99 раз из 100, значит она не работает вообще — так считает программист. Если она работает 9 раз из 10, так это и вовсе издевательство.
Но при взаимодействии с людьми, этими нелогичными белковыми существами, попадание в 90% случаев — отличный результат. Главное, чтобы в оставшихся 10% алгоритм честно говорил «не знаю», а не выдавал результат наобум.
Пример: автоматическое определение пола по имени-фамилии. Да, никакой алгоритм не угадает пол у «Саши Савченко». Но если он уверенно отрабатывает на Настях и Колях, а про «Женю Зверь» честно скажет «не знаю» — это отличный алгоритм. Потому что в 90% случаев вы узнаете пол, а в оставшихся 10% — ничего не потеряете.
Понятно, что частичные решения не везде уместны. Если автопилот в одном полёте из десяти говорит «ой всё, я не смогла» — в топку такой автопилот.
Но намного чаще частичные решения помогают. Главное, чтобы не врали.
По техническим причинам
Люди любят объяснять провалы «техническими причинами»:
> По техническим причинам поезда следуют с увеличенными интервалами.
> По техническим причинам платежи картой временно не принимаются.
> По техническим причинам магазин не работает после 18:00.
Я знаю один секрет: всем плевать на абстрактные причины. Неважно, технические они, гуманитарные, политические, религиозные или социальные. Если не можете назвать конкретику, лучше ограничиться голыми фактами:
> Поезда ходят с интервалом 5–10 минут.
> Платежи картой заработают 25 января.
> Часы работы: 10–18
Выпиливайте «технические причины» из интерфейсов.
Люди любят объяснять провалы «техническими причинами»:
> По техническим причинам поезда следуют с увеличенными интервалами.
> По техническим причинам платежи картой временно не принимаются.
> По техническим причинам магазин не работает после 18:00.
Я знаю один секрет: всем плевать на абстрактные причины. Неважно, технические они, гуманитарные, политические, религиозные или социальные. Если не можете назвать конкретику, лучше ограничиться голыми фактами:
> Поезда ходят с интервалом 5–10 минут.
> Платежи картой заработают 25 января.
> Часы работы: 10–18
Выпиливайте «технические причины» из интерфейсов.
Как проектировать необходимое зло в интерфейсе
Бывают в интерфейсе операции, которые пользователю не нужны — но без них никак. Самые частые «злые» операции — регистрация и оплата. Чтобы нормально их запроектировать, предлагаю два правила:
1. Минимизировать боль
2. Сохранять контекст
https://antonz.ru/necessary-evil/
Бывают в интерфейсе операции, которые пользователю не нужны — но без них никак. Самые частые «злые» операции — регистрация и оплата. Чтобы нормально их запроектировать, предлагаю два правила:
1. Минимизировать боль
2. Сохранять контекст
https://antonz.ru/necessary-evil/
Обратить необратимое
Возможно, вы слышали о грандиозном UX-провале на Гавайях: там из-за плохого интерфейса оператор ошибся и отправил жителям оповещение о ракетном ударе (с милым дополнением «ЭТО НЕ УЧЕБНАЯ ТРЕВОГА»).
По этому поводу Гавайи и плохие интерфейсы простебали уже все кому не лень. Из основных проблем выделяют визуальную схожесть кнопок тестовой и реальной тревоги, плохое подтверждение действия и не-сценарность интерфейса (он выглядит просто как свалка ссылок).
Но главная беда, на мой взгляд, такая:
— Нет отмены ошибочной операции —
Кажется, у необратимых операций всегда должна быть отмена. Это контринтуитивно (мол, какая же отмена, если операция необратимая). Но именно таким операциям и нужна отмена.
Простейший способ добавить отмену необратимого действия — выполнять его не по факту нажатия на кнопку, а отложенно, через N секунд. Обычно человек моментально понимает, что сделал что-то не то — и успевает отменить. Если вы когда-нибудь по ошибке отправляли письмо не тому человеку, то знаете, как это бывает ツ
Возможно, вы слышали о грандиозном UX-провале на Гавайях: там из-за плохого интерфейса оператор ошибся и отправил жителям оповещение о ракетном ударе (с милым дополнением «ЭТО НЕ УЧЕБНАЯ ТРЕВОГА»).
По этому поводу Гавайи и плохие интерфейсы простебали уже все кому не лень. Из основных проблем выделяют визуальную схожесть кнопок тестовой и реальной тревоги, плохое подтверждение действия и не-сценарность интерфейса (он выглядит просто как свалка ссылок).
Но главная беда, на мой взгляд, такая:
— Нет отмены ошибочной операции —
Кажется, у необратимых операций всегда должна быть отмена. Это контринтуитивно (мол, какая же отмена, если операция необратимая). Но именно таким операциям и нужна отмена.
Простейший способ добавить отмену необратимого действия — выполнять его не по факту нажатия на кнопку, а отложенно, через N секунд. Обычно человек моментально понимает, что сделал что-то не то — и успевает отменить. Если вы когда-нибудь по ошибке отправляли письмо не тому человеку, то знаете, как это бывает ツ
Секта свидетелей личного кабинета
Есть два типа дизайнеров:
— одни все настройки и статистику запихивают в «личный кабинет» (таких большинство),
— другие раскладывают их по фича-разделам.
Поясню на примере.
Есть у нас сервис с двумя фичами: «чесать за ухом» и «гладить по спинке». Фичи сильно разные. «Чесать за ухом» работает по годовой подписке, «гладить по спинке» — оплачивается за каждое поглаживание. Отличается целевая аудитория, ведётся раздельная статистика, разная система скидок — ну вы поняли.
И вот нам надо куда-то добавить управление подпиской и статистику. Есть два варианта:
1) Делаем в личном кабинете разделы «оплата» (внутри разбиение на «чесалку» и «гладилку») и «статистика» (внутри аналогичное разделение).
2) Берём промо-экран «чесалки» и меняем его для залогиненных пользователей: убираем вводную (человек ведь уже в курсе) и добавляем модули «подписка» и «статистика». Аналогично делаем для «гладилки». Личный кабинет не делаем вовсе.
Большинство выбирает первый вариант. Мне он не слишком по душе. А вам?
Есть два типа дизайнеров:
— одни все настройки и статистику запихивают в «личный кабинет» (таких большинство),
— другие раскладывают их по фича-разделам.
Поясню на примере.
Есть у нас сервис с двумя фичами: «чесать за ухом» и «гладить по спинке». Фичи сильно разные. «Чесать за ухом» работает по годовой подписке, «гладить по спинке» — оплачивается за каждое поглаживание. Отличается целевая аудитория, ведётся раздельная статистика, разная система скидок — ну вы поняли.
И вот нам надо куда-то добавить управление подпиской и статистику. Есть два варианта:
1) Делаем в личном кабинете разделы «оплата» (внутри разбиение на «чесалку» и «гладилку») и «статистика» (внутри аналогичное разделение).
2) Берём промо-экран «чесалки» и меняем его для залогиненных пользователей: убираем вводную (человек ведь уже в курсе) и добавляем модули «подписка» и «статистика». Аналогично делаем для «гладилки». Личный кабинет не делаем вовсе.
Большинство выбирает первый вариант. Мне он не слишком по душе. А вам?
Убийственный дизайн
Наткнулся на классную, судя по всему, книгу — Tragic Design. Об ошибках в дизайне, которые калечат и убивают — и о том, как их избежать.
Вторая глава с захватывающим названием «Design Can Kill» есть в открытом доступе. Там разобраны 4 ситуации, когда ошибки в интерфейсе продукта привели к фатальным последствиям:
— Аппарат для лучевой терапии, которые стрелял в пациентов направленным пучком в 17000 рад (в 85 раз больше нормальной дозы).
— Паром, у которого «газ» и «тормоз» менялись местами в зависимости от режима (вспоминается классическое программистское «define TRUE FALSE»).
— Автомобиль, который блокировал двери и загорался при ударе сзади — и убил таким способом 180 человек.
— Самолёт, который влетел в гору, потому что путал градусы с вертикальной скоростью.
Почитайте, чтобы навсегда перестать использовать режимы в интерфейсе. Это будет поубедительнее, чем аналогичная тема у Раскина ツ
Наткнулся на классную, судя по всему, книгу — Tragic Design. Об ошибках в дизайне, которые калечат и убивают — и о том, как их избежать.
Вторая глава с захватывающим названием «Design Can Kill» есть в открытом доступе. Там разобраны 4 ситуации, когда ошибки в интерфейсе продукта привели к фатальным последствиям:
— Аппарат для лучевой терапии, которые стрелял в пациентов направленным пучком в 17000 рад (в 85 раз больше нормальной дозы).
— Паром, у которого «газ» и «тормоз» менялись местами в зависимости от режима (вспоминается классическое программистское «define TRUE FALSE»).
— Автомобиль, который блокировал двери и загорался при ударе сзади — и убил таким способом 180 человек.
— Самолёт, который влетел в гору, потому что путал градусы с вертикальной скоростью.
Почитайте, чтобы навсегда перестать использовать режимы в интерфейсе. Это будет поубедительнее, чем аналогичная тема у Раскина ツ
Если нет награды, прогресс бесполезен
Мотивация усиливается по мере приближения к цели. Особенно хорошо это работает, если человек видит прогресс.
Продукты и сервисы вовсю этим пользуются. Хрестоматийный пример — LinkedIn с его «прогрессом заполнения профиля», но вообще приём используется повсеместно. Даже на форме заявки на кредитку пишут «шаг 1 из 4» — это тоже визуализация прогресса.
Приём работает при одном условии — человек понимает, в чём награда. Прогресс сам по себе не особо мотивирует, если я не понимаю, что получу взамен.
Хрестоматийный анти-пример — приложение заказа такси Gett. У них есть программа лояльности со статусами вроде «суперзвезда», «вожак стаи» и «босс». Но статусы ничем не отличаются, кроме названия и количества очков, которые надо набрать.
Так было несколько лет. Потом, похоже, кто-то в Gett заметил, что программа лояльности никого не делает лояльнее, и задумался о наградах. И придумал «скидку в часы пик».
И теперь эту скидку написали всем статусам выше определённого уровня. Одну и ту же ツ Но если награда везде одна и та же — это всё равно что её нет.
В общем, если показывать прогресс достижения цели — то вывесить понятную награду. А если у цели несколько уровней, то и награды должны быть разными.
Мотивация усиливается по мере приближения к цели. Особенно хорошо это работает, если человек видит прогресс.
Продукты и сервисы вовсю этим пользуются. Хрестоматийный пример — LinkedIn с его «прогрессом заполнения профиля», но вообще приём используется повсеместно. Даже на форме заявки на кредитку пишут «шаг 1 из 4» — это тоже визуализация прогресса.
Приём работает при одном условии — человек понимает, в чём награда. Прогресс сам по себе не особо мотивирует, если я не понимаю, что получу взамен.
Хрестоматийный анти-пример — приложение заказа такси Gett. У них есть программа лояльности со статусами вроде «суперзвезда», «вожак стаи» и «босс». Но статусы ничем не отличаются, кроме названия и количества очков, которые надо набрать.
Так было несколько лет. Потом, похоже, кто-то в Gett заметил, что программа лояльности никого не делает лояльнее, и задумался о наградах. И придумал «скидку в часы пик».
И теперь эту скидку написали всем статусам выше определённого уровня. Одну и ту же ツ Но если награда везде одна и та же — это всё равно что её нет.
В общем, если показывать прогресс достижения цели — то вывесить понятную награду. А если у цели несколько уровней, то и награды должны быть разными.
Сила примеров
На днях прочёл «Додо-книгу» — принципы ведения бизнеса от одноименной компании. Это был бы обычный занудный сборник в стиле «надо делать хорошо и не надо плохо», если бы не примеры. Каждая глава — история из жизни сотрудника компании. Истории показывают внутреннюю кухню. Истории объясняют, откуда взялся каждый принцип и чем он полезен. В результате читать интересно.
Для меня лучшая формула обучения чему угодно — «порция теории + вагон примеров». Забавно, что при этом для большинства преподавателей (да и вообще профессионалов) выдать примеры — огромная трудность.
Любой спец с лёгкостью напишет, как «лучше быть богатым и здоровым, чем бедным и больным» — но заскрипит на примерах. Если попросить профи написать статью — он изложит десяток хороших и правильных принципов, и в лучшем случае один натужный пример (хорошо если не выдуманный).
Я думаю, что успех рассылок и курсов Ильяхова именно в том, что он всегда и всё подаёт на примерах. То же самое и в продуктах. Хороший онбординг? Через примеры. Хорошая документация? Через примеры. Хороший маркетинг? Через примеры, близкие клиенту.
Кажется, от примеров выигрывает всё что угодно.
На днях прочёл «Додо-книгу» — принципы ведения бизнеса от одноименной компании. Это был бы обычный занудный сборник в стиле «надо делать хорошо и не надо плохо», если бы не примеры. Каждая глава — история из жизни сотрудника компании. Истории показывают внутреннюю кухню. Истории объясняют, откуда взялся каждый принцип и чем он полезен. В результате читать интересно.
Для меня лучшая формула обучения чему угодно — «порция теории + вагон примеров». Забавно, что при этом для большинства преподавателей (да и вообще профессионалов) выдать примеры — огромная трудность.
Любой спец с лёгкостью напишет, как «лучше быть богатым и здоровым, чем бедным и больным» — но заскрипит на примерах. Если попросить профи написать статью — он изложит десяток хороших и правильных принципов, и в лучшем случае один натужный пример (хорошо если не выдуманный).
Я думаю, что успех рассылок и курсов Ильяхова именно в том, что он всегда и всё подаёт на примерах. То же самое и в продуктах. Хороший онбординг? Через примеры. Хорошая документация? Через примеры. Хороший маркетинг? Через примеры, близкие клиенту.
Кажется, от примеров выигрывает всё что угодно.
Задачка: регистрация с фото и паспортом
На просторах фейсбука встретил скрины регистрации в довольно типичном приложении, которому надо идентифицировать человека. Так обычно работают каршеринги и всяки уберо-подобные сервисы, которым не обойтись просто электронной почтой.
Интерфейс достаточно аккуратный, явно делал дизайнер. Но, думаю, есть что улучшить. Попробуем?
Разбор: https://antonz.ru/signup-puzzle/
На просторах фейсбука встретил скрины регистрации в довольно типичном приложении, которому надо идентифицировать человека. Так обычно работают каршеринги и всяки уберо-подобные сервисы, которым не обойтись просто электронной почтой.
Интерфейс достаточно аккуратный, явно делал дизайнер. Но, думаю, есть что улучшить. Попробуем?
Разбор: https://antonz.ru/signup-puzzle/
Пароли в СМС
Альфа-Банк тут выложил в общий доступ свою дизайн-систему. Там, как полагается, есть принципы (скукота), компоненты на Реакте (вряд ли кому-то пригодятся, кроме самого банка) и самое интересное — паттерны.
Паттерны — это интерфейсные решения и эвристики продукта. Их там совсем немного, но вот хороший про одноразовые пароли:
> Важно, чтобы одноразовый пароль был полностью виден в предпросмотре входящего сообщения и был как можно короче. Так клиент сможет быстро увидеть пароль, запомнить его и ввести.
Золотые прям слова. Альфа-Банк много лет слал примерно такие СМС:
> Podverdite perevod na summu NNN RUR na schet MMM. Vnimanie! Nikomu ne soobshayte parol. Parol dlya perevoda: 123456
Разумеется, в панели нотификаций на телефоне показывалась только начальная бесполезная часть, а за паролем приходилось лезть внутрь сообщения.
В определённый момент ребята исправились и теперь шлют так:
> Parol: 1234. Podverdite perevod...
Осталось только отказаться от транслита, и будет совсем хорошо.
Альфа-Банк тут выложил в общий доступ свою дизайн-систему. Там, как полагается, есть принципы (скукота), компоненты на Реакте (вряд ли кому-то пригодятся, кроме самого банка) и самое интересное — паттерны.
Паттерны — это интерфейсные решения и эвристики продукта. Их там совсем немного, но вот хороший про одноразовые пароли:
> Важно, чтобы одноразовый пароль был полностью виден в предпросмотре входящего сообщения и был как можно короче. Так клиент сможет быстро увидеть пароль, запомнить его и ввести.
Золотые прям слова. Альфа-Банк много лет слал примерно такие СМС:
> Podverdite perevod na summu NNN RUR na schet MMM. Vnimanie! Nikomu ne soobshayte parol. Parol dlya perevoda: 123456
Разумеется, в панели нотификаций на телефоне показывалась только начальная бесполезная часть, а за паролем приходилось лезть внутрь сообщения.
В определённый момент ребята исправились и теперь шлют так:
> Parol: 1234. Podverdite perevod...
Осталось только отказаться от транслита, и будет совсем хорошо.
Что дать почитать коллеге, далёкому от интерфейсов
Хорошо, если в вашей команде разработчики и тестировщики «прокачаны» в интерфейсах. Но если нет — бывает, хочется им что-то дать почитать, чтобы обеспечить минимальный уровень адекватности. И понятно, если это «что-то» будет размером с книгу условного Купера, читать это никто не будет (тут работать надо, а не книжки читать).
Я думал, что лучше всего советовать в таких ситуациях. Но ничего не нашёл, поэтому пришлось написать самому ツ
Самый минимум для вправления мозгов технических ребят — чтобы думали о пользователе, а не о том, о чём они обычно думают.
https://antonz.ru/laws/
P.S. Спасибо за вычитку и замечания великолепной Ольге Коноваловой
Хорошо, если в вашей команде разработчики и тестировщики «прокачаны» в интерфейсах. Но если нет — бывает, хочется им что-то дать почитать, чтобы обеспечить минимальный уровень адекватности. И понятно, если это «что-то» будет размером с книгу условного Купера, читать это никто не будет (тут работать надо, а не книжки читать).
Я думал, что лучше всего советовать в таких ситуациях. Но ничего не нашёл, поэтому пришлось написать самому ツ
Самый минимум для вправления мозгов технических ребят — чтобы думали о пользователе, а не о том, о чём они обычно думают.
https://antonz.ru/laws/
P.S. Спасибо за вычитку и замечания великолепной Ольге Коноваловой
Облако vs коробка
Ghost (такой блого-движок) празднует пятилетний юбилей. По этому поводу авторы написали, что они поняли о рынке и разработке опенсорс-софта за прошедшее время.
Зацепил один момент. Они пишут:
> When we started out, we tried to make everything as simple and user-focused as possible. Most open source software has terrible UI design, so we would have great UI design and it would be the best of both worlds!
> This falls apart almost immediately.
Дело даже не в опенсорсе, а в разнице между «коробочным» и «облачным» софтом. Облачные системы на самом деле чудовищно сложные — множество отдельных компонентов, соединённых причудливой логикой, да ещё куча интеграций с внешними системами. Но для пользователя (даже для администратора) они выглядят простыми — потому что сложность скрыта под капотом.
«Коробочные» системы (имею в виду серверный софт), как бы разработчики ни старались, не могут быть настолько же простыми в установке и настройке, как облако. Но, парадоксально, внутри они устроены намного проще — иначе их вообще невозможно было бы нормально поставить.
Ребята из Госта пытались сделать простую в настройке «коробку» — и оказалось, что это утопия:
> We deliberately limited flexibility in the product to try and make it more simple. But it ended up being still not simple enough for the average user, and not powerful or flexible enough for the professional user — the worst of both worlds.
У хорошей «коробки» вместо облачной простоты — гибкость. А со сложностью борются понятной документацией, лёгкостью внесения изменений и развитыми средствами диагностики.
Ghost (такой блого-движок) празднует пятилетний юбилей. По этому поводу авторы написали, что они поняли о рынке и разработке опенсорс-софта за прошедшее время.
Зацепил один момент. Они пишут:
> When we started out, we tried to make everything as simple and user-focused as possible. Most open source software has terrible UI design, so we would have great UI design and it would be the best of both worlds!
> This falls apart almost immediately.
Дело даже не в опенсорсе, а в разнице между «коробочным» и «облачным» софтом. Облачные системы на самом деле чудовищно сложные — множество отдельных компонентов, соединённых причудливой логикой, да ещё куча интеграций с внешними системами. Но для пользователя (даже для администратора) они выглядят простыми — потому что сложность скрыта под капотом.
«Коробочные» системы (имею в виду серверный софт), как бы разработчики ни старались, не могут быть настолько же простыми в установке и настройке, как облако. Но, парадоксально, внутри они устроены намного проще — иначе их вообще невозможно было бы нормально поставить.
Ребята из Госта пытались сделать простую в настройке «коробку» — и оказалось, что это утопия:
> We deliberately limited flexibility in the product to try and make it more simple. But it ended up being still not simple enough for the average user, and not powerful or flexible enough for the professional user — the worst of both worlds.
У хорошей «коробки» вместо облачной простоты — гибкость. А со сложностью борются понятной документацией, лёгкостью внесения изменений и развитыми средствами диагностики.
Автокомплит и проверка данных
Чтобы помочь человеку правильно ввести сложные данные, часто используют автокомплит (он же «подсказки»). И почему-то постоянно хотят запретить вводить неизвестные варианты.
Не надо так:
https://antonz.ru/suggestions-vs-validation/
Чтобы помочь человеку правильно ввести сложные данные, часто используют автокомплит (он же «подсказки»). И почему-то постоянно хотят запретить вводить неизвестные варианты.
Не надо так:
https://antonz.ru/suggestions-vs-validation/
Не надо заканчивать фичи
Очень вредный совет продакту: «Надо заканчивать фичи». На самом деле — не надо, если на 100% не уверен в обратном.
Что значит не заканчивать фичу? Это значит, прекратить её улучшать, если видишь, что отдача (деньги, транзакции — любые попугаи, в которых меряете) меньше, чем затраты (деньги, человеко-часы, душевные силы).
Лучше вообще выпилить такую фичу из продукта, чем убиваться с доработкой или бесконечно тащить её с собой, теряя деньги на сопровождение и тестирование.
Почему важно не заканчивать фичи? Потому что время команды ограничено, а потенциальные фичи — нет. И лучше тратить ресурсы на фичи с хорошим соотношением «отдача/затраты», чем заканчивать плохие только потому, что когда-то начал их делать.
Что происходит с продуктом, в котором все фичи заканчивают? Он развивается мучительно медленно, а пользователи недоумевают, какого чёрта в продукт запихали все эти никому не нужные возможности.
Фичи надо заканчивать. Но только если игра стоит свеч.
Очень вредный совет продакту: «Надо заканчивать фичи». На самом деле — не надо, если на 100% не уверен в обратном.
Что значит не заканчивать фичу? Это значит, прекратить её улучшать, если видишь, что отдача (деньги, транзакции — любые попугаи, в которых меряете) меньше, чем затраты (деньги, человеко-часы, душевные силы).
Лучше вообще выпилить такую фичу из продукта, чем убиваться с доработкой или бесконечно тащить её с собой, теряя деньги на сопровождение и тестирование.
Почему важно не заканчивать фичи? Потому что время команды ограничено, а потенциальные фичи — нет. И лучше тратить ресурсы на фичи с хорошим соотношением «отдача/затраты», чем заканчивать плохие только потому, что когда-то начал их делать.
Что происходит с продуктом, в котором все фичи заканчивают? Он развивается мучительно медленно, а пользователи недоумевают, какого чёрта в продукт запихали все эти никому не нужные возможности.
Фичи надо заканчивать. Но только если игра стоит свеч.
О кодах подтверждения
Всё, что вы хотели знать о кодах подтверждения, которые используют банки и другие сервисы:
— какие бывают,
— какой длины кода достаточно,
— правда ли, что цифры в коде повторяются.
https://antonz.ru/security-code/
Всё, что вы хотели знать о кодах подтверждения, которые используют банки и другие сервисы:
— какие бывают,
— какой длины кода достаточно,
— правда ли, что цифры в коде повторяются.
https://antonz.ru/security-code/
Бэклогом управляют пользователи
Когда приоритизируешь фичи в бэклоге, легко попасть в одну из двух ловушек:
— Слышать только самых громких.
— Считать по головам.
Решение — докапываться до сути проблемы в каждом запросе, пока не увидишь повторяющиеся паттерны. Проще сказать, чем сделать ツ
https://antonz.ru/users-not-backlog/
Когда приоритизируешь фичи в бэклоге, легко попасть в одну из двух ловушек:
— Слышать только самых громких.
— Считать по головам.
Решение — докапываться до сути проблемы в каждом запросе, пока не увидишь повторяющиеся паттерны. Проще сказать, чем сделать ツ
https://antonz.ru/users-not-backlog/
Уберите капчу при оплате
Капча — это очень, очень безопасно. А ещё очень, очень тупо — особенно когда она вмешивается в процесс оплаты.
Привожу примеры и вывожу Универсальное Правило Капчи:
https://antonz.ru/payment-captcha/
Капча — это очень, очень безопасно. А ещё очень, очень тупо — особенно когда она вмешивается в процесс оплаты.
Привожу примеры и вывожу Универсальное Правило Капчи:
https://antonz.ru/payment-captcha/
Секта свидетелей раздутой конверсии
Стоит только написать о человечном дизайне — например, рекомендовать сайту не плеваться всплывающими окнами и пуш-нотификациями — как тут же приходят опровергатели с железобетонным утверждением «а я так делаю, и у меня конверсия выросла».
Специально для секты свидетелей высокой конверсии у меня есть два соображения, которые они редко учитывают: https://antonz.ru/conversion/
Стоит только написать о человечном дизайне — например, рекомендовать сайту не плеваться всплывающими окнами и пуш-нотификациями — как тут же приходят опровергатели с железобетонным утверждением «а я так делаю, и у меня конверсия выросла».
Специально для секты свидетелей высокой конверсии у меня есть два соображения, которые они редко учитывают: https://antonz.ru/conversion/
Приём «срезать угол»
Срезать угол = сразу дать человеку результат, минуя ненужные шаги. Самый известный пример — «купить в 1 клик» на Амазоне. Срезаются привычные другим магазинам телодвижения: добавить в корзину, нажать «оформить заказ», выбрать способ доставки, нажать «подтвердить».
Ещё пример: кнопка «удалить всё из спама» в Гмейле. Срезаются: выделить все письма, нажать «удалить», нажать «подтвердить».
Ещё: кнопка «пропустить заставку» у сериалов на Нетфликсе. Срезаются 1–2 минуты, которые пользователи всех остальных сервисов тратят на просмотр одного и того же фрагмента в каждой серии.
Важно, чтобы решение «срезать или не срезать» принимал человек — это даёт ему ощущение контроля над ситуацией. Например, автоплатёж у подписки — это не «срезать угол», приятных эмоций он не создаёт.
Срезать угол = сразу дать человеку результат, минуя ненужные шаги. Самый известный пример — «купить в 1 клик» на Амазоне. Срезаются привычные другим магазинам телодвижения: добавить в корзину, нажать «оформить заказ», выбрать способ доставки, нажать «подтвердить».
Ещё пример: кнопка «удалить всё из спама» в Гмейле. Срезаются: выделить все письма, нажать «удалить», нажать «подтвердить».
Ещё: кнопка «пропустить заставку» у сериалов на Нетфликсе. Срезаются 1–2 минуты, которые пользователи всех остальных сервисов тратят на просмотр одного и того же фрагмента в каждой серии.
Важно, чтобы решение «срезать или не срезать» принимал человек — это даёт ему ощущение контроля над ситуацией. Например, автоплатёж у подписки — это не «срезать угол», приятных эмоций он не создаёт.
Премиальный и золотой тарифы
Наткнулся на забавный пример ценообразования. Есть приложение «Труколлер» — оно помогает распознавать телефонных спамеров. В базовом варианте бесплатное, но, разумеется, есть платный тариф (Premium). В нём типовой набор плюшек — нет рекламы, дополнительные приятные возможности, всякое такое. Обычное дело.
Но сегодня я заметил, что у «Труколлера» есть и «золотой» (Gold) тариф — ровно в 10 раз дороже «премиального». Смотрите, чем он отличается:
1) Приоритетная техническая поддержка
2) Почётный золотой значок (sic!)
Переплачивать за быструю техподдержку — стандартная практика в корпоративном сегменте. Всякие Ораклы, IBM и прочие SAP в «базовом» варианте даже бровью не поведут, если у заказчика возникли проблемы с их софтом. Чтобы добиться от них хоть какой-то внятной помощи, крупные компании покупают «золотые» и «платиновые» тарифы с конским ценником. Это оправданно.
Но «Труколлер»? Если с ним возникают проблемы, проще снести приложение и поставить аналог, чем обращаться в поддержку. И уж точно нет смысла платить 10x за приоритетный саппорт.
Почётный золотой значок — это вообще волшебно. Я сразу вспомнил приложение «I am Rich» для айфона, которое стоило $1000 и прожило в апсторе ровно 1 день. Ну там хоть понятно — это был чистый стёб разработчика. Но кто станет платить 7К в год за золотой значок, серьёзно?
Может маркетологи из «Труколлера» тоже так развлекаются, конечно. Тогда я бы им предложил добавить по-настоящему золотую фичу: посмотреть, под каким именем ты записан у других людей в контактах. Ну и переименовать тариф в «платиновый», конечно ツ
Наткнулся на забавный пример ценообразования. Есть приложение «Труколлер» — оно помогает распознавать телефонных спамеров. В базовом варианте бесплатное, но, разумеется, есть платный тариф (Premium). В нём типовой набор плюшек — нет рекламы, дополнительные приятные возможности, всякое такое. Обычное дело.
Но сегодня я заметил, что у «Труколлера» есть и «золотой» (Gold) тариф — ровно в 10 раз дороже «премиального». Смотрите, чем он отличается:
1) Приоритетная техническая поддержка
2) Почётный золотой значок (sic!)
Переплачивать за быструю техподдержку — стандартная практика в корпоративном сегменте. Всякие Ораклы, IBM и прочие SAP в «базовом» варианте даже бровью не поведут, если у заказчика возникли проблемы с их софтом. Чтобы добиться от них хоть какой-то внятной помощи, крупные компании покупают «золотые» и «платиновые» тарифы с конским ценником. Это оправданно.
Но «Труколлер»? Если с ним возникают проблемы, проще снести приложение и поставить аналог, чем обращаться в поддержку. И уж точно нет смысла платить 10x за приоритетный саппорт.
Почётный золотой значок — это вообще волшебно. Я сразу вспомнил приложение «I am Rich» для айфона, которое стоило $1000 и прожило в апсторе ровно 1 день. Ну там хоть понятно — это был чистый стёб разработчика. Но кто станет платить 7К в год за золотой значок, серьёзно?
Может маркетологи из «Труколлера» тоже так развлекаются, конечно. Тогда я бы им предложил добавить по-настоящему золотую фичу: посмотреть, под каким именем ты записан у других людей в контактах. Ну и переименовать тариф в «платиновый», конечно ツ