Сила примеров

На днях прочёл «Додо-книгу» — принципы ведения бизнеса от одноименной компании. Это был бы обычный занудный сборник в стиле «надо делать хорошо и не надо плохо», если бы не примеры. Каждая глава — история из жизни сотрудника компании. Истории показывают внутреннюю кухню. Истории объясняют, откуда взялся каждый принцип и чем он полезен. В результате читать интересно.

Для меня лучшая формула обучения чему угодно — «порция теории + вагон примеров». Забавно, что при этом для большинства преподавателей (да и вообще профессионалов) выдать примеры — огромная трудность.

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

Я думаю, что успех рассылок и курсов Ильяхова именно в том, что он всегда и всё подаёт на примерах. То же самое и в продуктах. Хороший онбординг? Через примеры. Хорошая документация? Через примеры. Хороший маркетинг? Через примеры, близкие клиенту.

Кажется, от примеров выигрывает всё что угодно.

Задачка: регистрация с фото и паспортом

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

Интерфейс достаточно аккуратный, явно делал дизайнер. Но, думаю, есть что улучшить. Попробуем?

Разбор: 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...

Осталось только отказаться от транслита, и будет совсем хорошо.

Что дать почитать коллеге, далёкому от интерфейсов

Хорошо, если в вашей команде разработчики и тестировщики «прокачаны» в интерфейсах. Но если нет — бывает, хочется им что-то дать почитать, чтобы обеспечить минимальный уровень адекватности. И понятно, если это «что-то» будет размером с книгу условного Купера, читать это никто не будет (тут работать надо, а не книжки читать).

Я думал, что лучше всего советовать в таких ситуациях. Но ничего не нашёл, поэтому пришлось написать самому ツ
Самый минимум для вправления мозгов технических ребят — чтобы думали о пользователе, а не о том, о чём они обычно думают.

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.

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

Автокомплит и проверка данных

Чтобы помочь человеку правильно ввести сложные данные, часто используют автокомплит (он же «подсказки»). И почему-то постоянно хотят запретить вводить неизвестные варианты.

Не надо так:
https://antonz.ru/suggestions-vs-validation/

Не надо заканчивать фичи

Очень вредный совет продакту: «Надо заканчивать фичи». На самом деле — не надо, если на 100% не уверен в обратном.

Что значит не заканчивать фичу? Это значит, прекратить её улучшать, если видишь, что отдача (деньги, транзакции — любые попугаи, в которых меряете) меньше, чем затраты (деньги, человеко-часы, душевные силы).

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

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

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

Фичи надо заканчивать. Но только если игра стоит свеч.

О кодах подтверждения

Всё, что вы хотели знать о кодах подтверждения, которые используют банки и другие сервисы:

— какие бывают,
— какой длины кода достаточно,
— правда ли, что цифры в коде повторяются.

https://antonz.ru/security-code/

Бэклогом управляют пользователи

Когда приоритизируешь фичи в бэклоге, легко попасть в одну из двух ловушек:

— Слышать только самых громких.
— Считать по головам.

Решение — докапываться до сути проблемы в каждом запросе, пока не увидишь повторяющиеся паттерны. Проще сказать, чем сделать ツ

https://antonz.ru/users-not-backlog/

Уберите капчу при оплате

Капча — это очень, очень безопасно. А ещё очень, очень тупо — особенно когда она вмешивается в процесс оплаты.

Привожу примеры и вывожу Универсальное Правило Капчи:
https://antonz.ru/payment-captcha/

Секта свидетелей раздутой конверсии

Стоит только написать о человечном дизайне — например, рекомендовать сайту не плеваться всплывающими окнами и пуш-нотификациями — как тут же приходят опровергатели с железобетонным утверждением «а я так делаю, и у меня конверсия выросла».

Специально для секты свидетелей высокой конверсии у меня есть два соображения, которые они редко учитывают: https://antonz.ru/conversion/

Приём «срезать угол»

Срезать угол = сразу дать человеку результат, минуя ненужные шаги. Самый известный пример — «купить в 1 клик» на Амазоне. Срезаются привычные другим магазинам телодвижения: добавить в корзину, нажать «оформить заказ», выбрать способ доставки, нажать «подтвердить».

Ещё пример: кнопка «удалить всё из спама» в Гмейле. Срезаются: выделить все письма, нажать «удалить», нажать «подтвердить».

Ещё: кнопка «пропустить заставку» у сериалов на Нетфликсе. Срезаются 1–2 минуты, которые пользователи всех остальных сервисов тратят на просмотр одного и того же фрагмента в каждой серии.

Важно, чтобы решение «срезать или не срезать» принимал человек — это даёт ему ощущение контроля над ситуацией. Например, автоплатёж у подписки — это не «срезать угол», приятных эмоций он не создаёт.

Премиальный и золотой тарифы

Наткнулся на забавный пример ценообразования. Есть приложение «Труколлер» — оно помогает распознавать телефонных спамеров. В базовом варианте бесплатное, но, разумеется, есть платный тариф (Premium). В нём типовой набор плюшек — нет рекламы, дополнительные приятные возможности, всякое такое. Обычное дело.

Но сегодня я заметил, что у «Труколлера» есть и «золотой» (Gold) тариф — ровно в 10 раз дороже «премиального». Смотрите, чем он отличается:

1) Приоритетная техническая поддержка
2) Почётный золотой значок (sic!)

Переплачивать за быструю техподдержку — стандартная практика в корпоративном сегменте. Всякие Ораклы, IBM и прочие SAP в «базовом» варианте даже бровью не поведут, если у заказчика возникли проблемы с их софтом. Чтобы добиться от них хоть какой-то внятной помощи, крупные компании покупают «золотые» и «платиновые» тарифы с конским ценником. Это оправданно.

Но «Труколлер»? Если с ним возникают проблемы, проще снести приложение и поставить аналог, чем обращаться в поддержку. И уж точно нет смысла платить 10x за приоритетный саппорт.

Почётный золотой значок — это вообще волшебно. Я сразу вспомнил приложение «I am Rich» для айфона, которое стоило $1000 и прожило в апсторе ровно 1 день. Ну там хоть понятно — это был чистый стёб разработчика. Но кто станет платить 7К в год за золотой значок, серьёзно?

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

Тестировщики не должны находить баги

Читаю сейчас книгу Мартина о правильных программистах. Вообще, Мартин весёлый дядька — обожает категоричные утверждения, прямо как я. Но тут превзошёл сам себя: тестировщики, мол не должны ничего находить! На кой они тогда нужны, верно?

На самом деле, мысль его другая: код должен попадать к тестировщику уже тщательно проверенным. И тут я 100% «за».

Сколько раз наблюдал: программист чего-то там наделал, как-то вроде работает, какие-то даже тесты есть. И перебрасывает в тестирование — проверяйте, мол. QA сразу находит баги, программист чинит, QA снова находит, он снова чинит... В тяжёлых случаях это длится неделями.

Мартин прав. Фича здорового человека попадает в тестирование уже проверенной со всех сторон. Все ветки покрыты тестами, проверена производительность, учтены особенности продакшен-среды.

И это тяжело. Постоянно хочется срезать углы и понадеяться на «авось», когда знаешь, что за тобой кто-то проверит. Давите эти гнилые порывы, проверяйте всё сами — как если после вас сразу на прод ツ

Конечно, тестировщик всё равно найдёт баги — просто потому что мыслит иначе, чем разработчик. Но не будет ни бессмысленного пинг-понга, ни продолбов по срокам, ни костылей в коде.

Как стать на порядок умнее

Есть одна вещь, которая огорчает меня в коллегах по отрасли. Встречается она даже у программистов, что уж говорить о других причастных к производству софта специализациях.

Это безответственное использование выражения «на порядок».

Часто, когда человек хочет сказать «намного больше» — говорит «на порядок». Это, видимо, должно придать словам дополнительный «математический» вес:

— Мы добавили на сайт пять всплывающих окон, и конверсия выросла на порядок.
— Новая версия нашего мега-продукта работает на порядок быстрее.
— Я стал применять технику «помидорок», и эффективность увеличилась на порядки.

По определению, «на порядок» — это отличие как минимум в 10 раз. А «на порядки» — минимум в 100 раз.

Если конверсия была 2%, а стала 25% — поздравляю, это действительно «на порядок» (хотя больше похоже на то, что кто-то совсем заврался).

Если мега-продукт заработал в 2 раза быстрее — это «в два раза», а не «на порядок» (если хотите выпендриться — скажите «производительность возросла кратно»).

Если в прошлом месяце на сайт пришло 1000 человек, а в этом 1500 — это «посещаемость выросла на 50%» (или «в полтора раза»), а не «на порядок».

Если эффективность вроде бы возросла, но вы никогда её не мерили, и понятия не имеете, насколько — это «по ощущениям стало лучше», а не «на порядок».

Уверен, что у моих читателей всё в порядке с порядками. Просто наболело.

Дизайн — это здравый смысл

Чтобы создать хороший интерфейс, дизайнеру требуется:

— 80% здравого смысла,
— 19% знания предметной области,
— 1% дизайн-мышления, дизайн-систем, насмотренности и прочего, про что дизайнеры любят писать статьи на Медиуме.

То есть главное в дизайне — здравый смысл. Чтобы доказать это утверждение, я сделаю «редизайн» популярного приложения Zoom (замена скайпу для видео- и аудио-конференций) с позиции обычного здравомыслящего человека, не дизайнера.

Включаем голову: https://antonz.ru/common-sense-design/

Задачка: «очистить» vs «удалить»

На скриншоте интерфейс управления почтовыми ящиками. В контекстном меню есть действия Empty (очистить ящик) и Delete (удалить ящик). Я постоянно их путаю, и удаляю ящики, вместо того, чтобы очистить.

Как бы вы минимально изменили интерфейс, чтобы уменьшить вероятность ошибки?

Разбор: «очистить» vs «удалить»

Я согласен с большинством — лучше убрать Delete в настройки. Удаление почтового ящика — редкая операция, ей нечего делать в контекстном меню. Empty же используется часто: это тестовая почта, ящики время от времени чистят.

Почему остальные варианты нравятся меньше:

Переименовать, чтобы стало понятнее
Как не переименовывай, оба пункта останутся близкими по смыслу, а значит ошибки никуда не уйдут.

Сделать Delete красным и добавить ⚠️
Это, скорее всего, сработает. Но визуальный акцент на редкой операции — так себе решение.

Убрать Empty в настройки
Этот вариант я специально добавил, чтобы чуть усложнить выбор ツ Думаю, тут всё понятно.

В личку несколько раз прислали ещё один вариант:

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

Как упростить пользователю жизнь

Давным-давно Дональд Норман написал книгу «Дизайн привычных вещей». Максимум, что обычно из неё помнят люди — обзор дверей с неудобными ручками.

Книга, между тем, чудесная. Например, есть глава про то, как продукт может сделать жизнь человека проще. Там четыре шага, от простого к сложному. Я примерил их на сервисы доставки еды и обнаружил, что до конца пути никто до сих пор не прошёл. А книге 20 лет уже ツ

https://antonz.ru/simplify-users-life/