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

• Ну и что, что человек не может ничего прочитать, пока не подпишется на рассылку в огромном попапе? Так конверсия выше!
• Ну и что, что всех бесит, когда в углу прыгает и требует внимания онлайн-консультант? Зато конверсия растёт!
• Ну и что, что при попытке увести курсор мыши на соседнюю вкладку выскакивает окошко с предложением ОГРОМНОЙ СКИДКИ? Это всё ради конверсии!

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

1. Выручка вместо конверсии

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

Для коммерческой компании адекватный показатель — выручка (и прибыль), а не конверсия.

2. Долговременные последствия

Окей, допустим «продающие» уловки увеличили не только конверсию, но и выручку. Но помимо изменений «в моменте» есть и долговременные:

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

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

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

⌘ ⌘ ⌘

Не замыкайтесь вы на этой конверсии. Смотрите на все показатели бизнеса; и не в моменте, а в перспективе.

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

1. Не размазывать мысль по нескольким сообщениям

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

А ещё — перечитайте пост перед отправкой и исправьте очевидные проблемы в формулировках. Никто не хочет читать полуфабрикат.

2. Ограничиться одним постом в день

Если у вас не новостной канал, конечно. Учитывая бешеную активность в чатах и группах, читателю не очень радостно получать десяток дополнительных сообщений ежедневно.

Один пост, максимум два — самое то.

3. Отключить оповещения

В ваших заметках нет ничего настолько срочного, чтобы тыкать в подписчика пуш-оповещениями. Конечно, многие и так мьютят все каналы, но хорошо позаботиться об остальных и самостоятельно выключить колокольчик:

4. Выносить длинные посты в Телеграф

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

5. Использовать форматирование

Отформатированный пост приятно выглядит, да и читать его легче:

Вот что поможет:

• жирный заголовок,
• ссылки в конце, а не по тексту,
• минимум эмодзи,
• иллюстрация, если уместно.

6. Обозначать рекламу

Элементарная порядочность: ставишь рекламу — напиши, что это она. Не надо маскировать под рекомендации или «кстати, наткнулся тут».

Голосовой помощник Яндекса — «Алиса» — работает на смартфонах, в автомобилях и в Яндекс-станции. Алиса обладает «навыками»: человек спрашивает и командует, Алиса отвечает и выполняет.

Есть стандартные навыки («какая сейчас погода»). Можно делать собственные: «включи свет», «проверь почту», «закажи пропуск». В теории выглядит красиво.

Я посмотрел, как «нестандартные» навыки работают на практике. Резюме такое, что для «умного» дома или офиса они совсем не годятся.

1. Нельзя сделать навык только для себя

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

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

Это было бы поправимо, если бы не следующая проблема:

2. Нет автоматической авторизации

«Алиса» не умеет отличить человека по голосу или привязать навыки к учётной записи. Если хотите настоящей приватности — реализуйте авторизацию самостоятельно.

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

3. Нельзя просто так взять и попросить

Нельзя просто сказать «Алиса, включи свет в прихожей». Сначала придётся активировать навык:

Алиса, запусти навык «умный дом»

И затем уже командовать:

Включи свет в прихожей

Да быстрее самому включить ツ

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

Алиса, запусти навык «Умный дом Антона Жиянова». Включи свет в прихожей.

И это мне ещё с редкой фамилией повезло. Готовьтесь испытать муки творчества, сравнимые с придумыванием домена или адреса электронной почты.

4. На выходе — вахтёр

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

Модерация занимает 1–3 дня.

⌘ ⌘ ⌘

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

«Спасибо, кэп! Какой чудак будет ставить капчу на форму оплаты?». А таких много. В этой заметке я покажу примеры и выведу универсальное правило применения капчи.

Капча для подписчика

У газеты «Ведомости» есть платная подписка:

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

1. Ведомости уже потратились на отправку СМС, а значит отсеивать ботов несколько поздновато.
2. Человек подтверждает свою человечность, вводя код из СМС. Капча проверяет непонято что.

Представим теперь, что капчу убрали. И нашёлся такой умный бот, что получил СМС, и ввёл код, и подписался на Ведомости. Что плохого произойдёт для газеты? Ничего. Капча не нужна.

Капча при оплате

Популярный пакет офисных программ LibreOffice принимает пожертвования на сайте:

Нажимаешь на Donate, получаешь в благодарность капчу. Если разгадал — так уж и быть, можешь заплатить. Не разгадал или бот — ха-ха, неудачник, не видать ЛибреОфису твоих денежек! Хм.

Как и с «Ведомостями», капча ЛибреОфиса эффективно решает единственную задачу — собрать как можно меньше денег. Не думаю, что это достойная цель.

Если убрать капчу, то бот отвалится на этапе ввода карточки или подтверждения платежа. Что плохого произойдёт для ЛибреОфиса? Ничего. Капча не нужна.

Выводы и правила

Первое, консервативное правило капчи:

Уберите капчу, если расходы на борьбу с ботами меньше упущенной прибыли от потерянных клиентов

Например, ваш сервис без капчи привлекает 100 клиентов в месяц и 500 ботов, а с капчей — 50 клиентов и 0 ботов. Пусть средний чек на клиента — 1000 ₽ в месяц.

Значит, на капче вы теряете 50 * 1000 = 50 000 ₽ в месяц. А если убрать капчу, получите 500 ботов. Обойдутся ли эти боты вам дороже 50 000 ₽? Если да, ставьте капчу. Если нет — к чёрту её.

Если последовательно применять консервативное правило капчи, рано или поздно придёте ко второму, радикальному:

Не используйте капчу

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

Но если от радикального правила внутри всё бурлит и клокочет — консервативное всегда к вашим услугам.

У программистов есть расхожая шутка:

Чтобы понять рекурсию, надо понять рекурсию.

Шутка на самом деле неудачная. Чтобы это увидеть, достаточно перевести её в псевдокод:

def understand_recursion():
    understand_recursion()

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

Исправим ошибку:

def understand_recursion(myself):
    if recursion_is_understood(myself):
        return
    understand_recursion(myself)

Или, переходя на естественный язык:

Чтобы понять рекурсию, надо понимать рекурсию до тех пор, пока не поймёте

Банки и другие сервисы используют коды подтверждения для защиты от мошенников. Обычно код выглядит как число из 4–6 цифр, которое приходит по СМС или пуш-оповещением.

В этой заметке я расскажу об удобстве и безопасности разных вариантов.

Какие бывают коды

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

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

• 45% сервисов используют коды из 6 цифр
• 41% используют 4 цифры
• 14% используют 5 цифр

Какой длины кода достаточно

Если у вас в компании есть безопасник — наверняка он ответит «шесть цифр и никак не меньше». 6 цифр — это 1 миллион комбинаций. Если дать злодею возможность беспрепятственно вводить коды каждую секунду, ему потребуется 11 дней, чтобы угадать.

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

Код из 4 цифр даёт 10 тысяч комбинаций. Если разрешить 3 попытки ввода, шанс угадать составит 0,03%. Другими словами, злоумышленнику придётся попытать счастья с 3300 человек, прежде чем у него что-то получится. Не слишком интересный расклад для злодея ツ

Правда ли, что цифры в коде повторяются

Это довольно распространённая точка зрения. Хочется думать: родной банк так заботится о твоём удобстве, что генерит коды с повторяющимися цифрами — чтобы легче было запомнить:

• 134571
• 85651
• 6411

В большинстве случаев это заблуждение. Чем длинее код, тем больше вероятность, что цифры в нём повторятся сами собой, без всяких усилий сервиса. Например, для кода из 4 цифр вероятность повторения хотя бы одной цифры — 50%. А для кода из 6 цифр — уже 85%.

Ради интереса я взял сервисы, по которым собрал больше всего данных, и проверил, какова доля кодов с повторами в цифрах. У большинства распределение получилось несмещённое, то есть специально они одинаковые цифры не генерят.

Единственное исключение — «Тиньков»: у него 65% кодов с повторами против ожидаемых 50%.

Что, если всегда генерить код с повторами

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

Шанс угадать такой код на 3 попытках — 0,06% или 1650 бесплодных злодейских заходов. Как по мне, вполне надёжно. Хотя ваш безопасник будет против, конечно ツ

⌘ ⌘ ⌘

Резюмирую:

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

А ещё, пишите код в начале сообщения.

Если вы, как большинство нормальных людей, не следите пристально за развитием веб-API, то вот краткая сводка их успехов в обработке речи.

Синтез речи

Вовсю работает в нормальных браузерах. Реализуется в 4 строчки на джаваскрипте:

See the Pen Синтез речи by Anton (@nalgeon) on CodePen.

Функция speak создаёт говорилку и озвучивает переданный текст на русском языке.

Распознавание речи

Работает только в хроме и фаерфоксе, причём у каждого по-своему. На андроиде тоже работает, хотя функциональность ограничена по сравнению с десктопом. Реализуется посложнее, но тоже терпимо — 40 строчек джаваскрипта:

See the Pen Распознавание речи by Anton (@nalgeon) on CodePen.

Распознавалка — в классе Recognizer. Начинает слушать после вызова start(), заканчивает после stop(). Накапливает распознанный текст в свойстве transcript. Умеет возвращать промежуточные результаты распознавания, если передать обработчик в start():

recognizer.start((text) => {
  txtInterim.value = text;
  txtMessage.value = recognizer.transcript;
});

Добрый человек Tal Ater сделал удобную обёртку над API распознавания — библиотеку annyang. С ней всё ещё проще.

Вредный совет продакту: «Надо заканчивать фичи». Вредный совет вообще: «Надо заканчивать то, что начал».

• Я не заканчиваю читать начатую книгу, если понимаю, что она пустая.
• Я не заканчиваю и не публикую текст, если получилась фигня.
• Я не заканчиваю тренировку, если чувствую себя плохо.

И вам не советую.

В применении к фичам:

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

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

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

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

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

P.S. Это ответ на заметку «Надо заканчивать фичи» Михаила Дубакова, основателя Targetprocess

В университете меня три года пичкали функциональным анализом, дифференциальными уравнениями и теорией функций комплексного переменного. Считаю это преступлением против юности: как и большинству программистов, эти знания никогда не понадобились.

В этой заметке я расскажу, какие (небольшие) кусочки математики действительно пригодятся программисту и как их освоить за несколько месяцев. Если вы уже программируете — можно использовать как чек-лист для самопроверки.

Сразу скажу, что если вы программируете игры или разрабатываете софт для физиков, медиков или биологов — этого не хватит. Но для «бизнесовых» и повседневных программ — с запасом.

Интересные программисту области относятся к дискретной математике. Более конкретно:

• логика,
• комбинаторика,
• теория вероятностей и матстатистика,
• линейная алгебра,
• теория графов,
• теория сложности.

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

Логика

Логические переменные и операторы. Булева алгебра. Таблицы истинности.

Вполне возможно, что это проходят ещё в школе — я уже не помню, что там было ツ

Комбинаторика

Размещения и сочетания. Бином Ньютона и биномиальные коэффициенты. Разбиения. Формула включений и исключений.

Теория вероятностей и матстатистика

События и их вероятности. Комбинации и последовательности событий. Зависимые события и теорема Байеса.

Меры среднего значения выборки: арифметическое среднее, медиана и процентили. Матожидание, дисперсия, стандартное отклонение.

Случайные переменные и их свойства. Распределение вероятности.

Линейная алгебра

Матрицы и векторы. Базовые операции над матрицами.

Теория графов

Гравы, подграфы, вершины и рёбра. Маршруты, пути и циклы. Операции над графами. Деревья. Раскраски.

Теория сложности

Логарифм и экспонента. Арифметическая, геометрическая и прочие суммы.

Скорость роста функций и алгоритмов. O-нотация. Анализ алгоритмов.

⌘ ⌘ ⌘

Теперь о том, где этому учиться.

• Курс Основы дискретной математики закрывает большую часть тем, рекомендую. Рассчитан на два месяца.
• Теорию сложности можно посмотреть в курсе Введение в дискретную математику, четвёртый модуль.
• Основы линейной алгебры очень доступно рассказаны в курсе Machine Learning, первая неделя, модуль Linear Algebra Review.

Все курсы бесплатные.

За скобками остались алгоритмы и структуры данных, потому что их обычно относят к «computer science», а не математике. Напишу о них в другой раз.

У американцев предусмотрен вагон должностей вида «чототам officer». Типа «Data Protection Officer» или «Information Security Officer».

Традиционно их переводят на русский как «офицеров». Это неправильно, потому что ну какие они к чёрту офицеры. В то же время, превращать officer в какого-нибудь «специалиста» или «менеджера» тоже нехорошо.

И вот сегодня меня осенило. Officer — это же «прапор»! Послушайте, как хорошо:

• прапор информационной безопасности
• прапор защиты данных
• старший прапор маркетинга

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

Officer в бизнесе = прапор!

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

Когда программист видит автокомплит — немедленно совмещает его с проверкой. Программист думает так:

Если пользователь хочет ввести что-то непредусмотренное автокомплитом, следует сурово его покарать.

Нельзя допустить, чтобы человек вводил отсебятину, думает программист:

Люди спокойно вешают такие проверки на формы заказа в интернет-магазинах, например. Их не смущает, что покупатель, получив свой «некорректный адрес» (или ещё лучше — «некорректное ФИО»), просто уйдёт.

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

Нормальное решение только одно:

Не использовать автокомплит для проверки данных

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

• Если покупатель в магазине указал неизвестный автокомплиту дом — ничего страшного. Менеджер потом перезвонит и уточнит.
• Если человеку нравится указывать машину как «BMW X5 3.0 SD», а подсказки знают только «BMW 5-Series» — не надо рассказывать, что записаться в сервис никак невозможно.
• Если предприниматель два часа назад зарегистрировал компанию в налоговой, и облачная бухгалтерия ещё не успела подтянуть данные — не надо отказывать в регистрации, пусть введёт реквизиты вручную.

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

Простая эвристика:

Автокомплит — для помощи человеку, не для проверки

Ghost (лучший блого-движок ever) празднует пятилетний юбилей. По этому поводу авторы написали, что они поняли о рынке и разработке опенсорс-софта за прошедшее время. Статья классная, рекомендую.

Зацепил один момент. Они пишут:

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.

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

After 5 years and 3 $M, here’s everything we’ve learned from building Ghost

После выпуска айпода Эпл постоянно ищет новый вау-продукт — такой, чтобы не просто популярный, а аж дух захватывало.

• Сначала получилось с айфоном.
• Потом не получилась с айпадом — оказалось, что планшеты людям не особо нужны.
• Потом не получилось с макбуком. Эйр не слишком зашёл, а прошки постепенно стали хуже чем были.
• Потом не получилось с часами — тут история как с планшетами.
• Из нового захода на айфон получилось это убожество с ушами, о котором даже говорить неудобно.

В общем, ничего такого я от Эпла уже не ждал. Пока не попробовал новые наушники — эйрподы, которые похоже на свисающие из ушей сигареты.

И знаете, мне всё равно, на что они похожи. Наушники дико удобные — практически не ощущаются и не ограничивают движения.

Работают как гарнитура — можно вообще только одно ухо вставить, а второе отдать кому-нибудь — получится телеконференция. Раньше я пользовался Plantronics Legend, и при всём уважении к Плантрониксу, эйрподы уделывают его в ноль.

Работают с андроидом (когда такое было вообще). Больше того, для счастливых обладателей ведра бонус: двойное постукивание по наушнику работает как play / pause. На айфоне оно по умолчанию вызывает Сири, ха-ха (ещё одна неудавшаяся эпловая поделка).

Для меня Эпл наконец сделали сказочный продукт. Это 🔥

Сыграл с читателями «интерфейсов без шелухи» в моего любимого супергероя — Капитана Очевидность.

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

1000 дизайнеров использовали капитанское супероружие — здравый смысл — чтобы получить такие результаты:

Не могу сказать, что капитан победил. Швейцарцы выяснили, что удобнее всего человеку видеть сообщения об ошибках справа от текстового поля. Но они исследовали десктопные интерфейсы. На мобильных, естественно, лучше всего показывать сообщения под текстовым полем.

Так что ничья ツ

Отчёт об исследовании

Карточки помогают компактно показать сложный объект:

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

• иллюстрация (привлечь внимание);
• заголовок (понять, о чём статья);
• аватарка и имя автора (заинтересовать, если автор знаком читателю);
• количество аплодисментов (социальное доказательство ценности);
• время чтения (принять решение: читать сейчас, добавить в закладки или вовсе не читать).

У Фейсбука на первый взгляд тоже всё хорошо:

Но не очень:

• Чуть ли не на самом выигрышном месте — количество фолловеров (что это? зачем? почему не написать там про общих друзей?)
• Непонятно, кем и где человек работает (мешает узнать малознакомого человека или заинтересоваться незнакомым)

Отсутствие информации о работе — это прямо провал. При этом фейсбук умеет компактно показывать место работы:

Но на карточке почему-то не пишет ¯\_(ツ)_/¯

⌘ ⌘ ⌘

Если формулировать правила для содержимого карточки, я бы предложил такие:

1. Хорошая карточка отвечает на главные вопросы пользователя в этой точке сценария использования.
2. И помогает разработчику достичь бизнес-целей (увеличить конверсию, вовлечение, виральность и т.п.)