Лучше напрячь программиста, чем пользователя
Программы часто хотят лишнюю информацию от людей. Пол, почтовый индекс, ИНН — всякое такое.
Иногда эта информация вовсе не нужна (просто бизнес собирает «чтобы было»). Иногда — реально используется. Но даже в этом случае кучу сведений можно получить автоматически, не дёргая человека.
Например:
— Пол по ФИО
— Индекс, район города, ближайшее метро и почтовое отделение по адресу
— Все реквизиты компании по названию или ИНН
— Страну, оператора связи и часовой пояс по телефону
— Банк по номеру карты
— Аватарку по емейлу
Большинство данных легко получить из готовых API. Какие-то можно скачать в машиночитаемом виде и приделать самостоятельно.
Причём это только для новых пользователей. А если взять историю взаимодействия с существующими и проанализировать паттерны поведения, вообще можно делать чудеса.
В любом случае, лучше один раз напрячь программиста, чем тысячу раз приставать к пользователям.
Программы часто хотят лишнюю информацию от людей. Пол, почтовый индекс, ИНН — всякое такое.
Иногда эта информация вовсе не нужна (просто бизнес собирает «чтобы было»). Иногда — реально используется. Но даже в этом случае кучу сведений можно получить автоматически, не дёргая человека.
Например:
— Пол по ФИО
— Индекс, район города, ближайшее метро и почтовое отделение по адресу
— Все реквизиты компании по названию или ИНН
— Страну, оператора связи и часовой пояс по телефону
— Банк по номеру карты
— Аватарку по емейлу
Большинство данных легко получить из готовых API. Какие-то можно скачать в машиночитаемом виде и приделать самостоятельно.
Причём это только для новых пользователей. А если взять историю взаимодействия с существующими и проанализировать паттерны поведения, вообще можно делать чудеса.
В любом случае, лучше один раз напрячь программиста, чем тысячу раз приставать к пользователям.
Я медленно снимаю твои деньги с карты
Многие сервисы заранее блокируют стоимость услуги на карте клиента, чтобы убедиться в его платёжеспособности.
Банки в СМС-оповещениях не делают разницы между блокировкой и списанием (может и правильно), потому присылают «с карты списано NNN рублей».
Если клиент пользуется услугой в первый раз, он начинает вибрировать: «ничего не сделали, а деньги уже списали, кидалы, а-а-а». Начинаются нервные звонки в поддержку и ругань в соцсетях. Ситуация проясняется, но осадок остаётся.
А избежать неприятных последствий просто: достаточно объяснить человеку, что происходит. Например, Qlean присылает такую СМС:
> Мы проверим вашу карту — вы можете получить смс от банка о списании средств. Не волнуйтесь, это всего лишь проверка.
Конечно, на самом деле это не «всего лишь проверка». 50% суммы они спишут в любом случае, даже если отменить уборку (в качестве штрафа).
Но эти нюансы в СМС не объяснишь, да и до штрафа дело доходит редко. А так клиент спокоен, доволен, и не отвлекает поддержку.
Многие сервисы заранее блокируют стоимость услуги на карте клиента, чтобы убедиться в его платёжеспособности.
Банки в СМС-оповещениях не делают разницы между блокировкой и списанием (может и правильно), потому присылают «с карты списано NNN рублей».
Если клиент пользуется услугой в первый раз, он начинает вибрировать: «ничего не сделали, а деньги уже списали, кидалы, а-а-а». Начинаются нервные звонки в поддержку и ругань в соцсетях. Ситуация проясняется, но осадок остаётся.
А избежать неприятных последствий просто: достаточно объяснить человеку, что происходит. Например, Qlean присылает такую СМС:
> Мы проверим вашу карту — вы можете получить смс от банка о списании средств. Не волнуйтесь, это всего лишь проверка.
Конечно, на самом деле это не «всего лишь проверка». 50% суммы они спишут в любом случае, даже если отменить уборку (в качестве штрафа).
Но эти нюансы в СМС не объяснишь, да и до штрафа дело доходит редко. А так клиент спокоен, доволен, и не отвлекает поддержку.
Сила частичных решений
Программисты ненавидят частичные решения. Если штука работает 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. Спасибо за вычитку и замечания великолепной Ольге Коноваловой
👍1
Облако 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/